Perl 6, 10 ans déjà…

Le 1er août 2000, 361 RFCs (Requests For Change), fruits d’un gros travail communautaire, étaient soumises à Larry Wall pour qu’il en synthétise la “substantifique mœlle”, qu’il nomma les Apocalypses.

Hier nous étions le 1er août 2010. Une décennie entière s’est écoulée, et faire un point (un bilan ?) semble plus que nécessaire. En dehors de son horrible logo nommé Camelia, que reste-t-il de Perl 6 ?

Alors que l’ancien interpréteur Perl était aussi la définition du langage, ce dernier n’ayant pas de spécifications différenciées de son implémentation, Perl 6 est lui un ensemble de spécifications, appelées Synopsys.

Tout compilateur, interpréteur ou machine virtuelle respectant ces spécifications, est Perl 6. Ainsi Pugs, écrit en Haskell, apparaît en 2005 comme une première implémentation complète de Perl 6.

Pugs profite de toute la puissance de ce superbe langage fonctionnel qu’est Haskell, qui a permis d’obtenir cette implémentation de Perl 6 utilisable pour des démonstrations, mais pâtit de sa contrepartie, une lenteur (difficile pour un compilateur d’optimiser quand tout est lazy-évalué) non compatible avec une utilisation réelle.

Il existe en fait une implémentation “officielle” de Perl 6. Elle se nomme Rakudo, et vient de sortir, il y a trois jours, sa première version pour les early adopters de Perl 6, Rakudo Star.

On comprend bien la volonté, pour les dix ans du projet, de montrer qu’il se passe quelque chose et que le projet n’est pas mort. Ce qui me gène dans l’annonce, ce n’est pas qu’il y ait encore des bugs, ou que ce soit plus lent que ça ne devrait, mais bien que there are some advanced pieces of the Perl 6 language specification that aren’t implemented yet. On est en fait encore très loin du compte, comme le montre le graphique suivant, sur l’évolution du nombre de tests réussis par Rakudo.

Le problème est en fait encore plus grave que cela, puisque les spécifications qui ne sont pas implémentées sont justement celles qui posent un problème d’implémentation. Il semblerait que la volonté de faire de Perl 6 “le langage parfait”, ait amené à une complexité très importante de sa syntaxe et de sa sémantique, et que sa réalisation pose de réelles difficultés.

Guido van Rossum a lui toujours fait attention à limiter Python à une grammaire qui lui permette d’avoir un parseur LL(1), et ce choix plus défensif ne semble finalement pas préjudiciable en pratique.

Pendant ce temps là les autres langages de programmation, et l’informatique toute entière, ont beaucoup progressé. Les améliorations fantasmées il y a dix ans sont-elles depuis longtemps dépassées par la concurrence ou au contraire justifient-elles toujours Perl 6 ?

De la même manière qu’une grande réflexion a eu lieu pour définir ce que pourrait être la syntaxe et la sémantique de Perl 6, une énorme réflexion s’est portée sur l’environnement d’exécution des programmes, et les choix d’implémentation.

Ainsi, la manière historique d’être multiplateforme, celle de Perl 5, était d’être écrit en C. Partout où un compilateur C fonctionnait, on pouvait compiler Perl et l’utiliser. La manière moderne de résoudre ce problème est de compiler du bytecode pour une machine virtuelle, et c’est à cette dernière qu’est déléguée la problématique réelle du support des différentes plateformes, c’est-à-dire en pratique être écrite en C .

La majorité des langages modernes ont fait ce choix, ayant chacun une machine virtuelle écrite pour lui, ainsi Java fonctionne sur la JVM de Sun et C# sur la CLI de Microsoft. Mais écrire une machine virtuelle complète et multiplateforme est un énorme travail, c’est pourquoi des langages comme Groovy ou Scala ont simplement choisi d’utiliser directement la JVM.

Perl 6 aurait donc pu utiliser la JVM, mais Java étant un langage statique, la JVM qui a été conçue pour lui ne semble pas être le meilleur choix pour un langage dynamique. On constatera cependant que Jython et JRuby sont deux réimplémentations parfaitement fonctionnelles de Python et Ruby, deux langages de programmation tout aussi dynamiques que Perl 6.

C’est ainsi que la décision a été prise d’écrire, en partant de rien, une nouvelle machine virtuelle plus adaptée, qui fut nommée Parrot. Parrot m’a toujours intéressé d’un point de vue technique, car c’est une machine virtuelle à registres, alors que toutes les autres machines virtuelles, à l’exception de Dalvik qui est utilisée par Android pour le Java, sont à pile (CPython, Perl 5, JVM de Sun, CLI, etc.).

Cependant, la vitesse fantasmée il y a dix ans d’une machine virtuelle à registres immature, peut-elle tenir la comparaison avec des machines virtuelles à pile parfaitement maîtrisées et optimisées depuis ? Comment ne pas penser au fameux débat noyau monolithique contre micro-noyau ? Parrot et Hurd, même combat ?

Cette situation qui dure a causé beaucoup de tort au langage Perl, qui était le premier langage libre largement diffusé et utilisé pour faire des scripts CGI. Il a été évincé du web “à l’ancienne” par PHP, et du web moderne par les frameworks comme Ruby on Rails et Django, écrits respectivement en Ruby et en Python.

Et cela ne risque pas de s’améliorer, car pour que des personnes utilisent vraiment Perl 6 pour développer des programmes, il faudra non seulement un Rakudo complet, mais aussi que les bindings pour les bibliothèques de programmation soient portés…

En terme de moyens, le développement de Perl 6 a bénéficié entre autres d’un don 200 000 $ de la part de Ian Hague, et le très brillant Patrick Michaud est salarié pour s’y consacrer à plein temps.

Mais le gros problème c’est que les choix technologiques, aussi intéressants soient-ils, sont si complexes qu’ils ont bloqué l’émergence d’une communauté de développeurs qui auraient donné une toute autre dynamique au projet.

Alors Perl 6 est-il mort avant même d’être né ?

C’est un question très dure, à propos d’un projet emblématique du logiciel libre et très intéressant techniquement, mais nous nous devons d’essayer d’apprendre de nos erreurs. Alors n’oubliez jamais : Keep it Simple, Stupid et release early, release often.