Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ and the Culture of Complexity (2013)

blog.greaterthanzero.com

Post reply on HN
Print view View original

91–100 of 285 posts

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

#91

Post by jVinc »

IshKebab wrote: post #63
bjorn2k wrote: post #46

I agree that c++ is complex, but remember that while trying to update the language the standard committee is trying not to do breaking changes. If you can do a greenfield implementation like rust, you don't have the baggage of an installed base, yet. If you compare c++ to a language that is also around for more that 25 years it starts to make more sense why it is complex. Add to that, that it started as an extension…

Yeah by keeping backwards compatibility they avoided something like the Python 2/3 mess which I would say is worth the effort and cruft.

Looking at the current programming language space, it honestly doesn't look like the Python 2/3 issue hit them that hard in the long run. And while it wasn't popular it might have been the right way forwards. Python is one of if not the most rapidly growing language. In large part due to the data-science movement which for anyone I've talked to is based on Python 3. I still occasionally talk to 2.7 proponents, who explain to me that they need to have this and that to handle all the complicated edge cases and problems in dealing with bytes vs. strings... Issues that you just don't encounter at all in python3.

If I had the choice of having a C++2020 with absolutely no backwards compatibility but a greatly cleaned up language or having yet another step down the path it's heading now, I'd chose the former even if it breaks backwards compatibility. But the language is going to follow the developers and they want to continue down the path where they get to explain again and again and again the intricacies and delicacies of rvalue semantics, exotic template meta-programming and what-ever the next big thing is going to be. All the while we seemingly still don't even have a clear road-map for providing simple modules.

I was enthusiastic back when C++11 hit and it felt like a great big push going on in the language development, I had the feeling that things were really going to take off... but now it feels like it just died out, and now there's nothing that really gets me exited about the future of C++. I'm worried It's going to get more and more complex and less and less used.

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

#92

Post by jcelerier »

WalterBright wrote: post #45
pjmlp wrote: post #41

Earlier quoted context omitted.

> For example, why does C++ still support EBCDIC? Because there are companies like Unisys and IBM that want to sell C++ compilers to their mainframe customers.

IBM can support it as an extension in their C++ compiler. No need to burden the rest of the community with it. It's not like C++ compiler vendors are shy about adding extensions :-) Despite C++ supporting EBCDIC, I seriously doubt the overwhelming majority of string processing C++ code will work with EBCDIC anyway, because the programmers probably never heard of it, let alone tested the software with it.

> No need to burden the rest of the community with it.

yeah, the problem is when IBM goes with big checks to national standard bodies and complains "muuuuhh we won't be able to assure that the systems we sold you in 1970 will still work in 20 years if the C++ standard removes support for EBCDIC" and then these standard bodies write strongly-worded letters to the ISO commitee: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n291...

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

#93

Post by nextos »

osullivj wrote: post #86
notacoward wrote: post #16

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…

I think that's spot on. I coded quite a lot of C++ in the early 2000s. Now I'm considering to jump onboard again. C++11 and successors are almost a different language.

More importantly, for my niche I don't see anything that can readily replace C++. Rust has very little support for scientific computing. Julia is great, and will replace my high level statistical inference code, but it's not designed to let me design low-level close-to-the-metal data structures. Scala has memory issues, which will be hopefully less problematic once value types are implemented in the JVM. OCaml and F# look interesting, I haven't evaluated these carefully.

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

#94

Post by Gibbon1 »

pjmlp wrote: post #80
cageface wrote: post #76

Earlier quoted context omitted.

C++ is a mess but it's one of the few languages that gives you low-level control of memory and fast code with zero or near zero cost abstractions. So for a certain class of application it's still the best choice. Music software, for example, is pretty much exclusively written in C++. I don't enjoy C++ the language very much but you can build some very cool things with it. Personally I'm hoping Rust displaces it from…

Very very slowly. Only now embedded development is starting to accept C++, and C still rules there anyway. Which means it took about 20 years to reach this point. And still Rust will need to go through the same certification processes that C, C++, Ada and Java enjoy for such scenarios.

I feel like embedded development should just avoid c++ and go with a managed languages. I was hopeful abut go, but they kinda wrecked it for embedded.

The thing with embedded is you have two cases, hard real time and just don't care.

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

#95

Post by lallysingh »

overgard wrote: post #31
lallysingh wrote: post #6

Earlier quoted context omitted.

Meh. The performance is almost never worth the huge complexity jump. Instead, profile an app in a higher level language and if any part's too slow, implement that in C/C++. That'll quite often be a low, single digit percentage of the app. Get the performance for substantially less engineering/maintenance cost.

I used to argue the same thing, but passing things across language barriers makes debugging painful and is usually pretty error prone, tools can't understand your codebase as well, and there are performance costs to all the conversions.

Depends on the languages involved.

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

#96

Post by Gibbon1 »

jVinc wrote: post #91
IshKebab wrote: post #63

Earlier quoted context omitted.

Yeah by keeping backwards compatibility they avoided something like the Python 2/3 mess which I would say is worth the effort and cruft.

Looking at the current programming language space, it honestly doesn't look like the Python 2/3 issue hit them that hard in the long run. And while it wasn't popular it might have been the right way forwards. Python is one of if not the most rapidly growing language. In large part due to the data-science movement which for anyone I've talked to is based on Python 3. I still occasionally talk to 2.7 proponents, who ex…

> If I had the choice of having a C++2020

Would be nice to just do a fork and you either pass -std=c11 or -std=c20.

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

#97

Post by lmm »

mikevm wrote: post #48
notacoward wrote: post #16

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…

How is Rust less complicated than C++? I don't use it, but from what I read it seems to be even more complicated, and getting even more so with the myriad of features they are adding each release.

It seems to have many fewer language-level features. No lvalue/rvalue distinction, pointers are not elevated to a language-level feature (only references), only a very limited exception mechanism (panic) that doesn't try to generalize to support general validation (rather general validation is done with Result which is a plain old datatype written in the language, though admittedly it relies on a macro for use - more generally this approach is also used for things like I/O, a lot more is done with plain old library functions written in the language rather than added to the language standard), the macro mechanism is much less of a special case than the C++ preprocessor, no "const" and associated language-level complexity (e.g. "mutable"), smaller and more consistent syntax (no comma operator, no sequence point rules), more unifying things from the start (e.g. traits as values) rather than ad-hoc conversion rules in the language later on.

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

#98

Post by pjmlp »

Gibbon1 wrote: post #94
pjmlp wrote: post #80

Earlier quoted context omitted.

Very very slowly. Only now embedded development is starting to accept C++, and C still rules there anyway. Which means it took about 20 years to reach this point. And still Rust will need to go through the same certification processes that C, C++, Ada and Java enjoy for such scenarios.

I feel like embedded development should just avoid c++ and go with a managed languages. I was hopeful abut go, but they kinda wrecked it for embedded. The thing with embedded is you have two cases, hard real time and just don't care.

They go with Java in very specific cases, but you need big bucks to pay for something like PTC Perc Ultra, JamaicaVM or WebSphere Real Time.

Then there is microEJ as well, but their target is that performance critical code is anyway written in C and exposed to Java.

Also depending how embedded one might consider mobile phone hardware, there is Android and Android Things.

Then there are some OEMs still selling Basic, Pascal and Oberon compilers.

But in what concerns embedded domains where only Assembly and C get used, currently C++ seems to be the only one that they care to adopt. Specially given that it already enjoys the same kind of safety regulations (MISRA, DOJ and similar).

And not everyone mind you, C++ conferences keep having sessions on how to advocate to those devs.

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

#99

Post by gpderetta »

WalterBright wrote: post #45
pjmlp wrote: post #41

Earlier quoted context omitted.

> For example, why does C++ still support EBCDIC? Because there are companies like Unisys and IBM that want to sell C++ compilers to their mainframe customers.

IBM can support it as an extension in their C++ compiler. No need to burden the rest of the community with it. It's not like C++ compiler vendors are shy about adding extensions :-) Despite C++ supporting EBCDIC, I seriously doubt the overwhelming majority of string processing C++ code will work with EBCDIC anyway, because the programmers probably never heard of it, let alone tested the software with it.

The Committee recently got rid of trigraphs (required for EBCDIC compatibility). IBM was strongly against the proposal but was finally outvoted. They do keep the functionality as a conforming extension in their compiler, but now that they have been removed from the standard, the language might evolve in ways that might make the extension non-conforming.

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

#100

Post by klik99 »

api wrote: post #21
notacoward wrote: post #16

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…

C++ is a language with a lot of features, and not all of them should be used in every code base. It's quite possible to write simple, portable, and relatively clean C++ code if you use only those features you need. It's not the prettiest language by any stretch, but it's quite capable and fast and has excellent support across just about every platform.

I saw Stroustrup give a talk and he said exactly this - C++ is a toolbox of different paradigms that aren't meant to be combined. If you avoid frameworks that impose a particular paradigm and/or shield the parts of the codebase with different paradigms (for example when using Qt you really should have your "engine" running aside the Qt rather than embedding the code in the UI, extreme example I know but the same idea) you'll have a grab bag of different approaches for the specific problem you're having for zero cost. When people talk of "sticking to a subset" they are unknowingly doing exactly that (especially since everyones subset is slightly different).

There might be a "culture of complexity" in the community, but to remove the conflicting paradigms from C++ is to destroy what makes C++ useful. I don't believe C++ is complex in it's DNA, but highly experimental, overwhelming to newcomers and experienced developers alike (since you have to truly understand any feature before using it), and easily misunderstood. It requires more strictness in design and implementation than other languages, and isn't my first choice for anything that doesn't require high performance. But since I'm in game development and audio synthesis, it's often my only choice since nothing else hits that sweet spot of abstraction and performance.

Post reply on HN