[lifthrasiir]

Like most questionable posts, this post manages to mix some good points with more questionable and often close-to-wrong claims.

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.

[smaudet]

Agreed, a lot of it is wrong and reads like an emotional reaction to some bad things that started to happen.

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).