@amerika @AnimeTradCath @BowsacNoodle @CatLord @DiamondMind @Inginsub @LordMordred @NecroKvntPuke @SoyMagnus @Terry @Waerloga @anonymous @dcc @ehhh @gh0st @ins0mniak @jasonl8446 @kumicota @lunarised @marine @mia @mischievoustomato @peemasons @pressure @pwm @redneonglow @sjw @thebitchisback @threat @tiskaan @warmbeverageenjoyer Like with any one-size-fits-all-of-humanity proposal, the devil is in the details and the devil will leap out of the details and force you onto the collective farm at gunpoint. If you attempt it, you end up with a hideous mess, you get C++.

The easiest way to dismiss this "one true language" concept is to suggest that the person proposing it wander through RosettaCode: a language that is concise and readable for some math problem will often be terrible at glue code, and vice versa. Forget the requirement that the language actually be implemented: you can't come up with a notation that allows all of the things. https://rosettacode.org/wiki/Factors_of_an_integer , https://rosettacode.org/wiki/Calendar , https://rosettacode.org/wiki/Draw_a_pixel , https://rosettacode.org/wiki/Palindrome_detection . And that's just a list of toy problems, divorced from real-world requirements and real-world hardware. You might find a general-purpose language that can do most of the general-purpose computing, but you won't find a language that does equally well on a microcontroller with 512 bytes of RAM as it does on Blue Gene or when you try to compile it to shaders or when you want to implement a Naive Bayes classifier.

Each branch of mathematics has a different set of notations and "function" doesn't necessarily mean the same thing in two different branches. They don't have a problem with "legacy mathbases" but the things that have to be concise in one branch of formal reasoning about quantities is different from the things that have to be concise in a different branch.

> You can extend any sufficiently advanced language

This is the problem. You can very easily extend something but you cannot get rid of shit that's in the way or that makes it slow. JavaScript can't acquire tail-call optimization because the semantics of "caller" make this impractical. There are a million things like this. Bare words, take bare words. This is a trade-off that you want to make in a shell or Tcl or other interactive scripting languages but that you *don't* want to make in a slightly more sophisticated language.

Or take something like pattern-matching versus function currying: even if you can manage to come up with a set of rules that is unambiguous and allows both in the same language, you can't have both in a single language and expect to be able to use that language. If you managed to do something that is actually impossible, then your ruleset will be such that no human can form a mental model of the language and its runtime, precluding anyone from being able to write code for it, rendering it useless entirely.