6 ms·

I feel like a development such as the C++ standard needs to deprecate things a lot faster than they currently do. Imagine in 15 years time when C++ compilers ar

I feel like a development such as the C++ standard needs to deprecate things a lot faster than they currently do. Imagine in 15 years time when C++ compilers are so complicated that they become self-aware and decide to get rid of us programmers.

arithma 8y ago
This does not go unnoticed, but with so many interested people who are actually contributing, it is hard to avoid the clutter. Bjarne Stroustrup (C++ creator) on this: http://www.stroustrup.com/P0977-remember-the-vasa.pdf http://www.stroustrup.com/P0977-remember-the-vasa.pdf
notacoward 8y ago
> the C++ standard needs to deprecate things a lot faster than the currently do. This, a thousand times. It's all very well for gumby to say that C++ is a big toolbox, but a good toolbox doesn't have all the mismatched tools from ten previous toolboxes all thrown together. Longcommonname can say that using modern C++ features help prevent errors, but that statement becomes a bit problematic when the most modern C++ style becomes deprecated C++ every few years. As the OP aptly illustrates, there are just too many ways to do even fairly simple things. All were idiomatic "best practices" for their time. It's not a problem if there are many ways to do things if they're all comprehensible to someone who knows the universal core of the language (as is often the case e.g. in C or Python). It's a problem when understanding each of them requires a whole separate excursion through some separate specialized and time-bound part of the standard, yet they all exist together in any large codebase that has had to build on those shifting sands. That's not good for maintainability. Future programmers will misunderstand the intent of code using each transient style, and either break it when they change it in place or miss some important detail when they try to replace it. Different versions of C++ should remain separate to a much larger degree than is currently the case. Trying to combine several distinct language-as-written into a single super language-as-compiled (a mistake also made by Scala) never seems to work out very well.
- MauranKilom 8y ago
  Do you interact with any significant C++ code base? Because I'm having a hard time seeing what your practical recommendations would be past the idealism. Yes, you can have major breaking changes every few years. But do you really think every larger C++ code base being stuck with the C++ version it was founded on is the way to go? Should they all be rewritten for each version?` Don't get me wrong, I'd love if we could deprecate more old stuff. The problem is that it doesn't just disappear from existing code (of which there is a _lot_) by marking it as such. If there are straightforward replacements (e.g. auto_ptr -> unique_ptr) that's one thing, but unless you want each new C++ standard to be unusable with existing code, you can't just do that.
  - notacoward 8y ago
    > Do you interact with any significant C++ code base? Yes. It's the codebase for one of the largest data storage systems in the world. If it stopped working, literally billions of people could be affected. Is that good enough to get past the ad hominem? > past the idealism. Is the idealist the one who questions the wisdom of changing a codebase that already works, or the one who demands it? It's all too easy to accuse others of being too idealistic, or to make up strawmen (see next point), but I don't think those are very constructive ways to approach a discussion. > do you really think every larger C++ code base being stuck with the C++ version it was founded on is the way to go? Of course not. But the transition from old idioms to new ones can be managed. The first thing that has to happen is that the people adding new features to each standard must be explicit about which old features are being deprecated when. Sure, you can specify --std=c++25 to get the new hotness, but then that might preclude use of old feature xyz from C++11 in the same compilation unit. You have to choose, and you should choose, according to pragmatic needs instead of mere neophilia. > unless you want each new C++ standard to be unusable with existing code Controlled deprecation doesn't necessarily mean 100% incompatibility between versions. N-1 is a very common model, which can be extended across any K prior releases. There are tons of examples, not only from languages but from APIs, file formats, operating systems, and even other kinds of engineering besides computers. People should absolutely be given time to adjust, but the time should be finite. "Simultaneously support everything that every existed" is the one model that's least likely to work in the long term.
biggestdecision 8y ago
So much of C++'s value proposition is based off the fact that it has such strong legacy compatibility. It's a language that is used today by businesses who are risk averse. Deprecating parts of the standard will make C++ a much less attractive language for the people who make up the majority of it's current user base. You also can't deprecate anything required for C interop, like the preprocessor.

arithma 8y ago

This does not go unnoticed, but with so many interested people who are actually contributing, it is hard to avoid the clutter. Bjarne Stroustrup (C++ creator) on this: http://www.stroustrup.com/P0977-remember-the-vasa.pdf http://www.stroustrup.com/P0977-remember-the-vasa.pdf

notacoward 8y ago

> the C++ standard needs to deprecate things a lot faster than the currently do. This, a thousand times. It's all very well for gumby to say that C++ is a big toolbox, but a good toolbox doesn't have all the mismatched tools from ten previous toolboxes all thrown together. Longcommonname can say that using modern C++ features help prevent errors, but that statement becomes a bit problematic when the most modern C++ style becomes deprecated C++ every few years. As the OP aptly illustrates, there are just too many ways to do even fairly simple things. All were idiomatic "best practices" for their time. It's not a problem if there are many ways to do things if they're all comprehensible to someone who knows the universal core of the language (as is often the case e.g. in C or Python). It's a problem when understanding each of them requires a whole separate excursion through some separate specialized and time-bound part of the standard, yet they all exist together in any large codebase that has had to build on those shifting sands. That's not good for maintainability. Future programmers will misunderstand the intent of code using each transient style, and either break it when they change it in place or miss some important detail when they try to replace it. Different versions of C++ should remain separate to a much larger degree than is currently the case. Trying to combine several distinct language-as-written into a single super language-as-compiled (a mistake also made by Scala) never seems to work out very well.

MauranKilom 8y ago
Do you interact with any significant C++ code base? Because I'm having a hard time seeing what your practical recommendations would be past the idealism. Yes, you can have major breaking changes every few years. But do you really think every larger C++ code base being stuck with the C++ version it was founded on is the way to go? Should they all be rewritten for each version?` Don't get me wrong, I'd love if we could deprecate more old stuff. The problem is that it doesn't just disappear from existing code (of which there is a _lot_) by marking it as such. If there are straightforward replacements (e.g. auto_ptr -> unique_ptr) that's one thing, but unless you want each new C++ standard to be unusable with existing code, you can't just do that.
- notacoward 8y ago
  > Do you interact with any significant C++ code base? Yes. It's the codebase for one of the largest data storage systems in the world. If it stopped working, literally billions of people could be affected. Is that good enough to get past the ad hominem? > past the idealism. Is the idealist the one who questions the wisdom of changing a codebase that already works, or the one who demands it? It's all too easy to accuse others of being too idealistic, or to make up strawmen (see next point), but I don't think those are very constructive ways to approach a discussion. > do you really think every larger C++ code base being stuck with the C++ version it was founded on is the way to go? Of course not. But the transition from old idioms to new ones can be managed. The first thing that has to happen is that the people adding new features to each standard must be explicit about which old features are being deprecated when. Sure, you can specify --std=c++25 to get the new hotness, but then that might preclude use of old feature xyz from C++11 in the same compilation unit. You have to choose, and you should choose, according to pragmatic needs instead of mere neophilia. > unless you want each new C++ standard to be unusable with existing code Controlled deprecation doesn't necessarily mean 100% incompatibility between versions. N-1 is a very common model, which can be extended across any K prior releases. There are tons of examples, not only from languages but from APIs, file formats, operating systems, and even other kinds of engineering besides computers. People should absolutely be given time to adjust, but the time should be finite. "Simultaneously support everything that every existed" is the one model that's least likely to work in the long term.

biggestdecision 8y ago

So much of C++'s value proposition is based off the fact that it has such strong legacy compatibility. It's a language that is used today by businesses who are risk averse. Deprecating parts of the standard will make C++ a much less attractive language for the people who make up the majority of it's current user base. You also can't deprecate anything required for C interop, like the preprocessor.