C++ launched its community survey, too

[Joakim]

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.