Greybeard's tomb: the lost treasure of language design (2019)(michael.orlitzky.com) |
Greybeard's tomb: the lost treasure of language design (2019)(michael.orlitzky.com) |
The most glaring problem is, of course, a fetishism for "independent" and "formal" standards. Standards are just documents that are presented as such, so qualifiers should be significant in order to be meaningful. And yet cited C and Ada standards are not exactly independent nor formal; standard organizations do not write a standard themselves, but appoint working groups and bless their outcomes. I don't know much about Ada standards, but the C standard is absolutely affected by major compiler vendors, but not completely. That's not an independence, but a democracy that the author seems to dislike? Not to mention that most standards are not that formal, with multiple possible interpretations and resulting incompatibilities.
An idea that compilation somehow discourages dependencies is also naive, especially given the history of Windows applications and the infamous term "DLL hell". It rather hides dependencies and often puts the resulting burden into end users (consider a very large minified JS blob). A clear vision and an active effort can reduce dependencies, regardless of compiled or not---transitive but otherwise unused dependencies are very much common and should be the foremost target after all.
I think the kernel of truth here is not that all compiled languages are superior, or that independent formally specified languages are necessarily superior, but that _low frequency updates to core features_ enables building 'critical mass'.
The emphasized points, e.g. code reuse, or stability, come from things like standardized formats, or well understood targets. The most salient points e.g. about cpp code not disappearing or libraries needing to be re-written are issues with ecosystems, not languages.
Given the OPs attitude towards Python, it seems he doesn't understand his own point - it succeeded because it was a consistent, simple language that did not change much, until Python 3. It was bad at a lot of things but it filled a niche, consistently, meaning it gathered a lot of steam (plus he demonstrates a misunderstanding of the point of interpreted languages, which is not to provide necessarily fast or correct programs, instead to invoke battle tested code quickly, nimbly, and adaptably).
"Up until recently (say, Google exists but you don't yet need to be transgender to work there), computers ran what were known as programs. These so-called programs were made of machine code, consisting of microscopic numbers that tell your CPU how to arrange particles of electricity into pornography. Ask your parents. The last program ever written was the V8 engine in 2008, after which programming was over and we all set about writing Javascript engines in Javascript for the next Javascript years.
Machine code was outlawed: in order to display pop-up advertisements, everyone agreed that it was best if we blindly ran whatever code was sent to us by strangers on the internet. We all got hacked for a while, but as a result, we now have a long list of extremely specific things that code from strangers shouldn't be allowed to do. We've only had to amend the list a few thousand times in the past; and—thanks to our collective willful ignorance of statistics, history, computer science, economics, crime, psychology, and of how lists even work—we're pretty sure that the list is complete this time."