3 ms·

Removing features from a programming language is almost impossible; it breaks backwards compatibility and so is a hard barrier to upgrading from the old version

Removing features from a programming language is almost impossible; it breaks backwards compatibility and so is a hard barrier to upgrading from the old version. Note the 12-year-and-counting struggle to adopt Python 3, or the fact that Perl 6 developers gave up completely trying to get people to upgrade from Perl 5 and just rebranded it as a new language instead. C++ has opted to avoid those struggles by never removing features; you can disagree with that decision but it was done for good reasons.

shortoncash 7y ago
I'm speaking strictly technical here, but there have been features that have been removed. Trigraphs (I think), and the register keyword. Moreover, there are objects that are very clearly marked deprecated, like auto_ptr. (Oh, and there is even talk of removing 'volatile' as a keyword.) The register keyword issue crops up because legacy code included and linked to modern C++ will occasionally have the word "register" affixed to a loop variable. Generally speaking, once you change standards, there is room to drop the old stuff. It's just gradual. Static analyzers do a lot to modernize code now too, so the situation is not as painful as it used to be.
- favorited 7y ago
  The `volatile` deprecation is more about providing new library features to do the things people (incorrectly) use `volatile` for today. `volatile` will still have legitimate use-cases.
nicoburns 7y ago
On the other hand, JavaScript very successfully added strict mode that removed features like `eval`. The trick seems to be to ensure that "old code" and "new code" can live side-by-side during a transition period.
- favorited 7y ago
  Vittorio Romeo has been proposing[0] an "epochs" feature for C++ which would enable modes like "strict." This would let them define things like const-by-default, requiring nulltpr instead of 0, etc. He's facing some resistance by other WG21 members. [0] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p188...
lizmat 7y ago
> the fact that Perl 6 developers gave up completely trying to get people to upgrade from Perl 5 and just rebranded it as a new language instead This statement does not do justice to the process that led to the renaming of "Perl 6" to "The Raku Programming Language". If you are interested in the process, https://github.com/Raku/problem-solving/issues/81 https://github.com/Raku/problem-solving/issues/81 will give you some of the discussion that happened online.

shortoncash 7y ago

I'm speaking strictly technical here, but there have been features that have been removed. Trigraphs (I think), and the register keyword. Moreover, there are objects that are very clearly marked deprecated, like auto_ptr. (Oh, and there is even talk of removing 'volatile' as a keyword.) The register keyword issue crops up because legacy code included and linked to modern C++ will occasionally have the word "register" affixed to a loop variable. Generally speaking, once you change standards, there is room to drop the old stuff. It's just gradual. Static analyzers do a lot to modernize code now too, so the situation is not as painful as it used to be.

favorited 7y ago
The `volatile` deprecation is more about providing new library features to do the things people (incorrectly) use `volatile` for today. `volatile` will still have legitimate use-cases.

nicoburns 7y ago

On the other hand, JavaScript very successfully added strict mode that removed features like `eval`. The trick seems to be to ensure that "old code" and "new code" can live side-by-side during a transition period.

favorited 7y ago
Vittorio Romeo has been proposing[0] an "epochs" feature for C++ which would enable modes like "strict." This would let them define things like const-by-default, requiring nulltpr instead of 0, etc. He's facing some resistance by other WG21 members. [0] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p188...

lizmat 7y ago

> the fact that Perl 6 developers gave up completely trying to get people to upgrade from Perl 5 and just rebranded it as a new language instead This statement does not do justice to the process that led to the renaming of "Perl 6" to "The Raku Programming Language". If you are interested in the process, https://github.com/Raku/problem-solving/issues/81 https://github.com/Raku/problem-solving/issues/81 will give you some of the discussion that happened online.