The graveyard of once-promising computer languages

 

I agree that one should fix a language's flaws, even if it means making breaking changes, however, that doesn’t change the fact that history shows you seem to only get one chance to get a language right. Oberon for example, had a fatal flaw in version 1, and because of that flaw, the early adopters, who are so critical to the success of a language, abandoned it, and moved elsewhere. The truth is that the adoption by “the herd” is driven by a small group of tastemakers. This is true in so many different fields. Take music for example, there are critics and “hip” people who spread the word that so-and-so is “hot”. The have a huge effect on the endpoint of the popularity curve, because the tastemakers function as filters for the society at large, who are so busy in their toils that they don’t experiment much, and the safety of herds relies on mass adoption and clustering. Want to be a hotshot artist in the USA? Get on the cover of Art Forum magazine.  

Humans are a herd animal like horses, and they run in packs, and stragglers are picked off by predators…so all evidence shows that your version 1 either makes you or breaks you. After all, the number of people using a language is a big factor in picking it to begin with. I have a saying, inertia is the most powerful force in the universe. Looking at the pile of dead languages, and there are over a 1000 that didn’t even make it to probably 10k users, the early adopters are a picky bunch, and don’t suffer glaring omissions kindly.

But being the eternal optimist that I am (and what programmer isn’t an optimist), i have made provision for graceful evolution of the Beads language by incorporating a feature whereby the code can be automatically upgraded to later versions, something that should be present in all languages but is inexplicably rare. 

To make the language comparison process less religious and more objective, i am performing “drag races”, where each language can be directly compared to another, by means of implementing a precisely specified task, and then to really add to the realism of the challenge, we take the perfectly operating program, modify the spec in some small way, and hand it to a new person, not the author, to update that code base to conform to the changed spec. For example, in Chess you could augment the rules, by allowing castling through other pieces, or giving the pawn the option to move 3 squares on the first move, not just 1 or 2. That is the acid test, can a different person improve someone else’s work? This is measurable, and actually matters the most, because code re-use is terribly low. In the real world, laws and conditions are constantly changing, and a program has to evolve. 

And to the point of allowing a language to evolve gracefully, i have added a feature to the syntax so that old code can be automatically updated as the language evolves. My experience shows that in business, programs last decades, and by that time the language has evolved so much that the existing code base gets cut off from the flow of the language, because it would disrupt the reliability to upgrade the compiler. People freeze the compiler more than they freeze the code, because it will wreak unknown, but possibly drastic effects. As soon as a big program stabilizes, there is a natural tendency to break it off of the “stream of constant breakage”.  I know that in my day job in a telecom firm, we have downgraded almost every PC in the company to Windows 7, because it works so much more smoothly. Look at the outrageous tactics Microsoft is employing to force their user base into Windows 10. i personally think Steve Ballmer should be in chains for his role in productivity abatement.