Why we need even more programming languages

Upgrading existing, popular languages to support new features is a lot harder than you might think

Page 2 of 2

The best example is surely Perl, whose community has been working on version 6 continuously since 2000. In 2008, the Perl community chastised me for suggesting that Perl 6 was "vaporware." It exists, they insisted, and you can use it today. But while that may be technically true, whether Perl 6 will ever be mature enough for production use remains an open question. Although several implementations are available, and some are even fairly stable, so far none of them supports all of the features of the Perl 6 specification.

The Python community has had better luck implementing its language. The most recent version, Python 3, was released in 2008, after about three years of development. Three years later, however, adoption remains slow. Python 3 took the radical step of breaking backward compatibility with earlier versions, and a number of popular Python libraries and frameworks (including Django) have yet to catch up. As a result, many Python developers still cling to version 2.x, particularly for Web work, and widespread migration to Python 3 is expected to take several more years.

These kinds of difficulties aren't limited to scripting languages, either. The Java community has long clamored for significant language updates. Before Java SE 7 shipped earlier this year, it had been five years since the last major release. But while Java SE 7 was originally expected to include much-requested capabilities such as lambda expressions and a module system, Oracle has since delayed those features until Java SE 8 at the earliest.

Darting ahead of JavaScript
All of this brings us back to Dart and why Google chose to invent its own language rather than working to improve JavaScript. JavaScript is based on the ECMAScript standard. Before the publication of the ECMAScript 5 specification in 2009, ECMAScript had remained unchanged for a full decade -- it made the Perl community look like a hotbed of activity!

Not that the ECMAScript working group had been idle throughout those years. Work on ECMAScript 4 began in 1999, but soon foundered and went on hiatus. The committee reconvened in 2003, but still the various stakeholders couldn't agree. Around and around they went for another five years, until -- much like PHP 6 -- the ECMAScript 4 effort was officially abandoned in 2008, in favor of a less-contentious specification that became ECMAScript 3.1.

The lesson from all of these examples is clear: Programming languages move slowly, and the more popular a language is, the slower it moves. It is far, far easier to create a new language from whole cloth than it is to convince the existing user base of a popular language to accept radical changes.

So don't knock Google for the work it's done on Dart. If the Web development community responds well to Dart, perhaps it will eventually replace JavaScript. On the other hand, it's possible that by creating a working prototype of Dart, Google will encourage the ECMAScript working group to evolve JavaScript more quickly. Either way, efforts like Dart are an important engine of progress for the software development community and a hedge against stagnation. Remember that the next time you ask whether we really need another new programming language.

This article, "Why we need even more programming languages," originally appeared at InfoWorld.com. Read more of Neil McAllister's Fatal Exception blog and follow the latest news in programming at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

| 1 2 Page 2