> Honestly, this reads more like you're burnt out and would prefer not to have to keep apace of new developments to continue contributing.

New developments don't necessarily mean "let's create new and weird syntaxes for TMTOWTDI"

> For one, natural language is constantly evolving. Shouldn't the languages we use to describe the solutions to problems be similarly capable if they want to keep up with a rapidly changing world?

There are many problems with this analogy. But before you read my points, or even instead of reading my points, I'd recommend you watch "Growing a Language" by Guy Steele: https://www.youtube.com/watch?v=_ahvzDzKdB0

1. A programming language is not a natural language. It is a constructed language

2. A natural language is not really constrained by anything. It can willy-nilly invent new words and concepts. It can import words and sentences wholesale from other languages, adapt, translate or transliterate them. It can deprecate and get rid of unused words concepts or give entirely new meaning to words. It can and is ambiguous.

3. A programming language is constrained and restricted. English has 500,000 headwords in a dictionary. All of those are "built in". Perl has maybe 100 total built-ins (including operators and keywords), plus a couple of hundred functions in the standard library?

4. A programming language does not aim to encompass all of human knowledge (a natural language does).

5. A programming language hopes to avoid ambiguity (C++ is rightfully criticised and ridiculed for the amount of ambiguous places in its standard). It aims to assign one and only one meaning to every word. A natural language will have thousands of words which have multiple meanings (famously, in English "set" has 464 definitions).

6. A programming language over the course of its evolution does not flip concepts or change meaning of words (except in very rare cases such as changing operator precedence). There are hundreds if not thousands words in every natural language that changed meaning (gay, nice, clue, spinster, senile etc.).

7. A programming language is usually concerned with backwards compatibility (even the rapidly evolving Javascript has to take care not to break sites from 15-20 years ago). Natural languages are never concerned with that. There are tragic stories of huge swaths of history and culture not available to modern generations in South East Asia after they swapped the commonly used Chinese hieroglyphics for national alphabets. Meanwhile programming languages like Clojure boast being able to run old code, and Linux is famously boasting that "it's usually just enough to recompile old programs".

etc. etc. etc.

> For two, we can look at what extreme conservatism in this department does to you. Python 2

That's not conservatism. That's pragmatism. "Don't fix what ain't broke" is a maxim that is as true today as it was yesterday, and as it will be tomorrow. There can be decades of institutionalised logic coded in Python 2. And it works. We should switch to Python 3 because someone said so?

There are 40-year old COBOL codebases that are still doing their job. Should they have been switched to C in the 80s, only to be switched to Java in the 90s, only to be switched to Python in the 00s, only to be switched to Javascript in the 2010s?

> Similarly, we see a lot of languages punt on actually making it easy to prototype and deploy modern data structures and algorithms.

What you call modern were most likely discovered in 1940s-1960s. All languages have been slow to adopt those. It still has no bearing on my initial statement of " A code by programmer A that does X is not significantly different than code that does the same X by programmer B". A boring language will adopt those modern structures in a boring way and my statement will remain as valid as it is now.

> That's why a bunch of mainstream languages still have very slow sorting algorithms in the stdlib

So, don't rely on stdlib in these cases.

> No one actually has this problem. Not Perl 6, not Perl 5, and not Haskell or Ocaml

Everyone has those problems in any language that adopted TMTOWTDI. It manifests in difficulty reading other people's code, onboarding of new hires in organisations etc. etc.

On that note, Rails' popularity (and its clones' popularity) comes from the fact that it enforced the "there's only one true way to do it" mentality in a language known for its TMTOWTDI approach. And still, if you take code that does the same by two different people, you'll have to reverse engineered each one as they will use and abuse the "let's do it differently" mentality.