![[couverture de Linux Magazine 86]](http://www.ed-diamond.com/bigres/lmag86.jpg "Linux Magazine 86")
Article publié dans Linux Magazine 86, septembre 2006.
![[+ del.icio.us]](/images/add-to-delicious.gif)
![[+ Developers Zone]](/images/add-to-dzone.gif)
![[+ Bookmarks.fr]](/images/add-to-bookmarks-fr.png)
![[Digg this]](/images/add-to-digg.png)
![[+ My Yahoo!]](/images/add-to-myyahoo.gif)
Cette interview a été réalisée dans la nuit du 10 au 11 février 2006, dans la brasserie Au Trappiste, à Paris.
Rafaël Garcia-Suarez est le pumpking de Perl 5.9, le mainteneur d'urpmi chez Mandriva, et bien évidemment un mongueur de Perl, co-fondateur de Lyon.pm et actuellement membre de Paris.pm.
Entretien et transcription réalisés par Philippe Bruhat.
Bonjour, Rafaël. Tu es le « pumpking » de Perl 5.9, est-ce que ça veut dire que tu est aussi celui de Perl 5.10 ? Comment ça marche exactement, la différence entre la version de développement et la version stable de Perl ?
En fait, la version de développement, c'est beaucoup plus, comment dirais-je, c'est beaucoup plus bordélique. C'est aussi une version de test, donc on n'hésite pas à y mettre des choses dont on sait que ça va casser la compatibilité avec d'anciens modules, que ça va peut-être d'ailleurs casser les tests pendant un certain temps, quitte à les corriger ensuite. C'est un peu une version d'expérimentation.
Il y a beaucoup de personnes qui ont le droit en commit sur la version
de développement. À part moi, il y a Gisle Aas (LWP, HTTP::Parser),
l'un des gros auteurs de modules très très connus du
CPAN, Dave Mitchell et Steve Peters qui n'ont pas de module sur le
CPAN, mais qui connaissent très bien le noyau, Nicholas Clark...
On a aussi des spécialistes de plates-formes, comme
Steve Hay, qui commite tout ce qui est Windows,
et Craig Berry qui commite tout ce qui est VMS.
VMS, c'est quelque chose qui n'est pas très répandu chez les
Perl 5 Porters.
En gros, il y a beaucoup de commits, on s'organise bien, on discute sur irc ou par mail.
Par contre, la version stable, il n'y a absolument que Nicholas Clark qui commite dedans, et il sélectionne les patchs un à un très précisément, en laissant passer une semaine ou deux pour voir s'ils ne cassent rien dans la version de développement, en les ayant revus attentivement pour savoir quels étaient les impacts sur le langage au niveau API binaire, ainsi qu'au niveau langage lui-même.
La version stable est beaucoup plus stricte : il n'y a rien qui ne va dans la version de maintenance qui ne soit pas allé dans la version de développement avant.
Et à propos des gens qui ont le droit de commit, est-ce qu'il y a des gens d'ActiveState qui ont un accès en commit sur bleadperl ?
Oui, il y a Gisle Aas. Par cooptation, on lui a donné le droit de commiter des patchs. Parce qu'il en propose beaucoup, et qu'en général c'est quelqu'un qui connaît très très bien perl.
C'est d'ailleurs lui qui avait écrit IllGuts, Illustrated Guts, qui décrit en détail le fonctionnement des entrailles de Perl (http://gisle.aas.no/perl/illguts/).
Il y a d'autres documents sur les entrailles de Perl ?
Il y a perlguts(1), qui est une vraie page de man, ainsi que perlapi(1)
et perlintern(1) qui sont générées par des programmes à partir des sources
de Perl.
Comment est-ce qu'on devient pumpking ?
On devient pumpking parce qu'on est assez crétin pour pouvoir accepter
de faire ce boulot, en fait. :-) J'exagère à peine...
En fait on devient pumpking parce que d'une part on comprend comment fonctionne le noyau de Perl, et donc on a assez d'informations pour juger de tout ; et d'autre part on a la confiance du pumpking précédent, parce qu'on n'a pas proposé de trucs trop délirants, qu'on a fait des bonnes remarques du genre « non, telle modification va casser la compatibilité dans tel cas ». En gros, on devient pumpking parce qu'on respecte des règles...
Il faut bien connaître Perl, bien connaître les applications Perl, bien connaître la vie de Perl, parce qu'on peut pas aller faire comme dans Python où on casse la compatibilité, où on retire des trucs du langage. Ça c'est une chose qui n'arrive pas dans Perl. C'est assez pénible pour le pumpking de temps en temps, mais on ne vire pas des fonctionnalités du langage.
Sauf par exemples les...
Les pseudo-hashes, mais alors les pseudo-hashes c'était buggé et ça ralentissait tout. Alors bon...
Ça va vraiment disparaître.
Voilà. Mais faut savoir qu'un module comme fields.pm qui utilisait les
pseudo-hashes a été réimplémenté sans pseudo-hashes. Avec les mêmes
fonctionnalités.
En plus, il y avait plein de programmes normaux qui étaient buggés parce que les gens utilisaient des pseudo-hashes sans le savoir.
De toute façon, les pseudo-hashes ne s'en vont pas comme ça : il y a un cycle de deprecation, si on utilise des pseudo-hashes maintenant, il y a un warning... Comme tu vois, on fait attention.
Et puis les pseudo-hashes, ce n'est pas une nouvelle syntaxe, c'est juste des tableaux dont le premier élément est une référence à un hash. Ce n'était pas vraiment une nouvelle syntaxe, c'était une structure de données, qui a une interprétation spécifique. Et d'ailleurs ça se voit.
Pour revenir au rôle de pumpking, finalement, c'est le fruit d'une collaboration, un peu sur P5P et ailleurs, où finalement on finit par se faire connaître par sa participation, et à un moment donné, quelqu'un qui est un peu usé par son rôle de pumpking Perl dit « bon, je vais passer le relais » et il trouve quelqu'un qui est assez naïf pour accepter.
Voilà, en fait c'est ça. (rires)
Et toi, comment en es-tu arrivé là ?
Si je me souviens bien, j'ai eu le droit de commiter des patchs pendant le cycle de développement de Perl 5.7, qui allait devenir Perl 5.8.
Mais parce que tu faisais des trucs sur une plate-forme particulière ou quelque chose comme ça ?
Non, parce que je m'intéressais bien au parser, au tokenizer, à l'optimiseur, à la construction de l'arbre syntaxique et que j'avais soumis pas mal de patchs là-dessus pour corriger des bugs ou des choses comme ça. Et du coup, Jarkko [l'ancien pumpking] avait proposé de me donner les droits en commit, j'ai commencé à commiter mes patchs pour corriger des bugs et tout ça.
Ensuite, Hugo van der Sanden est devenu pumpking pour Perl 5.9.0,. Mais ensuite, Hugo a eu pas mal de choses à faire professionnellement, et il avait de moins en moins le temps pour remplir son rôle de pumpking... Finalement, c'est moi qui appliquais la plupart des patchs courants, et pour les grosses décisions, c'était Hugo qui les prenait. Mais comme il avait de moins en moins de temps, finalement il a fini par me passer le relais.
C'est vrai que ça prend quand même pas mal de temps. Pour un patch, il faut pouvoir dire tout ce qui se passe, le comprendre, l'analyser...
À un moment donné, tu avais aussi joué le rôle de summarizer pour P5P... Ça se situe à quel moment, ça ?
Il y a environ deux ans et demi que j'ai fait ça.
Et tu avais déjà les droits en commit et ce genre de chose ?
Non, quand j'ai commencé, je n'avais pas les droits en commit. J'ai fait ça parce que, quand j'ai commencé à lire P5P, c'était à cause des comptes-rendus de Simon Cozens, qui avait pris le relais de Mark-Jason Dominus. Et Simon avait arrêté, et je trouvais que c'était dommage, parce que je trouvais ces résumés intéressants à l'époque où je ne lisais que les summaries et que je ne suivais pas P5P de très près.
Donc j'avais fait ça toutes les semaines, et le fait de lire P5P et d'être forcé de comprendre tout ce qui s'y dit pour pouvoir faire un résumé correct m'a permis d'apprendre énormément de choses en un laps de temps assez court, finalement.
Je me demande si ce n'est pas la raison, ou une des raisons, pour laquelle David Landgren le fait actuellement, par exemple. Il a probablement envie de se rapprocher des entrailles de Perl.
Oui, c'est possible. En faisant ça, on apprend beaucoup de choses. Ça prend aussi du temps et de l'effort au début, parce qu'au début évidemment, on lit des mails avec des gros patchs qui parlent de choses dont on n'a jamais entendu parler, qui sont des structures internes de données. Et puis finalement on va voir dans le code de quoi est-ce que les gens causent, et puis on apprend...
Glossaire
(explication de quelques termes employés dans cette interview)
ActiveState : Société qui commercialise des outils de développement pour les langages dynamiques (Perl, Python, Tcl, PHP). Fondée par Dick Hardt en 1997, elle employait Gurusamy Sarathy (à l'époque pumpking de Perl 5.6). ActiveState maintient une des versions de Perl sous Windows les plus populaires.
bleadperl : La version de développement de Perl. Le terme vient d'un jeu de mot sur leading edge / bleeding edge. On peut récuperer les sources de bleadperl via rsync :
rsync -avz rsync://ftp.linux.activestate.com/perl-current/ .
pumpking : En deux mots, le release manager de Perl. Il y a un pumpking pour la version stable (Nicholas Clark), qui intègre certains patchs de la version de développement pour corriger les bugs, et un pumpking pour la version de développement (Rafaël Garcia-Suarez) qui intègre les nouveaux patchs et les nouvelles fonctionnalités, en préparation de la prochaine version stable (5.10).
p5p : La liste de diffusion des perl5-porters. Fondée à l'origine lors de la migration de Perl 4 à Perl 5, elle accueille aujourd'hui toutes les discussions liés à Perl 5 et bleadperl. C'est le lieu de travail du pumpking.
p5p summaries : Plusieurs personnes (Mark-Jason Dominus, Simon Cozens, Piers Cawley, Léon Brocard, Abhijit Menon-Sen. Rafaël Garcia-Suarez, Scott Lanning, Adriano Ferrero, David Landgren) se sont succédées au fil du temps pour écrire des résumés hebdomadaires de la liste, afin de la rendre plus accessible au commun des mortels. Les résumés (en anglais) sont accessibles sur http://www.perl.com/pub/at/4 (résumés de juin 2000 à octobre 2001) et sur http://dev.perl.org/perl5/list-summaries/ (résumés de juillet 2002 à aujourd'hui).
core : Le core de Perl, c'est l'ensemble des modules et programmes fournis avec le binaire de Perl, quand on l'installe depuis les sources.
Justement, ça fait plusieurs fois que tu dis que ça prend beaucoup de temps... Pumpking, c'est quasiment un boulot à plein temps.
Ça pourrait. C'est pour ça que j'ai quand même pas mal délégué...
Par exemple, tout ce qui est upgrade des modules qui font partie du core de Perl, qu'on appelle aussi les modules dual-life pour ceux qui sont aussi sur le CPAN, en général c'est Steve Peters qui s'en occupe. Parce que c'est relativement mécanique comme tâche, on va dire : il s'agit de remplacer les fichiers, de lancer les tests de régression, de vérifier aussi les diff...
Les modules qui sont déjà dans le core sont en général assez stables, donc il n'y a pas de gros changements qui se produisent.
Oui. Enfin s'agit aussi parfois d'aller voir les gens qui maintiennent les modules et de leur dire « on a des patchs qu'on a mis dans le core, et il faudrait les réintégrer dans la version du CPAN ». Il y a un aspect social, aussi. Un certain nombre de gens qui maintiennent sur le CPAN des modules qui sont dans le core, ne suivent pas P5P de près : il ne savent pas quand il y a des patches qui arrivent. Et puis ils retransmettent des patchs également.
Effectivement c'est un peu compliqué de suivre tout ça.
Parce qu'on n'a pas de système de gestion de version centralisé entre les auteurs de modules du CPAN et le core. Ils ont chacun leur petit CVS ou autre.
Et quand on réintègre des changements qui sont faits sur le CPAN, il faut vérifier que l'on n'écrase pas des changements qui ont été faits dans le core.
Oui. Et donc, ce boulot à plein temps... Toi, tu as déjà un autre boulot à plein temps. Ça se passe comment avec ton employeur ? Il te laisse le faire ?
Oui. Ben déjà chez mon employeur je suis un programmeur Perl. Les trois quarts de mon temps, je programme des applications qui sont en Perl, je package les modules Perl, je fais des rpm...
Bon, c'est pour Linux Mag, alors on va peut-être resituer l'employeur...
Mon employeur c'est Mandriva.
Tu étais déjà pumpking en arrivant chez Mandriva ?
Oui.
Donc ils savaient à quoi ils s'engageaient en te prenant.
Oui, tout à fait.
Mon rôle chez Mandriva : je maintiens plusieurs applications qui sont à la base du système, notamment Perl. C'est moi qui package ça pour Mandriva. Je maintiens RPM, ce qui implique aussi tous les patchs qu'on a sur RPM, et un solveur de dépendances pour RPM qui s'appelle urpmi, qui est écrit en Perl. Et puis je m'occupe aussi un peu de l'installeur de l'OS qui est lui-même écrit en Perl également.
Donc je fais beaucoup de Perl, et comme Perl est effectivement une chose très importante pour les outils développés à Mandriva, c'est important d'avoir quelqu'un qui comprend bien Perl, qui est capable de débugger Perl...
Donc finalement ils s'y retrouvent aussi.
Et comment ça se passe, on te dit « tu as tant de pourcent de ton temps que tu peux passer sur le core » ou est-ce qu'au lieu de faire des heures sup' sur urpmi tu fais des heures sup' sur le core de Perl ?
J'ai le droit de travailler sur Perl pendant mon temps de travail, comme j'ai le droit de travailler sur RPM, par exemple, je peux soumettre des patchs à RPM, parce que c'est mon boulot aussi.
Donc, je fais de la recherche et développement, s'il y a un bug dans RPM, que le corrige parce qu'il nous pose un problème pour la distribution, c'est mon travail. Pareil pour Perl.
Et comment ça marche d'ailleurs avec RPM ? Parce que RPM c'est un logiciel Open Source qui est géré par Red Hat ? Ou il y a deux versions, une version de RPM Red Hat et une version Mandriva ?
Bon alors là on est off-topic, mais le mainteneur de RPM a quitté Red Hat, il y a un an. RPM, ça voulait dire « Red Hat Package Manager », mais maintenant ça veut juste dire « RPM Package Manager ».
Donc c'est lui qui fait la version de développement, en ajoutant les trucs nouveaux dont il a envie, et puis les distributions qui utilisent RPM, elles rament un peu derrière, en gros. Que ce soit Red Hat, Fedora, Suse, Mandriva...
Finalement, ce n'est peut-être pas plus mal pour toutes les différentes boîtes qui font du Linux que ça ne soit plus dirigé uniquement par Red Hat, qui pouvait rajouter un peu ses trucs comme ils voulaient.
Je ne pense pas que c'était ça la situation, parce que même quand il était chez Red Hat, Jeff Johnson avait la haute main sur RPM, et il faisait ce qu'il voulait avec.
Récemment, j'ai vu que maintenant tu avais mis urpmi sur CPAN... urpmi c'était déjà Open Source avant ?
Ça a été GPL depuis le début.
Tout ce que je développe chez Mandriva, et tout ce qui est développé en interne chez Mandriva est GPL.
Ils n'ont rien de propriétaire, pas même l'installeur ?
L'installeur est GPL.
Je ne sais pas pourquoi, mais j'avais la notion que finalement la manière dont les distributions Linux se différenciaient, c'était peut-être justement sur des bouts de code qui n'étaient distribués qu'en binaire, sur certaines parties. Mais donc ce n'est pas du tout le cas.
Non, mais ce n'est parfois pas évident de reprendre du bout de code d'une autre distribution. L'installeur est très spécifique parce qu'il dépend aussi des conventions de nommage de tes paquets ; je sais que nous avons des patchs spécifiques dans RPM.
Mais par contre, avant c'était en GPL, mais ce n'était pas sur CPAN. Donc, ce que tu as fait, c'est de le mettre sur CPAN.
Avant c'était sur le CVS de Mandriva, qui est public, accessible en anonyme. Moi je l'ai mis sur CPAN parce qu'a priori, il n'y a rien qui dépend de Mandriva dedans. Je connais des gens qui utilisent urpmi sur Red Hat, par exemple, et ça marche. Il faut un rpm relativement récent pour avoir toutes les fonctionnalités. Mon but à moi en le mettant sur CPAN, c'est qu'il y ait des gens qui l'utilisent sur d'autres distributions.
Enfin, d'autres distributions à base de RPM.
Oui, bien sûr.
C'est pas demain que ça tournera sur Debian...
Théoriquement, c'est possible. Il faut juste écrire des bindings RPM... Il y a une couche de bindings RPM, qui sont tous à peu près compatibles au niveau de l'API.
Ce que tu es en train de dire, c'est qu'à la limite, sous réserve de la couche de code qui manque, on pourrait installer des .deb avec urpmi. Non, quand même pas. C'est plutôt qu'on pourrait installer des .rpm sur une Debian.
À partir du moment où on installe rpm sur Debian, il n'y a pas d'objection à installer urpmi sur Debian. urpmi, c'est quelques lignes de Perl, un peu de XS...
À propos de perl-base, à un moment donné, on parlait, je crois que les gens
de BSD en parlent aussi, de faire un Perl light, parce que Perl c'est
quand même un gros truc, parce qu'il y a plein de vieux modules, comme
CGI qui ne sont pas forcément nécessaires pour tout le monde, qui ne font
pas partie de la fonctionnalité de base, et en même temps il y a plein de
modules qui n'y sont pas et plein de gens qui ne peuvent pas vivre
sans, genre LWP ou des choses comme ça. Et régulièrement, il y a des
discussions sur le Perl minimal qui permet de faire juste des scripts,
à la limite sans aucun use, le Perl standard tel qu'on le connaît
aujourd'hui, et puis un Perl étendu, de FAI ou de fournisseur de services...
Est-ce que c'est toujours un projet en cours ? Est-ce qu'il y a des gens qui s'y intéressent ? Ou bien est-ce que c'est un serpent de mer qui ressurgit régulièrement ?
Il n'y a pas vraiment de projet en cours. C'est quelque chose d'intéressant,
de faire une distribution perl-base, comme c'est aussi intéressant
de faire un gros bundle Perl avec tous les modules un peu à la mode
du moment.
D'ailleurs la Perl Foundation a sponsorisé un projet de faire un bundle contenant des modules certifiés comme marchant ensemble et avec telle version de Perl. Ça c'est un truc qui est prévu sur le CPAN, mais ça ne vient pas pour l'instant.
Et sinon, pour faire un Perl de base, je sais que par exemple, chez Sun ils en ont un, parce qu'ils l'utilisent aussi dans le processus de build de l'OS. Ils ont des scripts Perl pour rebuilder Solaris, et ils l'utilisent très peu.
Ils utilisent juste le langage, et pas de module.
Et en fait on se rend compte qu'on a besoin d'assez peu de choses en
dehors de perl. Il y a certains modules qui peuvent être chargés
dans Perl sans qu'on le sache, comme Errno par exemple, ou Fcntl,
puis il y a les modules PerlIO.
Mais en gros, on peut faire un perl-base vraiment très petit, même
sans strict et warnings. Bon, on perd un peu d'intérêt parce que
ce sont des librairies qui sont quand même très liées au core, et que ça n'a
pas vraiment de sens à les distribuer séparément. Mais au moins si on les
conserve et qu'on vire tous les modules qui sont déjà sur le CPAN et qui
ne sont pas très liés au core, on peut avoir quelque chose de très petit.
L'exécutable de Perl, enfin si on regarde le binaire perl, ça fait combien, un méga, deux mégas ?
Alors ça, je n'en ai absolument aucune idée. Parce que déjà ça dépend de plein de facteurs... Ça dépend de, est-ce que le binaire est stripé ou pas, est-ce qu'on utilise la librairie libperl.so ou pas...
Ce que je sais, c'est que Nicholas Clark, depuis assez longtemps d'ailleurs, a fait un gros travail de refactorisation de code et de simplification, et que dans les dernières releases de Perl, la taille de l'exécutable, avec les mêmes options de compilation, diminue régulièrement.
Donc la taille de Perl en mémoire diminue.
En gros aujourd'hui, chacun fait un peu son perl-base dans
son coin, Sun a le sien, Mandriva a le sien, Debian a le sien aussi...
Les bugs dans Perl sont...
Les bugs dans Perl sont d'abord corrigés dans Perl 5.9.
Puis les patchs sont backportés dans Perl 5.8 par Nicholas, qui s'assure que ça marche bien, et qu'on garde la compatibilité binaire, et ce genre de chose.
Oui. D'ailleurs il y a des bugs qui ne sont pas corrigés dans 5.8 et qui sont corrigés dans 5.9, parce qu'ils vont par exemple casser la compatibilité binaire, ou parce qu'ils marchent sur certaines plates-formes et pas d'autres, etc.
Tout à l'heure on parlait des plates-formes... Entre VMS, Sun et les autres, est-ce que P5P a accès à des machines dans toutes les architectures ? On dit Perl est porté sur je ne sais pas combien de dizaines d'architectures et de systèmes. Est-ce que quand vous sortez un 5.8.8, comme récemment, vous l'avez testé sur toutes les plates-formes, ou...
Pas toutes, mais on l'a quand même testé sur un nombre assez impressionant de plates-formes.
Elles sont où, toutes ces plates-formes ? Je veux dire, est-ce qu'il y a quelqu'un qui a tout ça dans son garage, ou bien est-ce que c'est réparti dans le monde ?
C'est réparti, évidemment. Il y a les gens qui suivent P5P et qui ont des plates-formes chez eux, où on a des tests très réguliers. Donc là, c'est Linux, Solaris, AIX, HP-UX, VMS, Windows, et plusieurs versions de tout ça. Pour Mac OS X, aussi. Pour à peu près tout ; ce sont des OS assez courants, finalement.
Et de temps en temps, on a aussi des tests sur des OS moins répandus : z/OS, Tru64, d'autres systèmes sur RISC, des Cray, des Amiga... Bon Amiga, je crois que ça prend trop de temps, maintenant.
C'est vraiment une trop vieille machine...
Voilà. C'est vrai que des tests sous LinuxPPC, par exemple, on n'en a pas beaucoup...
5.9, c'est donc la version de Perl qui prépare 5.10.
Oui.
Est-ce qu'on a des dates ?
On n'a pas de dates, parce qu'on est Open Source, mais on a une roadmap.
C'est une roadmap qui est accessible dans la page de man perltodo(1)
sur Perl 5.8.8. Et comme Perl 5.8.8, c'est récent, cette liste est à jour.
C'est ce qu'il faut faire en gros pour 5.9.4, 5.9.5, 5.9.6, et a priori il n'y aura pas de 5.9.7.
Donc on est déjà à mi-chemin, quoi.
Voilà. Sachant que 5.9.6, dans mon esprit, c'est une Release Candidate, et qu'on ne mettra pas de nouvelles choses dedans.
5.9.6 aura déjà tout. Ce qui évolue entre 5.9.6 et 5.10, c'est correction de bugs, portabilité et ce genre de choses.
Et au niveau des délais, comment ça marche ? Parce que typiquement, récemment, quand Hugo était trop occupé pour s'occuper de bleadperl, ça a un peu glissé... Mais quand on regarde 5.8, Nicholas à un moment donné disait « je vais faire une distribution tous les 3 mois ». Je ne sais pas s'il arrive à tenir ça exactement ou pas, d'ailleurs.
Il n'a pas tenu ça pour 5.8.8, mais peut-être qu'il n'y avait pas tellement de choses à faire non plus. C'est une version quand même très stable, et il n'y avait pas d'urgence...
Et toi, pour par exemple 5.9.4, est-ce que tu as déjà une idée à peu près de quand ça va sortir ? Enfin, à la louche. Est-ce que c'est quelques mois, ou plus ?
Non, pour moi c'est quelques mois. Il y a quelques mois entre chaque release à venir.
Donc, il en reste trois, trois fois quelques mois, ça fait... 5.10 c'est pour 2007 ?
Ensuite, c'est vrai qu'on n'est pas beaucoup à travailler sur Perl, donc ça dépend pas mal de la disponibilité de chacun.
C'est vrai qu'on essaye de rendre Perl plus rapide et moins gros. Mais réduire la taille de Perl...
Je me souviens de YAPC::Europe à Munich en 2002 où Hugo avait fait une présentation dans laquelle il avait dit « 5.10, ce sera : rien de plus, mais plus rapide ».
Alors que finalement non.
Finalement, il y aura plein de trucs en plus, quand même. Il y a au moins le defined-or.
Il y a pas mal de choses qui viennent de Perl 6. Il y a le
defined-or (c'est-à-dire l'opérateur //), il y a le given
(l'équivalent du switch de C, en beaucoup plus puissant) et le
smart-match (c'est-à-dire l'opérateur ~~), qui vont à peu près
ensemble.
Il y aura le given et le smart-match de Perl 6 ? Wahou...
Ça marche déjà en 5.9.3, hein. Vous installez 5.9.3 depuis CPAN, vous avez le smart-match.
Et les arguments explicites, nommés et compagnie ?
Ah non, faut pas délirer non plus.
Dommage. (rires)
Il y a say(), c'est important. C'est un truc qu'on a du mal à faire
tout seul, en plus... ;-)
Et cowsay() ? (rires)
Non, say(). (rires)
Donc tout ça c'est 5.10, d'accord. Mais depuis le temps, est-ce que Perl 5.10 va servir à quelque chose ? Parce que Perl 6, c'est pour bientôt, non ?
Mon avis personnel, c'est que les deux langages vont évoluer parallèlement pendant un certain temps. Ils vont vivre pendant une bonne dizaine d'années.
Tu penses que Perl 5 en a encore pour dix ans tranquille ?
Tranquille. Avant qu'on déploie en production du Perl 5 qui tourne sur du Perl 6 via un émulateur ou un traducteur, à mon avis il y aura du temps.
C'est vrai que je connais des gens qui maintiennent des machines qui font tourner du Perl 5.4. Ou une boîte qui récemment, avait besoin de traduire des script Perl 4 en Perl 5.8.8... un saut de douze ans d'un coup. Apparemment, c'était suite à une migration d'un Unix vers un Linux, et ils se sont rendus compte que le Perl de Linux n'était pas le même que celui de leur Unix auquel ils n'avaient pas dû toucher depuis un bon moment... (rires)
Bref, il y aura un Perl 5.12 sans problème d'après toi, voire même un Perl 5.14 ?
Glossaire
(explication de quelques termes employés dans cette interview)
Haskell : Langage de programmation fonctionnel pur et paresseux (le site d'Haskell dit même polymorphicly typed, lazy, purely functional language). Le tutoriel d'Haskell indique que la meilleure manière d'apprendre Haskell est d'implémenter un langage de programmation avec. C'est ce conseil qu'a suivi Audrey Tang en en écrivant en février 2005 un compilateur Perl 6 en Haskell, à partir des spécifications publiées.
Pugs : Perl 6 User's Golfing System. Il s'agit de l'implémentation de Perl 6 en Haskell démarrée par Audrey Tang. Pugs sait aujourd'hui compiler du Perl 6 vers des backends Perl 5, JavaScript...
ghc : Glascow Haskell Compiler, une des implémentations d'Haskell. C'est celle qu'a utilisée Audrey Tang pour implémenter Pugs.
svk : svk est un programme de gestion de sources (comme CVS ou Subversion) avec un algorithme de gestion de branches très élaboré (star-merge) qui permet de travailler sur des branches locales, sans être connecté au réseau. svk est écrit en Perl et s'appuie sur le système de fichiers de Subversion.
Ça je ne sais pas, je ne peux pas dire si on continuera à faire du développement et à ajouter de nouvelles choses. Par contre, je pense qu'il y aura des versions de maintenance de 5.10 pendant un certain temps.
D'une part il est prévu de faire tourner du Perl 5 sur Parrot, compatible Perl 6 avec Ponie. D'autre part il est prévu de faire un traducteur Perl 5 vers Perl 6.
Le but à court terme est d'utiliser Perl 5.9 comme backend de Pugs, l'interpréteur Perl 6 conçu par Audrey Tang, qui sert de bootstrap à Perl 6.
Donc aujourd'hui, apprendre Perl 5, ce n'est pas du tout un mauvais choix ? On ne peut pas se dire « Oh non, je ne vais pas apprendre Perl 5, parce que de toute façon Perl 6 sort dans un an et demi. ».
On ne peut pas dire que c'est moribond.
Même s'il n'y a pas beaucoup de monde qui travaille dessus, il y a du monde qui travaille.
À mon avis, le changement va être complètement différent du changement entre Perl 4 et Perl 5, parce que Perl 5 a été fait pour être complètement compatible avec Perl 4. Enfin pas complètement, il y a des incompatibilités... Mais en gros, un script Perl 4 tournait en Perl 5 sans problème. Ce qui ne va pas être le cas pour passer de Perl 5 à Perl 6.
Ça dépend, si Larry fait son traducteur Perl 5 vers Perl 6, qu'est-ce qui empêche les gens de continuer à programmer en Perl 5 et de finalement faire tourner leurs scripts sur un binaire Perl 6 ?
Mais est-ce que les gens auront confiance en un traducteur de Perl ? Quand ils ont plein de modules XS qu'ils ont fait chez eux ?
C'est ça qui fait aussi que Perl 5 va devoir continuer à vivre, parce qu'il y a des gens qui vont dire « Je ne peux pas passer en Perl 6, parce que mon XS, je ne vais jamais le traduire pour ça. ».
Exactement.
Et comme langage, c'est intéressant, Perl 6 ? C'est bien ? Tu le conseilles ? Parce que là, tu es en train de me dire « Bon, ne vous inquiétez pas pour Perl 5, vous pouvez l'apprendre aujourd'hui et ça vous servira encore un bon moment », mais est-ce qu'aujourd'hui c'est intéressant de regarder Perl 6 et de le considérer comme un langage complètement différent de Perl 5 et de faire d'autres choses avec ?
C'est vrai que je le considère comme un langage séparé, et moi j'aime les langages de programmation parce que je m'amuse en programmant avec. Parfois je m'amuse encore en programmant en Perl 5, mais peut-être que je connais trop bien Perl 5 pour m'amuser vraiment avec.
Récemment, j'ai testé Catalyst et je me suis beaucoup amusé avec,
parce que Catalyst utilise deux features
de Perl que j'ai rarement vues utilisées ailleurs, c'est NEXT (la
classe NEXT de Damian Conway, pour faire du dispatch sur des arbres
d'héritage) et les attributs de fonction.
En gros, pour matcher une fonction sur une URL dans un cycle de requête,
tu écris sub tafonction :global { ... }, ça veut dire qu'elle va
être exécutée pour toute requête qui contient le nom de la fonction dans
l'URL à la base. local, ça veut dire qu'elle va être exécutée pour
toute URL qui contient le nom de fonction précédé du nom de paquet
avec les :: transformés en /. Ou alors tu as l'attribut :regexp
avec entre parenthèses une regexp, et donc si la requête matche la
regexp, la fonction va être utilisée.
Mais comme le dispatch est fait par NEXT et pas par SUPER, ça
s'empile, donc tu peux empiler les fonctions pour faire une même page.
Tu vois, c'est super agréable à utiliser. Or, des attributs de fonction
comme ça, et du dispatch par NEXT, je ne vois pas d'autre langage
permette d'utiliser ça aussi facilement.
Ça marche comment exactement, les attributs ?
La syntaxe est simple : sub toto :identificateur (chaine) { ... }.
La chaîne de caractères entre parenthèses est optionnelle. Et ensuite
tu définis dans une classe dont ça hérite un attribute handler, qui
va dispatcher selon le nom de l'attribut, les paramètres de l'attribut
il va en faire quelque chose et donc ça va appeler en gros une callback.
Ce sont des paramètres qui sont définis à la compilation, en gros. En terminologie Perl 6, on parlerait de traits.
Ce sont quand même des choses qui ne sont pas récentes dans Perl. C'est bien stable dans Perl 5.8, et ça date de 5.6.
Il y a des attibuts qui existent dans Perl, comme :lvalue, mais
on peut définir ses propres attributs. Pour bien comprendre, il faut
lire la documentation de Attribute::Handlers, tout est expliqué
dedans.
Je viens d'expliquer Catalyst en deux mots, mais tu vois que c'est différent
de la programmation Perl 5 « normale », use CGI;, etc.
En Catalyst, tu définis une fonction :global, par exemple, tu lances
un script qui t'a été généré automatiquement quand tu as créé ton application
Catalyst, tu lances ton browser, et t'as ta page.
Catalyst c'est vraiment un avant-goût de Perl 6.
D'ailleurs, j'ai déjà codé des petits scripts en Perl 6, en utilisant Pugs et je me suis beaucoup amusé finalement.
Est-ce que Pugs est packagé par Mandriva ?
Oui.
On peut faire urpmi pugs et ça marche ?
Ça veut dire qu'il y a un mec qui a fait un paquet pour ghc ? Comment il s'appelle ? (rires)
Oui, c'est moi. En fait, j'ai voulu faire un paquet pour Pugs, et puis donc du coup je me suis retrouvé à faire un paquet pour ghc, ce qui veut dire que je l'ai fait en deux fois, parce qu'il faut le bootstraper. Effectivement, j'ai packagé Pugs pour Mandriva.
Sous Debian, pour compiler Pugs à un moment donné, il fallait aller chercher ghc dans experimental. Parce qu'Audrey a utilisé des trucs de ghc tellement récents que ce n'était même pas dans le ghc de la Debian unstable.
Pugs est disponible sur les miroirs pour Mandriva 2006, par exemple. Par contre ce n'est pas la dernière version de Pugs. Pour la dernière version de Pugs, faut la dernière version de Mandriva, la version de développement. De toute façon, la dernière version de Pugs est sortie, quoi, il y a quinze jours.
Ça met deux heures à compiler... par contre, j'ai viré tous les .hi du rpm. Parce que les .hi ça ne sert qu'à ceux qui insèrent les bindings Haskell directement sur Pugs. Ceux qui font ça, en général ils se compilent leur Pugs eux-mêmes.
J'avais remarqué que tu t'intéressais beaucoup à Subversion, à l'époque où ce gestionnaire de sources n'était pas encore à la mode. Est-ce que tu as des choses à dire sur Subversion ? Quel est le système de gestion de sources de Perl ?
Moi personnellement, dans mon travail, pour mes projets, j'utilise svk.
Le système de gestion de version de Perl c'est Perforce, depuis la version 5.002 ou 5.003.
Qui est-ce qui a amené Perforce ?
Malcom Beattie, qui était pumpking à l'époque.
Aujourd'hui les sources de Perl sont chez ActiveState, qui doit payer la licence, car c'est un logiciel propriétaire.
ActiveState utilise Perforce en interne de toute façon.
Mais Malcom Beattie n'était pas chez ActiveState ?
Non. Mais l'historique des versions est géré chez ActiveState depuis le début. Je ne sais pas trop, il faudrait demander à Dick Hardt (le fondateur d'ActiveState).
Je sais qu'à l'époque ils avaient pris Perforce parce que CVS n'était pas assez puissant pour gérer des branches. Perforce sait faire des commits atomiques sur plusieurs fichiers, il sait faire des intégrations entre branches relativement intelligemment, des trucs que Subversion sait faire aujourd'hui et que CVS ne sait pas faire. Il sait aussi déplacer ou renommer des fichiers, ce genre de choses, quoi.
C'est vrai qu'il y a un projet pour passer tout ça sous Subversion. Sauf que ça fait quand même un certain nombre d'années d'historique.
Ça va être un gros script Perl pour la migration...
Perl ou Python, d'ailleurs ? Les développeurs de Subversion ont l'air de préférer Python, car cvs2svn est écrit en Python.
Perl. C'est moi qui l'ai écrit, le script en question.
Donc perforce2svn sera écrit en Perl.
Il y a un perforce2svn spécial pour Perl, qui se trouve sur le CPAN,
c'est moi qui l'ai écrit en premier, mais c'est Andreas König qui le
maintient, maintenant. Il s'appelle Perl-Repository-APC. APC signifie
« All Perl Changes ».
J'ai écrit ça parce que j'avais accès au dépôt Perforce, et qu'à côté je voulais un dépôt Subversion pour pouvoir bosser en local sur un portable. À l'époque il n'y avait pas encore svk. Donc j'avais tout mon historique, je pouvais faire des diff, des commit en local, et ce genre de choses, sans avoir besoin d'être connecté au réseau.
C'était pas très long à faire, mais par contre on a 28000 révisions, donc ça prend quand même beaucoup de temps et d'espace pour tout importer sous Subversion.
Il existe un repository svn qui contient tout l'historique de Perl, mais il est encore beta.
Donc le saut va se faire à un moment donné... Et c'est hébergé où, ce dépôt Subversion ?
Au début, la machine profane des Mongueurs de Perl devait
servir à ça, mais Robert Spier, qui gère svn.perl.org préfère faire
ça sur ses machines en local. C'est lui qui gère le svn où sont les sites
de perl.org, où il y a aussi Parrot, et ce genre de projet.
Et ça va se faire à un numéro de révision tout rond ? ou premier ?
Je ne pense pas. Aux alentours de 30000, peut-être.
À propos de perl.org et de la Perl Foundation, quels sont les liens entre
P5P, le pumpking, la Perl Foundation ? Il y a des liens parce que les
gens se connaissent, mais est-ce qu'il y a des liens formels ?
Il n'y a pas de lien formel, non. P5P c'est un peu une entité à part. Disons qu'on bosse sur Perl 5, Perl 5 est un logiciel copyright Larry Wall, Larry Wall lui-même n'a pas lien spécial avec la Perl Foundation. Il n'a pas de poste officiel à la Perl Foundation.
C'est encore copyright Larry Wall, alors que ça fait très longtemps qu'il n'a pas commité quelque chose dans Perl. Larry Wall a créé Perl 5, puis assez rapidement, c'est passé aux porters, et maintenant ...
Oui, mais tu ne peux pas changer un copyright holder comme ça. Quand les gens proposent des patches, ils donnent leurs droits au copyright holder légalement, d'après la licence.
Si vous prenez les sources de Perl et que vous regardez dans regexec.c, vous verrez que ce n'est pas copyright Larry Wall, mais copyright Henry Spencer.
Ah oui, la librairie de regexp qui est apparue en Perl 2. Il n'a donc pas lâché son copyright pour la libraire de regexp.
Non, je pense que Larry ne lui a jamais demandé.
Peut-être qu'il a eu peur qu'Henry Spencer voit ce qui a été fait avec sa librairie ! (rires)
Pour conclure, tu as un message pour les lecteurs de Linux Magazine, pour l'humanité ?
Je dirais que Perl se porte assez bien. Finalement, le noyau de Perl, ce n'est pas si important que ça. Parce que ce qui fait bouger Perl, en gros, ce sont les applications qui tournent dessus. On parlait de Catalyst tout à l'heure : Catalyst c'est un truc qui exploite des fonctions qui sont dans Perl depuis Perl 5.6, finalement, et qui n'avaient jamais été exploités à fond jusque là. Avec Perl, on peut faire des choses qu'on ne peut pas faire dans la plupart des autres langages que je connais.
C'est plus cela qui fait vivre Perl, toute la communauté du CPAN, que le petit noyau des Perl 5 Porters qui finalement améliore un interpréteur, et rajoute deux-trois trucs dans le langage. Ce n'est finalement pas tellement important et indispensable.
En clair, ce n'est pas l'interpréteur Perl qui fait que Perl continue d'être populaire et utilisé. C'est tout ce qu'on fait avec et notamment sur CPAN.
Merci beaucoup, Rafaël, de cette interview et de cette conclusion sur Perl.
Ça m'a donné soif de parler pendant une heure. :-)
![[IE7, par Dean Edwards]](/images/ie7.gif)
![[Validation du HTML]](/images/xhtml.gif)
![[Validation du CSS]](/images/css.gif)
Copyright © Les Mongueurs de Perl, 2001-2011
pour le site.
Les auteurs conservent le copyright de leurs articles.