5 ms·

I think there exists both necessary complexity and unnecessary complexity. Necessary complexity is when the underlying system is genuinely hard and trying to si

I think there exists both necessary complexity and unnecessary complexity. Necessary complexity is when the underlying system is genuinely hard and trying to simplify it causes nuance to be lost -- Rust and Haskell are good examples. Unnecessary complexity just stems from poor design and then perpetually trying to add features on top of the poor design and making it worse -- the classic example is PHP. IMO, C++ has both a lot of necessary complexity (due to its lofty goals) and a lot of unnecessary complexity (mostly due to the C back-compat). I think this is the root of a lot of the "C++ sucks!"/"C++ is great!" arguments; when people only see one half or the other. My bottom line with C++ is that it tries and mostly succeeds to do a lot of hard things, but has questionable design decisions that make these things even harder than they need to be. For a while we just had to live with that because if you wanted a language that was both fast and high-level, C++ was the only game in town. I think that's no longer true, which is why I'm such a cheerleader for Rust: I see it as trying to have all the good things (necessary complexity) of C++ without the baggage.

stcredzero 10y ago
IMO, C++ has both a lot of necessary complexity (due to its lofty goals) and a lot of unnecessary complexity (mostly due to the C back-compat). I think this is the root of a lot of the "C++ sucks!"/"C++ is great!" arguments; when people only see one half or the other. C++ is more like an ecosystem of about a dozen languages. You can divide it into 4 languages chronologically. You can add a lot more by categorizing by use. If you pick and choose properly, you can set up a subset of C++ that makes it a great language. Half the computer programming managers out there have below average taste, however.
- gcp 10y ago
  Any sufficiently large project that pulls in dependencies will likely involve you dealing with all 4 of them. This is one reason why I doubt adding more features to C++ (making it 5) is going to make the language any more pleasant to use (outside toy, one person programs).
  - stcredzero 10y ago
    Any sufficiently large project that pulls in dependencies will likely involve you dealing with all 4 of them. Which describes my current work situation. However, this would seem to imply that a startup or a small project would be able to set up a C++ project with a beautiful, cohesive subset of C++. Your point is something that people who are serious about language design for programming "in the large" should definitely pay attention to. This is one reason why I doubt adding more features to C++ (making it 5) is going to make the language any more pleasant to use (outside toy, one person programs). How do you distinguish between one, two, three, or four person projects? Can you really make such a blanket statement about all the different possible codebases that exist? Methinks you exaggerate. (And I say this as a former dyed-in-the-wool minimalist Smalltalker!)
    - gcp 10y ago
      I put the distinction at "more than 1" because that's the point where you need to deal with code that isn't your own. (In theory of course your buddy could use a style and feature-set really close to your own and make it all a nice abstracted API so you don't need to look inside etc, but you get my point)
      - stcredzero 10y ago
        I put the distinction at "more than 1" because that's the point where you need to deal with code that isn't your own. You've never worked in a small shop where there was a good coding standard and everyone stuck to it? That sort of thing actually does pay off. I've seen this in my professional life.
        gcp 10y ago
        We tended to use libraries or external dependencies, too. (And when that was out of the question, C++11 and later usually were as well)
        stcredzero 10y ago
soulbadguy 10y ago
You make a good point in nuancing the different types of complexity, and trying to sort the complexity derived from doing something hard from the complexity of doing something wrong. But you skip the important details we do not have an objective way of knowing which is which. You are asserting that Rust/Haskell have more the of former and less of the later without really explaining how you go to that conclusion. Rust and Haskell are complex languages (as compared to say C). And it's not clear for a lot of people that their complexity is any better than C++. But by trying to garanty an ever increasing level of correctness and safety, they booth creating a large set of computation that are conceptually easy but very hard to express in a way that is correct to the type system/borrow checker.

stcredzero 10y ago

IMO, C++ has both a lot of necessary complexity (due to its lofty goals) and a lot of unnecessary complexity (mostly due to the C back-compat). I think this is the root of a lot of the "C++ sucks!"/"C++ is great!" arguments; when people only see one half or the other. C++ is more like an ecosystem of about a dozen languages. You can divide it into 4 languages chronologically. You can add a lot more by categorizing by use. If you pick and choose properly, you can set up a subset of C++ that makes it a great language. Half the computer programming managers out there have below average taste, however.

gcp 10y ago
Any sufficiently large project that pulls in dependencies will likely involve you dealing with all 4 of them. This is one reason why I doubt adding more features to C++ (making it 5) is going to make the language any more pleasant to use (outside toy, one person programs).
- stcredzero 10y ago
  Any sufficiently large project that pulls in dependencies will likely involve you dealing with all 4 of them. Which describes my current work situation. However, this would seem to imply that a startup or a small project would be able to set up a C++ project with a beautiful, cohesive subset of C++. Your point is something that people who are serious about language design for programming "in the large" should definitely pay attention to. This is one reason why I doubt adding more features to C++ (making it 5) is going to make the language any more pleasant to use (outside toy, one person programs). How do you distinguish between one, two, three, or four person projects? Can you really make such a blanket statement about all the different possible codebases that exist? Methinks you exaggerate. (And I say this as a former dyed-in-the-wool minimalist Smalltalker!)
  - gcp 10y ago
    I put the distinction at "more than 1" because that's the point where you need to deal with code that isn't your own. (In theory of course your buddy could use a style and feature-set really close to your own and make it all a nice abstracted API so you don't need to look inside etc, but you get my point)
    - stcredzero 10y ago
      I put the distinction at "more than 1" because that's the point where you need to deal with code that isn't your own. You've never worked in a small shop where there was a good coding standard and everyone stuck to it? That sort of thing actually does pay off. I've seen this in my professional life.
      - gcp 10y ago
        We tended to use libraries or external dependencies, too. (And when that was out of the question, C++11 and later usually were as well)
        stcredzero 10y ago

soulbadguy 10y ago

You make a good point in nuancing the different types of complexity, and trying to sort the complexity derived from doing something hard from the complexity of doing something wrong. But you skip the important details we do not have an objective way of knowing which is which. You are asserting that Rust/Haskell have more the of former and less of the later without really explaining how you go to that conclusion. Rust and Haskell are complex languages (as compared to say C). And it's not clear for a lot of people that their complexity is any better than C++. But by trying to garanty an ever increasing level of correctness and safety, they booth creating a large set of computation that are conceptually easy but very hard to express in a way that is correct to the type system/borrow checker.