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

71–80 of 285 posts

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

#71

Post by luk32 »

KayEss wrote: 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.

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

#72

Post by Santosh83 »

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.

For one thing, Rust has had the benefit of learning from the evolutionary lessons that languages like C++ went through. Another point is that really arcane stuff that's applicable only to very few legacy systems need not be supported, and aren't, while C and C++ don't have the luxury of dropping such support.

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

#73

Post by jejones3141 »

hux_ wrote: post #39
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…

Oh give me a break. Following this logic, why aren't you writing your code in English? The real world is complex. Don't confuse hiding complexity with minimizing complexity.

See Brooks's "No Silver Bullet". C++'s complexity is accidental.

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

#74

Post by pjmlp »

IshKebab wrote: post #64
pjmlp wrote: post #40

Earlier quoted context omitted.

Object Pascal, Eiffel, Ada, Mesa/Cedar, Oberon, Modula-2, Modula-3, Oberon, Oberon-2, Oberon07, Active Oberon, Component Pascal, Sather, Swift, D, Go, Rust are OO languages[1] and value based as well. [1] - As usual, there are many ways of doing OO, not just C++/Java style.

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 Go implement encapsulation via struct methods and modules.

Rust and Go implement containment.

Rust and Go allow for delegation.

Rust allows for type extensions via a mix of generics and traits.

Go allows for struct embedding as a kind of type extension.

Class based inheritance is not a requirement for a language to be OO.

CS literature is full of languages that explored other kinds of OO.

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

#75

Post by tomohawk »

virmundi wrote: post #14
foo101 wrote: 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++.

I find Spring to be great. I grant that I've used it since 2.0, but really it does everything quickly, easily, and is well documented. Especially with Spring Boot. I'm writing a core service in Go because Java 9 broke a Maven plug-in (that I don't need now). Holy crap is it painful. I know that I'm learning, but it's hard to layer the application. Most tutorials show passing the database connection through all of the…

I big part of learning Go, once you've done a lot of Java is to unlearn the things that you had to do as a successful Java programmer. You're used to looking at problems through the lens imposed by the imposing bag of tools and abstractions that is Java, as well as obsolete language design decisions (I'm looking at you, inheritance).

Resolve to look at things and think about things differently.

I have to give credit to Spring for saving Java from itself for a while, but it jumped the shark at some point. I've talked to many devs who've come from teams where only a small number of people understood the magic going on, and they never felt like they could really contribute because they couldn't scale the complexity hurdle of the modern Java environment.

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

#76

Post by cageface »

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 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 most of these remaining niches but even if it does it will probably happen slowly.

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

#77

Post by lou1306 »

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.

On the other hand, I find Python 3 much more predictable/less astonishing than 2. The jump was definitely a mess, but judging by the continuous spread of the language it seems to have paid off in the long term.

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

#78

Post by pjmlp »

Santosh83 wrote: post #69
WalterBright wrote: post #30

Earlier quoted context omitted.

> C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security. Being a C++ compiler writer (Zortech C++, Symantec C++, Digital Mars C++) I can assure you this is not true at all. As to why C++ is so complex, my opinion is it is because it was designed a long time ago, what is considered better practice in designing languages has moved on, and C++ is unwilling to…

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 going out with C. :)

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

#79

Post by TheArcane »

cageface wrote: post #76
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 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…

Robotics is pretty much exlusively in C++ as well.

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

#80

Post by pjmlp »

cageface wrote: post #76
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 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.

Post reply on HN