> 1. A programming language is not a natural language. It is a constructed language Conlangs can be universal. Certainly Toki Pona and Esperanto punch above th

> 1. A programming language is not a natural language. It is a constructed language Conlangs can be universal. Certainly Toki Pona and Esperanto punch above their weight when given an opportunity to do so. > 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? Programming languages that lack these constraints not only exist, they're quite famous. You may have heard of Lisp. Similarly, the vocabulary that is the union of every C library in existence is surely more than half a million distinct tokens! Both natural languages and constructed programming languages can constrain themselves to subsets of the total vocabulary, and then extend or contract that context. > . 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.). Programming has tons of these as well. Many concepts are overloaded right now! The semantics under the symbols are constantly evolving. Heck, even things you might not believe have changed at lot have altered in subtle but important ways, like "new" and "delete" and "malloc" and "fopen." One of the most dramatically changed is "map." > What you call modern were most likely discovered in 1940s-1960s. No. 1990 onwards. People still spout absurdities like, "the fastest you can sort an array is O(n log n) time." But another important example is Bagwell's Hash Array Mapped Tries, which dramatically improve the performance of well-ordered key-value stores dramatically on modern hardware. Outside of some interesting index techniques, I can't think of many worthy algorithms from the 60's lingering in obscurity. Can you? > 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? If you don't change your methodologies at all over the course of a decade as the entire world of computer science revolutionizes itself and we even start rethink how we're organizing operating systems? > 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? Are there? I know a few banks deeply regretting their decision to keep their system of record on outdated cold-war-era technology as they struggle with hard complexity caps they can't address. But sure, I'm sure somewhere somehow this is true. It's just not actually an argument. > 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. This is a just-so story. There is no magical solution that makes all code permeable. It's misguided to assume code can exist without good documentation. > 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. Hi, I actually know a lot about this and there is no such notion in Rails. In fact, you have it exactly wrong. Rails is deeply committed to a "good default behavior" that is always subject to modification. And people do in fact modify it extensively to suit their needs. The idea that Rails's defaults are constraining as opposed to a rational starting point fundamentally misses the point.