Er zijn te weinig programmeertalen

Telkens wanneer een nieuwe programmeertaal wordt aangekondigd, klinkt er vanuit een deel van het kamp van developers een flinke zucht en licht gebrom: 'We hebben al zoveel om uit te kiezen...'

De nieuwste telg is Dart, de taal waarvan Google hoopt dat het JavaScript gaat vervangen. Was het echt nodig om een hele nieuw client-side taal voor het web te ontwikkelen? Dart lijkt op het eerste oog niet veel meer dan JavaScript met een aantal extra nieuwe functionaliteiten. Het compileert zelfs naar JavaScipt (alhoewel niet erg efficiënt). Had het geen slimmer idee geweest om het bestaande JavaScript verder te verbeteren?

Eigenlijk is Google daar met Dart ook mee bezig. Zij begrijpen dat een taal op een bepaald niveau van populariteit, niet zomaar overhoop gegooid kan worden om nieuwe functionaliteit, paradigma's en patronen te ondersteunen. Zoiets wordt heel erg lastig.

Het PHP6-debacle

Een goed voorbeeld daarvan is PHP. De laatste versie van deze populaire taal voor webapplicaties bracht deze week een 'release candidate' uit en levert volgend jaar een eindproduct op. Dit wordt dan niet het langverwachte PHP 6, maar een veel minder ambitieuze revisie in de vorm van PHP 5.4.

Ongetwijfeld is dit een grote teleurstelling voor de ontwikkelaars die al sinds oktober 2005 op PHP 6 zitten te wachten. Als er uiteindelijk toch een release uitkomt met de naam PHP6, zal deze weinig lijken op de versie die nu in ontwikkeling is. PHP-bedenker Rasmus Lerdorf zette het PHP6-project in maart 2010 officieel in de koelkast omdat er in vijf jaar tijd te weinig progressie was geboekt. De focus werd verlegd naar een formele PHP 5.4 release.

Bepaalde achterliggende redenen voor het mislukken van PHP6 waren technisch van aard. De primaire doelstelling was om PHP te 'retoolen' om native ondersteuning van Unicode mogelijk te maken. Dat zou niet beperkt worden tot het gebruik van strings, maar zelfs tot de mogelijkheid van het specificeren van namen van variabelen, functies en identifiers via ieder Unicode-script, waaronder ook complexe codings als het Chinees en Hindi. De jaren verstreken en vervelende obstakels bleven terugkeren; het werd duidelijk dat de PHP-community teveel hooi op zijn vork had genomen.

Het hielp niet dat het voornamelijk vrijwilligers zijn die aan het open-source PHP meewerken. Volgens PHP-vertegenwoordiger Andrei Zmievski, begrepen maar weinig developers waarom Unicode zo belangrijk was en was de animo om dit mogelijk te maken niet groot. Weinigen zagen het zitten om bergen werkende code opnieuw te schrijven voor de ondersteuning van Unicode, en het enthousiasme voor het project verdween geleidelijk. Toen PHP6 in 2010 werd geparkeerd, zei Lerdorf dat het werken aan PHP "al een tijd niet meer leuk was."

Talen evolueren, maar dat gebeurt heel langzaam

Zelf ben ik geen fan van PHP. Ik vind het al tijden een schoolvoorbeeld van slecht taalontwerp, dus het verbaast me niets dat het laten evolueren ervan in iets beters neerkomt op sisyfusarbeid. Maar ik zal niet alleen PHP als voorbeeld aandragen. Sterker nog, veel van de meer populaire talen hebben het afgelopen jaren moeilijk gehad met nieuwe versies.

Het beste voorbeeld is Perl, waarbij de community al sinds 2000 aan versie 6 werkt. In 2008 werd ik aangevallen door de Perl-gemeenschap omdat ik Perl 6 als 'vaporware' bestempelde. Het bestond wel degelijk, lieten ze weten en ik zou het vandaag gewoon kunnen gebruiken. Maar hoewel dat technisch klopt, is het de vraag of Perl 6 ooit volwassen genoeg zal zijn voor productie. Hoewel er verschillende implementaties zijn, waarvan sommige redelijk stabiel, ondersteunt geen van hen alle features van de Perl 6-specficatie.

De Python-community had meer geluk bij de implementatie van hun taal. De meest recente versie, Python 3, kwam in 2008 uit na drie jaar ontwikkeling. Drie jaar later valt de adoptie ervan echter tegen. Python 3 nam de radicale beslissing om te breken met backwards compatibiliteit met eerdere versies met als gevolg dat een aantal populaire Python-bibliotheken en frameworks (waaronder Django) nog niet bijgewerkt zijn. Hierdoor blijven veel ontwikkelaars hangen op versie 2.x en duurt het nog jaren voordat de massa overgaat op Python 3.

Dit soort problemen zijn niet enkel voorbehouden aan scripttalen. De Java-community worstelt ook al jaren met grote taalupdates. Tussen de lancering van Java SE 6 en 7 (uitgebracht eerder dit jaar) zat maar liefst vijf jaar. Maar ook van Java SE 7 werden oorspronkelijk zaken verwacht die Oracle pas in Java SE 8 op zijn vroegst kan doorvoeren.

Dart loopt vooruit op JavaScript

Gaan we weer terug naar Dart en waarom Google besloot een eigen taal te ontwikkelen in plaats van JavaScript te verbeteren. JavaScript is gebaseerd op de EMCAScript standaard. Voor de publicatie van EMCAScript 5 in 2009, was EMCAScript tien jaar lang niet aangepast - hiermee vergeleken lijkt de Perl-gemeenschap een broeiplaats van activiteit!

Het is niet dat de EMCAScript groep jarenlang heeft stilgezeten. Ook zij hebben jarenlang getwist over specificaties en releases in de koelkast gezet omdat ze te ambitieus waren.

De les van deze voorbeelden lijkt me duidelijk: Programmeertalen ontwikkelen zich traag en hoe populairder de taal is, hoe trager die ontwikkeling verloopt. Het is veel, maar dan ook VEEL makkelijker om een geheel nieuwe taal te ontwikkelen, dan om een bestaande gebruikersgroep te overtuigen van het doorvoeren van radicale veranderingen.

Val Google daarom niet aan op Dart. Als de community webdevelopers goed op Dart reageert, zal de taal uiteindelijk JavaScript vervangen. Aan de andere kant is het mogelijk dat een werkend prototype van Dart, Google de EMCAScript-werkgroep aanmoedigt om JavaScript sneller te laten evolueren. Wat de uitkomst ook wordt, nieuwe talen als Dart zijn een belangrijke motor voor de ontwikkelingscommunity en voorkomen stagnatie. Onthoud dat wanneer je jezelf weer afvraagt of we wel een nieuwe programmeertaal nodig hebben.