Live data from Hacker News

C++ and the Culture of Complexity (2013)

blog.greaterthanzero.com

81–90 of 285 posts

Re: C++ and the Culture of Complexity (2013)

#81
Lots of posts here frame it like "Yes, it's a bit of a complex language, but the C++ committee has the difficult job of keeping everything backwards compatible, so it's understandable." But that's not the reality. The reality is that they (or Stroustroup) made that decision, and that decision was a mistake.

The correct way to deal with backwards compatibility issues is the way Go does it, namely to write tools to automatically upgrade code to a newer API [1]. And as that smug Google guy explained here [2], they have something like this for C++, too. They just don't bother sharing it with us peasants.

The fundamental mistake of C++ is to religiously keep backwards-compatibility with everything for all eternity. It's so easy to say that backwards-compatibility is a good thing. It's obvious! But ultimately that decision is the reason for all the problems that C++ has.

[1] https://golang.org/cmd/fix/

[2] https://www.youtube.com/watch?v=tISy7EJQPzI

Re: C++ and the Culture of Complexity (2013)

#82
post #71
post #37

Part of the problem here is that OO sits nicely with references, but C++ (like C) is a value based language. This can be seen clearly in most of the design of the standard library -- it's all value semantics, and as such relatively simple and obvious to use (so long as you're not trying to cram OO into it). A line like if ( a == b ) In C++ is pretty obvious what it does. It'll always be a value comparison, and if a a…

Are you sure? I can make (a==1 && a==1 && a==3) Evaluate to true. It is reasonable to assume what you say, but don't say "always", when it's not.

Me too, but not only in C++.

I can start with Python as first one.

Re: C++ and the Culture of Complexity (2013)

#83
post #74

Earlier quoted context omitted.

I don't really know about the others but Rust isn't really OO. Neither is Go.

Sure they are, just not on the classical C++/Java style hence the footnote, as I was already expecting that kind of comments. There isn't "The ONE true OOP way", just like there isn't "The ONE true FP way" or "The ONE true LP way". Each paradigm has a set of concepts of what they might mean, and many languages cherry pick from there. Rust and Go implement polymorphism via traits and interfaces respectively. Rust and…

On that topic, Joe Armstrong famously said that Erlang (Erlang!) might be the only "real" OOP language out there: after all, you can have encapsulation, polymorphism, delegation, and so on, by just designing appropriate exchanges of messages between processes.

Re: C++ and the Culture of Complexity (2013)

#84

Earlier quoted context omitted.

Well, you can spend 5 months writing your software in C++, and a month fixing your bugs and doing a bit of optimization. Or you can spend 3 months writing C# or other modern language and have another 3 months to optimize, all the while enjoying substantially faster compile times and super easy refactoring.

This is not an apples to apples comparison. I've given examples from runtime, not from development time. OTOH, refactoring in C++ is not hard, at least from my experience. With some knowledge of the language, everyone can write reasonably bug-free C++ (or any other language) application in one go. Compilation in C++ is a different story. C# is not native. It's converted to CLI (was that the name, I don't use Win32 fo…

C# is surely native as well.

It can be compiled to native code just like C++ via NGEN, .NET Native, CoreRT, IL2CPP, Bartok, Mono AOT.

Or if you prefer, C++ is not native. It's converted to LLVM bitcode, OS/400 TIMI, WASM,....

Lets not mix languages with implementations.

Re: C++ and the Culture of Complexity (2013)

#85
post #7

Earlier quoted context omitted.

C++ is a complex language no doubt. But software written in C++ need not be complex. Java, on the other hand, is a simple language. But the kind of unnecessary complexity I have seen in Java-land (EJBs, Spring, etc.) has no parallel in the C++-land. So going by your argument, I would choose C++ over Java to avoid the complexity jump, then profile the app, and if any part's too slow, improve that again in C++.

Java just pushes the complexity into the user's code. For example, a friend of mine once gushed to me about Java IDEs - with one click of a button, a hundred lines of boilerplate are automatically added! I replied a good language shouldn't need boilerplate code automatically inserted.

This is called 'Waterbed Theory' and is ascribed to Larry Wall.

https://en.wikipedia.org/wiki/Waterbed_theory

Re: C++ and the Culture of Complexity (2013)

#86

The bullet list near the end closely matches my own experience with C++. There's an inordinate number of features creating an even worse profusion of edge cases where they interact. Then the "solutions" for those edge cases usually add even more complexity. Worse, they force programmers to coddle their compilers. The ratio between what a C++ compiler will accept and what it will produce sane code for is huge . That's…

Strongly agree on the inordinate number of features point. Which other mainstream OO language supports dynamic & static dispatch, single & multiple inheritance, interface inheritance via abstract classes, generic types and functions via templates, lambdas, type inference, and operator overloading? Roll that up with C compatibility, a 30 year history of evolution, and the complexity of commonly adopted libraries like STL & Boost, and there's simply no avoiding it. There's a lot of C++ out there, and I'm confident that will pay the bills for years to come for this 50 something 25 year C++ veteran!

Re: C++ and the Culture of Complexity (2013)

#87

Earlier quoted context omitted.

Java just pushes the complexity into the user's code. For example, a friend of mine once gushed to me about Java IDEs - with one click of a button, a hundred lines of boilerplate are automatically added! I replied a good language shouldn't need boilerplate code automatically inserted.

Boilerplate bureacracy usually happens, when Configurations are not itteratable and/or a language does not enforce the providing of meaningfull defaults. I find both sides guilt and charged here...

>>language does not enforce the providing of meaningfull defaults.

There is more to this. This can can also happen if the language doesn't have features to heavy lift complicated code patterns well. You have to then use massive amount of code wall texts to make the same thing happen.

Part of the reasons why C based languages seem to die all the time, is because you sooner or later have to add features to catch up with the complexity of software getting written around. That either causes enormous amounts of ugly unusable bloat, or you have to go decades of backward compatibility breakage. The languages are just too brittle to work with change.

To give you an example. The best innovation that has come out of Python as a language is they changed the print feature from being a keyword to being a function. This is the biggest innovation they could manage in decades. And even this requires breaking backwards compatibility and having the entire world's Python code bases to go through several decades of upgrade cycles.

You see all this and just move on the next new language, like Go. And then the cycle starts again.

Re: C++ and the Culture of Complexity (2013)

#88
post #78

Earlier quoted context omitted.

THIS is the reason IMO too. C++ has taken on the very difficult task of remaining broadly compatible with C and with legacy features while at the same time has continuously evolved over the decades, incorporating whatever was the state of the art at that time, without new features breaking old code. That is not an easy task without increasing complexity.

The book "Design and Evolution of C++" is quite interesting in that regard. For all its warts, C++ only got adopted inside AT&T and later by almost every C compiler vendor, because it just fitted on their existing toolchains. Even lack of modules is related to that, C++ object files needed to look just like C ones. Now that C++ is grown up and can live on its own, it needs to pay for the crazy days of its parties goi…

Some might say the party never ended. :-)

Re: C++ and the Culture of Complexity (2013)

#89

The bullet list near the end closely matches my own experience with C++. There's an inordinate number of features creating an even worse profusion of edge cases where they interact. Then the "solutions" for those edge cases usually add even more complexity. Worse, they force programmers to coddle their compilers. The ratio between what a C++ compiler will accept and what it will produce sane code for is huge . That's…

I agree that C++ is bad but I actually find C much worse for projects bigger than a few thousands of lines. Reasons for this:

* lack of namespaces - all names with long prefix look the same to me

* just text based macros

* no generics

* error handling usually based on int constants and output function parameters - in big projects is hard to use them consistently without any type checking

* no polymorphism

* ton of undefined behavior (almost the same as C++)

Post reply on HN