Comment by flohofwoe

13 hours ago

As I understood the article, the main critique is that the stdlib has no concept of deprecation and breaking backward compatibility. E.g. the C++ committee is quick to add badly designed features to the stdlib but then can't roll them back when people actually realize that those new features are useless for most real-world code.

I'm not sure this is a winnable game for programming languages.

- Keep a small stdlib, like JavaScript (especially earlier JavaScript): everyone complains about missing features, warring communities form around jQuery promises vs. Promises/A+ vs. callbacks, supply chain attacks, left-pad/is-even dependencies, etc.

- Grow a big stdlib while keeping backward compatibility, like C++: lots of cruft left around that must never be used, sitting next to newer stuff with similar names. People complain about the bloat.

- Grow a big stdlib and then break backward compatibility, like Python 2 -> 3: everyone is sad, the ecosystem churns for years.

I admit there are probably better and worse versions of each strategy, e.g., it seems to me like JavaScript's slow-but-steady accretion of primitives over time has gone OK, and it seems like apart from Python 2 -> 3 some of the PEPs I see for deprecations and replacements are reasonable. But no language has ever hit on a strategy that everyone loves, as far as I can tell.

Badly designed things get replaced. For example unique_ptr replaced auto_ptr. I'm not sure if the language standard actually supports the term "deprecation" though.

Edit: Also not sure what can possibly be downvoted here.

  • auto_ptr is an exception. Not the rule.

    Regular expressions in C++ are an example "everybody" advises against using, but it's still there. vector<bool> will stay forever and so on.

  • ISO/IEC 14882 contains many uses of the word "deprecation", including all the sections of Appendix D that explicitly lists all of the deprecated and removed features of the language and library.