5 ms·

He's right in many ways. They did the best they could at the time under the constraints that they had - try adding type-safety to K&R C while maintaining backwa

He's right in many ways. They did the best they could at the time under the constraints that they had - try adding type-safety to K&R C while maintaining backwards compatibility with K&R C. But now the only way forward I see for C++ to maintain its position as a mainstream language is to draw a hard line in the sand and effectively only keep all of the stuff that people refer to when they say "write in Modern C++", and remove everything else.

AlotOfReading 3y ago
That's effectively what the profiles proposal is: a set of compiler warnings that error if you use anything outside a limited subset of modern C++. I don't think it's a very good proposal, personally. For one thing, it effectively amounts to a rewrite of nearly all existing code. For another, the error messages that can be emitted are terrible. Worse, it relies on the compiler to do a lot of heavy lifting that just isn't going to happen in the industries it's needed most for years. It's also opt-in rather than opt-out. Depending on the as-yet(?) unclarified constraints on UB, there may be yet more footguns for those unwise enough to attempt incremental rewrites. Also, because it's C++ there are already a bunch of visual warts like having to continue using gsl::span instead of std::span because of subtly different semantics. Or you can use a memory safe language and get essentially the same/better guarantees without all the caveats. However, you have to list a different language on future job postings.
- lelanthran 3y ago
  > That's effectively what the profiles proposal is: a set of compiler warnings that error if you use anything outside a limited subset of modern C++. Subtly different - by "a line in the sand" I meant that anything past this line is New C++ and anything behind the line is Old C++. Your compiler for New C++ wouldn't compile anything that is Old C++, and the Old C++ compiler wouldn't compiler much of New C++. Two different languages that both have Current C++ as an ancestor. > I don't think it's a very good proposal, personally. For one thing, it effectively amounts to a rewrite of nearly all existing code. For making it a set of errors in the Current C++, yes, it's a bad proposal and not what I proposed. Under my proposal, it's not like your Old C++ compiler will suddenly stop existing, or stop being supported, would it? You'll effectively have decades before this is the case. > Or you can use a memory safe language and get essentially the same/better guarantees without all the caveats. However, you have to list a different language on future job postings. Yeah. You list either New C++ or Old C++ (or both, if you can). Like many others, I gave up on C++ a long time ago and stick with C for those projects that I both 1) do solo, AND, 2) need the low-level access and performance.
  - pjmlp 3y ago
    As Python 2, Java 8 and .NET Framework have proven, that never works out that painlessly, plenty of people are still stuck on those versions to this day, with no end in sight, regardless how much the modern versions get pushed. Regarding C, it isn't also not standing still and WG14 is quite clearly turning it into "C++ without classes" kind of language, look forward to more _Generic improvements and upcoming lambdas in C29.
    - lelanthran 3y ago
      > As Python 2, Java 8 and .NET Framework have proven, that never works out that painlessly, plenty of people are still stuck on those versions to this day, with no end in sight, regardless how much the modern versions get pushed. That's sorta my point: it worked out excellently for those languages. Those with legacy code and unable to change still use legacy and the new language gets the benefit of remaining relevant. The point is not "keep that old shit as relevant for as long as possible", the point is "keep the language relevant", and that means jettisoning all the baggage that C++ has. > Regarding C, it isn't also not standing still and WG14 is quite clearly turning it into "C++ without classes" kind of language, look forward to more _Generic improvements and upcoming lambdas in C29. It's not standing still, but the pace and volume of additions is simply nowhere near to what the C++ committee does. As far as C is concerned, while I feel that they are poor stewards of the language, anyway, the future additions do look helpful.
      - pjmlp 3y ago
        It did not work out excellently, as there are now big problems regarding interoperability between old code and new frameworks, while at the same time finding people willing to work on those projects.
Barrin92 3y ago
>and remove everything else. That is not a good idea. Breaking backwards compatibility with a language that large is going to damage the ecosystem. the Python 2 -> 3 transition shows how slow and costly, ironically enough, this can be. Stroustrup is correct when he says the way forward is evolutionary. In evolution you never cut things, they're always phased out. Vestigial structures stick around. Incremental change is ultimately going to be more successful, causing schisms and splitting the language community is not going to be success.
- lelanthran 3y ago
  > Stroustrup is correct when he says the way forward is evolutionary. In evolution you never cut things, they're always phased out. Vestigial structures stick around. That hasn't worked in the past for C++. Why would you expect that approach to start working in the future? I also think that it's a bad idea to have the language's direction set by what the existing (and attritioning) developers want, and not by what it would take to get new devs. A policy like that is almost guaranteed to result in death by attrition. > Incremental change is ultimately going to be more successful, causing schisms and splitting the language community is not going to be success. Two things: 1. I think we're defining success differently here. I'm defining it as market-share.[1] 2. You're looking at the way C++ has always done things, which has failed (IMO, anyway) to keep the language mainstream. You're predicting a future where this approach that has failed in the past, will succeed in your predictions. BTW, I'm not predicting anything; I'm saying that the C++ approach has resulted in a dismal failure for the languages popularity, causing it to lose some ground against every single competitor in that space: Rust, Nim, Zig and more are all eating away at what's left of the C++ developer base after Java and C# took a shark-sized bite from it in the early 00's to late 00's. All that's left for C++ is gamedev. If we want to avoid that, C++ needs to be more accessible. In order to get to that, it needs to remove anything that can be removed. [1] Python is an incredible success, having gained marketshare since 3 was released and people started the "slow and costly" migration which only took 10 years for Python 3 to be the most-used language now. C++, by comparison, has been losing marketshare with each new evolutionary and incremental change that never discards anything. C++ has been doing what you say is the correct way, and it has been losing its status as a mainstream language with each new standard. Python did it the way you say is incorrect, and is still solid in it's use-case against newer and better languages.

AlotOfReading 3y ago

That's effectively what the profiles proposal is: a set of compiler warnings that error if you use anything outside a limited subset of modern C++. I don't think it's a very good proposal, personally. For one thing, it effectively amounts to a rewrite of nearly all existing code. For another, the error messages that can be emitted are terrible. Worse, it relies on the compiler to do a lot of heavy lifting that just isn't going to happen in the industries it's needed most for years. It's also opt-in rather than opt-out. Depending on the as-yet(?) unclarified constraints on UB, there may be yet more footguns for those unwise enough to attempt incremental rewrites. Also, because it's C++ there are already a bunch of visual warts like having to continue using gsl::span instead of std::span because of subtly different semantics. Or you can use a memory safe language and get essentially the same/better guarantees without all the caveats. However, you have to list a different language on future job postings.

lelanthran 3y ago
> That's effectively what the profiles proposal is: a set of compiler warnings that error if you use anything outside a limited subset of modern C++. Subtly different - by "a line in the sand" I meant that anything past this line is New C++ and anything behind the line is Old C++. Your compiler for New C++ wouldn't compile anything that is Old C++, and the Old C++ compiler wouldn't compiler much of New C++. Two different languages that both have Current C++ as an ancestor. > I don't think it's a very good proposal, personally. For one thing, it effectively amounts to a rewrite of nearly all existing code. For making it a set of errors in the Current C++, yes, it's a bad proposal and not what I proposed. Under my proposal, it's not like your Old C++ compiler will suddenly stop existing, or stop being supported, would it? You'll effectively have decades before this is the case. > Or you can use a memory safe language and get essentially the same/better guarantees without all the caveats. However, you have to list a different language on future job postings. Yeah. You list either New C++ or Old C++ (or both, if you can). Like many others, I gave up on C++ a long time ago and stick with C for those projects that I both 1) do solo, AND, 2) need the low-level access and performance.
- pjmlp 3y ago
  As Python 2, Java 8 and .NET Framework have proven, that never works out that painlessly, plenty of people are still stuck on those versions to this day, with no end in sight, regardless how much the modern versions get pushed. Regarding C, it isn't also not standing still and WG14 is quite clearly turning it into "C++ without classes" kind of language, look forward to more _Generic improvements and upcoming lambdas in C29.
  - lelanthran 3y ago
    > As Python 2, Java 8 and .NET Framework have proven, that never works out that painlessly, plenty of people are still stuck on those versions to this day, with no end in sight, regardless how much the modern versions get pushed. That's sorta my point: it worked out excellently for those languages. Those with legacy code and unable to change still use legacy and the new language gets the benefit of remaining relevant. The point is not "keep that old shit as relevant for as long as possible", the point is "keep the language relevant", and that means jettisoning all the baggage that C++ has. > Regarding C, it isn't also not standing still and WG14 is quite clearly turning it into "C++ without classes" kind of language, look forward to more _Generic improvements and upcoming lambdas in C29. It's not standing still, but the pace and volume of additions is simply nowhere near to what the C++ committee does. As far as C is concerned, while I feel that they are poor stewards of the language, anyway, the future additions do look helpful.
    - pjmlp 3y ago
      It did not work out excellently, as there are now big problems regarding interoperability between old code and new frameworks, while at the same time finding people willing to work on those projects.

Barrin92 3y ago

>and remove everything else. That is not a good idea. Breaking backwards compatibility with a language that large is going to damage the ecosystem. the Python 2 -> 3 transition shows how slow and costly, ironically enough, this can be. Stroustrup is correct when he says the way forward is evolutionary. In evolution you never cut things, they're always phased out. Vestigial structures stick around. Incremental change is ultimately going to be more successful, causing schisms and splitting the language community is not going to be success.

lelanthran 3y ago
> Stroustrup is correct when he says the way forward is evolutionary. In evolution you never cut things, they're always phased out. Vestigial structures stick around. That hasn't worked in the past for C++. Why would you expect that approach to start working in the future? I also think that it's a bad idea to have the language's direction set by what the existing (and attritioning) developers want, and not by what it would take to get new devs. A policy like that is almost guaranteed to result in death by attrition. > Incremental change is ultimately going to be more successful, causing schisms and splitting the language community is not going to be success. Two things: 1. I think we're defining success differently here. I'm defining it as market-share.[1] 2. You're looking at the way C++ has always done things, which has failed (IMO, anyway) to keep the language mainstream. You're predicting a future where this approach that has failed in the past, will succeed in your predictions. BTW, I'm not predicting anything; I'm saying that the C++ approach has resulted in a dismal failure for the languages popularity, causing it to lose some ground against every single competitor in that space: Rust, Nim, Zig and more are all eating away at what's left of the C++ developer base after Java and C# took a shark-sized bite from it in the early 00's to late 00's. All that's left for C++ is gamedev. If we want to avoid that, C++ needs to be more accessible. In order to get to that, it needs to remove anything that can be removed. [1] Python is an incredible success, having gained marketshare since 3 was released and people started the "slow and costly" migration which only took 10 years for Python 3 to be the most-used language now. C++, by comparison, has been losing marketshare with each new evolutionary and incremental change that never discards anything. C++ has been doing what you say is the correct way, and it has been losing its status as a mainstream language with each new standard. Python did it the way you say is incorrect, and is still solid in it's use-case against newer and better languages.