Phew! … that has really been a long time, since I posted anything in this series. I apologise to anyone who was awaiting anything. Since my three weeks summer vacation in August I wasn’t able to pick up blogging with the same intensity as before and right now I don’t feel I will recover soon, if ever. The Meteor full-text search package thing, other concrete software projects, work, our cars (we had an Autobahn accident right at the beginning of our vacation and my commuting Aygo’s clutch died) and family, kept me really busy for quite some time. After this long writing break words don’t really flow. If you know what I mean.
I published a schedule for this series, which I will not be able to follow, I fear. So forget about it. Posts will come as I can manage to write them. That said let’s look onto the topic of this post, the next attribute on which I will assess programming languages for their chance to become The Next Big Language: Ecoverse.
Well, with Ecoverse I mean the stuff that “surrounds” the language: libraries, runtimes, frameworks. The Java stack for Clojure, for example. The development environment is discussed in a different post. Here only the things you use in your programs or that run your programs are meant.
This factor is very relevant, but has two opposing vantage points.
The first: the NBL must be deeply rooted in an existing world. Proponents of this vantage point argue that it is easier to get started, to become productive, to build hardened real world apps. Their reasoning goes long this lines: you can reuse literally millions of thoroughly tested, runtime-optimised and proofed-to-work lines of code. That is admittedly a big asset. But there are drawbacks, as well. The existing Ecoverse might stifle the possibilities a language can theoretically possess, which might make the language suboptimal regarding other factors.
And there is another point: fun. Developers (in my experience) tend to willingly reinvent the wheel. Again and again. They have fun doing so. They seek the challenge. They constantly try to make things more elegant, more generic, they put layer upon layer to make their final work – stitching some concrete business app together – less time consuming and boring. Especially when doing spare time coding.
But when everything is there and needs only to be more or less awkwardly included into your program, there isn’t much fun left. Only the drudgery of sewing the parts together. And when a language is built upon an existing Ecoverse this can become a real pain in the ass.
The second standpoint: the NBL has to be fresh, shiny and new. The language can be freely and optimally designed. No drawbacks from the existing stack. Developers can freely reinvent everything and hopefully use what they have learned from existing counterparts. This might boost other factors considerably. Of course basic things might be missing, not working correctly or lack performance. Making a real-world app would result in the need to build many things from scratch and ugly workarounds. The time and cost penalty as well as the risk wouldn’t be affordable by any financially pressed company.
Both are extreme points. We might encounter languages, that try to find a balance here.
To summarise. Companies would go for the first point. Developers for the second. The question is: Which group will more likely trigger wide adoption?
The lovely Steve Ballmer put it: Developers! Developers! Developers!
There is some truth in it. Despite it’s ludicrousness. But I’m not absolutely convinced. For future language reviews I will discuss this point in depth and decide based upon the completeness and maturity of standalone languages and the ease of using the existing Ecoverse from the new language. We will see how this sorts out.