The Costs of Programming Language Fragmentation

I really believe that it is better to have many small 'throw-away' programming languages that can interoperate with each other, than having a few huge languages that are isolated in their own ecosystem.

A language shouldn't be complex nor should it take more than a few days to learn, and it should be easy to abandon when another language is better suited for a problem.

What actually makes many languages useful is their standard libraries and library ecosystem, and the two always get mixed up. When people talk about how great language X is, in most cases they mean how feature-rich or easy to use the standard library of that language is.

With few exceptions, those libraries shouldn't be tied to a specific language. Let me access your library written in language X from my language Y.

Let me easily create projects that are made of different languages, for each part of the project the language that fits this part best.

I'm not sure how old that article is, but parts of gcc suite have been rewritten in a subset of C++ for several years now (https://lwn.net/Articles/542457/), starting from over 10 years ago.

Thank god nobody listened to his advice, otherwise we all be doing Basic and Java ( such rebel’s)

Fragmentation yields a distribution of effort which yields theoretically inferior products, compared to the theoretical output of all the individual parts working towards the same goal. (Debatable, but we'll assume it.)

Centralization yields a lack of competition yields a lack of a drive to improve inferior products yields stagnation and disenfranchisement. (Also debatable, but probably safe to assume here as well.)

Startup costs in this area (basic compiler stuff, usually handled by llvm and other varied metacompiler frameworks nowadays) become vanishingly small with time, while the long tail becomes ever larger (libraries, tooling, ecosystem goodness, all are expected now).

Given these two observations, when a language becomes popular despite starting in a fragmented ecosystem, it slowly grows, starts to take advantage of network effects, and gains the benefits of growing centralization as it becomes "the defacto choice" in some area (usually at the cost of other players in the space, be they large or small). Eventually, it stagnates, parts of the community become disenfranchised and go and spawn their own languages and variants (taking ideas from their origin, along with their grievances and ideas from other areas with them), and the process begins anew. However because of the growing long tail, each time this cycle takes place, the time between expansion and explosion takes longer and longer.

At least, that's how I've been led to believe systems like these tend to work.

It seems like the call to be _mindful_ of what you're doing when you make a language is sensible; if you contribute to the cycle, you're contributing to what will eventually be 2 years of long-tail work for what will be the de-facto norm for developer tooling 40 years from now; but that's a terrible way to look at it. Wouldn't you rather get in closer to the ground floor and be part of the first iterations that set the standards for the iterations which come after? Isn't thinking of it any other way just being defeatist? (Since it amounts to concluding that future generations of developers must be better at this than you, and so are worth more early-cycle-iteration time?) So what if it's indulging the ego some; if that's the cost of improvement, then so be it. The languages we have today wouldn't have been made without their predecessors, and the languages of tomorrow won't exist without the ones we have today. Is it also equally possible that deciding _not_ to make some new language potentially delaying the progress of the programming language field as a whole? Is making that value judgement in the purview of anything other than hindsight? I can't begin to imagine in what ways future languages may improve life as a developer, but if they're anything like the stark contrasts we've seen recently in certain PL areas (ie, systems languages), it's sure to be exciting.

Yes, I know that. C++ is also very much used for game development. C++ allows to build very impressive abstractions that are very handy. The main drawback is that this flexibility has a huge impact on the language. When you switch between two projects writen in C++, it is almost as if they were using a different language. I have understood that this language was a mess in 98 when I have bought the standard and read it completely. In professional projects, I always try to avoid it in favor of java despite all the years I have spent learning and using C++.