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.