On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis wrote:
On Tuesday, February 27, 2018 17:33:52 12345swordy via Digitalmars-d wrote:
On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu

wrote:
> https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite 
-2018-02
>
> Andrei

I have submitted, already. My major complaints boils down to the fact that they refuse to deprecated features due to religious like devotions to backwards compatibility support.

The main problem with that is that the fact that as soon as you're willing to break backwards compatability in C++, then you lose one of the major benefits of C++ (that the same code compiles pretty much forever)

No, you wouldn't, just do what D did with the 2.0 branch: put all the breaking changes in a new version, while continuing to support those clinging to old codebases with an older branch. D did it and survived the branch with much less resources, I see no reason C++ couldn't do the same with their massive resources.

and that if you're willing to give up on that, you might as well be using another language like D or Rust. I'm sure that there's a crowd who would love to break some aspects of backwards compatability with C++ and stick with it rather than switching to another language, but if someone actually really tried to fix C++, you wouldn't end up with C++ anymore. You might not end up with D or Rust, but it would definitely be a new language, and if you're willing to do that, why stick with C++?

Those people are more likely to leave when you don't clean up C++, including deprecating bad features. Users are always coming and going: you need to have some vision of what C++ will evolve into that will keep a lot of them, while still keeping enough backwards compatibility that most don't leave.

However, the way the politics works at any large, successful organization is that the ones pushing to maintain the status quo win out: after all, they've won out so far, so they clearly know what they're doing? Then, they inevitably fade away, as they lose touch with reality in their bubble.

The _only_ time this pattern breaks is if they're on the verge of dying and the crisis allows for radical change, such as when they brought Steve Jobs back to Apple and let him clean house, and that's almost always too late. C++ is not in crisis yet, so nothing will happen.

The other problem is that many of C++'s problems come from being a superset of C, which is also a huge strength, and it would be a pretty huge blow to C++ if it couldn't just #include C code and use it as if it were C++. To truly fix C++ while retaining many of its strengths would require fixing C as well, and that's not happening.

There are ways to clean up that C integration though, as D has shown with one approach. There's no reason to carry around this legacy baggage forever.

C++ stagnates because of a lack of creativity, will, and vision, which is going to happen to any organization that gets fat and successful. There are many things they could do to change this descent, but they lack those essential ingredients to do them.

Reply via email to