Perl pride ♥

Coucou !

Je viens de muter à la Bulac pour m’occuper du système de gestion des bibliothèques de l’établissement. Ce dernier tourne sous Koha, un logiciel libre écrit pour 27% en Perl. Le poste à la Bulac m’a attiré entre autres pour l’engagement de l’établissement dans le logiciel libre et pour la perspective de travailler sur Koha et de faire du Perl. Je pourrais décrire Perl comme je pourrais me décrire moi : d’aspect bordélique et joyeux, j’adore rendre service et je suis polyvalent. J’espère que vous entendez surtout du bien de moi :), en revanche je suis presque sûr que vous n’en entendez pas beaucoup de Perl. Comme on se ressemble lui et moi, j’ai envie de vous parler un peu de ce langage controversé et de mon expérience avec, sans trop rentrer dans les détails techniques.

Je me suis acheté un ordinateur en 2002 pour rédiger ma maîtrise d’histoire. J’ai passé beaucoup plus de temps sur l’ordinateur que sur ma maîtrise. Six mois plus tard, j’avais installé un Linux et je commençais à m’intéresser à la programmation. Perl était un des langages de programmation dont j’entendais le plus parler, il était encore très populaire. Beaucoup de moteurs de sites web étaient écrits en Perl, les programmes d’administration système des machines UNIX souvent aussi. Les hackers  de Perl étaient regroupés dans une communauté amusante dont le but principal semblait être de prendre du plaisir en travaillant.

En dix ans, Perl est devenu une bête noire dont il faut dire du mal. Il est de bon ton de faire une grimace quand on en parle. Si quelqu’un ose faire quelque chose en Perl, on peut lui demander de manière bien méprisante « pourquoi ne l’avez-vous pas écrit en Python ? ». Le programmeur Perl doit vivre dans la honte d’infliger son langage détestable qui complique la vie de tout le monde. Je l’ai moi-même bien intégré : je ne conseille pas Perl comme premier langage (plutôt Python ou Ruby), je ne conseille pas Perl pour commencer un projet (plutôt Python ou Ruby). Pourtant, il m’arrive de lire du Perl, reprendre du Perl, écrire en Perl, et chaque fois, je m’amuse beaucoup avec Perl. Dois-je avoir honte ? En fait, ça commence un peu à m’agacer. Je suis super content de faire du Perl, aussi content que si je devais utiliser Python ou Ruby. Bref, pourquoi Perl a décliné ? Pourquoi je l’aime bien quand même ?

Le déclin de Perl

Rejoignez la révolution glorieuse de Python.
Rejoignez la révolution glorieuse de programmation en Python.

Le déclin de Perl peut se comprendre par la longue pause que le langage a connu. En juillet 2003, la version 5.8 sort et Perl se met à stagner. Pour beaucoup, à l’époque, 5.8 était la dernière version de la branche 5 en attendant la sortie d’une nouvelle version majeure de Perl qui allait tout remettre à plat : Perl 6. Or Perl 6 resta longtemps à l’état de vaporware. Le langage tant attendu à l’époque est quasiment sorti dans l’indifférence. En se rendant compte que Perl 6 allait mettre du temps, le travail a repris sur la branche 5 et Perl 5.10 est sorti en 2007. Les quatre ans d’inertie ont je pense suffit pour que l’on s’intéresse plus facilement à d’autres choses et que Perl se laisse dépasser par de nouvelles modes et de nouveaux usages.

Les autres langages ont certainement profité de cette pause. Sur le web, côté serveur, PHP est devenu la référence pour développer des applications au début des années 2000. PHP ressemble beaucoup à Perl, en plus simple, et permet de programmer plus facilement un site. Les concurrents directs de Perl qui regroupent autant d’avantages en termes de fonctionnalités sont Python et Ruby. Ils ont été développés après Perl, en cherchant à éviter ses problèmes, voire pour Python en abordant un point de vue opposé1. Python ou Ruby ont une syntaxe qui paraît à beaucoup plus plus claire, plus accessible, moins anarchique et proposent tous les autres avantages de Perl2. Ils ont beaucoup gagné en popularité et sont assistés du côté de Python par des prosélytes vindicatifs3.

Le déclin de Perl s’explique enfin par la quête de la technique miracle qui permet qu’un projet ne se transforme pas en monstre incontrôlable4. Il faut trouver un langage qui permet : d’éviter de faire des erreurs, de développer un projet dans la durée, d’être facilement reprenable par d’autres programmeurs. Perl s’est taillé la réputation d’être très mauvais dans chacun de ces trois éléments. Les prosélytes de Python, Java, C# le reprennent comme un mantra, ce qui a sans doute permis à tout le monde de croire que c’était vrai. Ce prosélytisme virulent n’est pas dans la culture de Perl et de ses hackers, du moins je ne l’ai pas vu. Quelque part, en restant aimable et serviable, je trouve que Perl s’est un peu fait manger par les zélotes.

Mais alors pourquoi Perl ?

Avec tous ces défauts, et le problème social de passer pour un déviant, qu’est-ce qui fait que j’aime bien Perl ?

Perl est rigolo et sympa. Je ne sais pas si c’est parce que je suis nostalgique, mais j’ai un ressenti très particulier avec Perl. Je le trouve rigolo. Je trouve son créateur, Larry Wall, rigolo et vachement sympa. Perl, c’est des tas de gros gentils. Regardez le bandeau de Perl 6. J’en ai un peu marre de ce monde où l’on justifie les choses que l’on fait en disant que ça sera une révolution, que ce sera utile aux autres et que c’est très sérieux. Je n’arrive pas à être sérieux ou utile si je ne m’amuse pas. Perl assume totalement son côté fun, ce qui peut être très mal vu par les gens sérieux. Je m’en fous, je défends le fun, je suis là pour être heureux dans ce que je fais, marre du silice5.

Le papillon de Perl 6
Le papillon de Perl 6. Il est trop chou.

Perl sait faire plein de choses. On peut dresser une longue liste de fonctionnalités avancées du langage, on peut utiliser de nombreuses techniques ou paradigmes de programmation différents avec Perl6. Il m’arrive encore d’être coincé pour utiliser des techniques que j’aime bien avec d’autres langages7.

Perl a de super bouquins. Le Camel Book, le Llama Book, l’Alpaca Book sont très bien écrits et drôles. Le Llama Book est un de mes livres préférés d’initiation à la programmation. Je place Randal L. Schwartz au panthéon des grands écrivains de livres d’informatique aux côté de Brian Kernighan, Richard Stevens et Michael W. Lucas. L’Alpaca est sans doute un des livres avec lequel j’ai le plus appris en programmation, c’est grâce à lui que je peux apprendre d’autres langage facilement (ça a été le cas pour Python ou Ruby)8).

Perl sait être propre. On peut dresser le chameau. Je ne comprends pas les gens qui parlent de code illisible. Je n’ai pas de problème pour lire du Perl, je ne trouve pas ça plus compliqué qu’un autre langage que j’ai l’habitude de lire. Les styles de code proposés dans les livres cités plus haut et la documentation du projet sont très clairs et donnent d’excellents exemples à suivre, selon moi. Si vous avez besoin d’établir un code typographique pour vos programmes, vous pouvez vous inspirer de Perl Best Practices, mais c’est d’une manière générale qu’il faut faire attention au style. Je conseille à ce propos le premier chapitre de Practice of Programming par Kernighan et Pike9.

Perl est solide. La branche 5 de Perl fait quelque chose de très agréable que l’on a perdu de vue ces derniers temps : elle est activement développée tout en gardant une très bonne compatibilité avec les versions précédentes. Je n’ai jamais eu besoin de savoir quelle version de Perl tournait pour lancer une application. Je n’ai presque jamais eu de soucis de versions ou de problème de compatibilité entre versions avec Perl. Dans Coders at Work, Jamie Zawinsky dit qu’il méprise Perl, mais qu’il l’utilise parce qu’il est installé partout. La robustesse et la portabilité de Perl sont bien des qualités que n’ont pas beaucoup d’autres langages10.

Conclusion

Avec les langages de programmation, je suis polyamoureux. Le seul vrai reproche que j’ai à faire à Perl, c’est que maintenant que je vais en faire régulièrement, je risque d’entendre encore plus de reproches sur ce langage et pourquoi il est nul. C’est un peu vexant quand je souligne bien que j’aime le langage. En fait, c’est pour ça qu’en général je conseille Ruby ou Python, ça évite de se faire trop humilier. Bon, les haters seront toujours là pour vous humilier quand même. C’est fréquent dans la culture geek, on méprise facilement le langage et l’éditeur de l’Autre et on se recentre fièrement sur sa micro-communauté avec la certitude d’avoir raison11. Cependant avec Perl, je pense qu’on a passé un cap dans le milieu des années 2000, le cap qui permet de s’acharner dessus et que ça paraisse normal. Plus ça va, plus je trouve que le problème est social et non technique.

Quand Perl sera mort, le monde ne sera pas meilleur. Les systèmes informatiques continueront de planter. Les projets continueront à devenir des monstres incontrôlables. Le monde sera toujours plein de choses qui nous agacent. Nous râleront toujours en reprenant le projet de quelqu’un d’autre. S’attaquer à Perl est un faux problème. En fait, je regrette de m’être attaqué à d’autres langages de programmation par le passé (notamment PHP et Java), ça ne fait rien avancer, ça ne rend pas service, ça n’apporte rien à part éventuellement blesser des gens qui prennent plaisir à utiliser ces outils.

Heureusement, je ne pense pas que Perl meure si vite :). Je vais avoir une petite aventure plus intime avec lui dans les années qui viennent et je tiens à m’amuser ! Oui, j’aime Perl. Non, je ne suis pas un monstre qui participe à la destruction du monde. Oui je serai aussi super content si je devais bosser avec Python, Ruby, Clojure, Haskell, Erlang, C…  et je serai super content de retrouver ces langages dans mes projets futurs :). En attendant, je suis heureux d’avoir trouvé l’occasion de me remettre à Perl :).

J'aime Perl
Je viens de trouver ça sur un billet récent \o/.
  1. D’un monde où l’on considère que l’on peut faire une chose de plusieurs manières, on passe à un monde où il ne devrait y avoir qu’une manière parfaite de faire une chose. []
  2. Voir Why Python? D’Eric S. Raymond qui est sans doute un des points de départ les plus influents pour comprendre l’ascension de Python. []
  3. <ton_méprisant>Pouvez-vous expliquer pourquoi votre langue maternelle n’est pas le Python ?</ton_méprisant>. []
  4. Dans le monde informatique on parle de silver bullet. []
  5. Python s’appelle python en référence au Monthy Python et c’est sans doute la seule chose qui a un lien avec l’humour dans ce langage. Bon, c’est pas tout à fait vrai, je me suis vraiment bidonné en tapant « import antigravity » dans un REPL Python. J’exagère sans doute, je prends beaucoup de plaisir avec d’autres langages, mais je retrouve difficilement ce côté sympa. Alan Perlis a appelé à garder le fun qu’il y a à utiliser des ordinateurs, à ne pas devenir des vendeurs de Bible, j’aime bien cette idée. []
  6. POO, programmation fonctionnelle, curryfication, fermetures… []
  7. Comme l’autovivification, ou trouver facilement comment trier un hash en fonction des valeurs… []
  8. Le Learning Python d’Oreilly est catastrophique : veuillez attendre la page 393 pour apprendre à écrire une fonction… C’est d’autant plus étonnant que la documentation en ligne de Python est d’extrêmement bonne qualité. Je peux citer des tas de chouettes livres sur Javascript, Common Lisp, Erlang, C… Pas sur Java, Python, Ruby… Je ne parle pas de bons livres, je parle de livres qui changent la vie. Bon OK, c’est sans doute diablement subjectif :). N’hésitez pas à laisser en commentaire vos livres préférés de programmation qui ne sont pas sur Perl, j’irai les lire :). Pour la défense de langages comme Python ou Haskell, les langages eux-mêmes m’ont fait un effet wahou. Peut-être que dans ce cas il n’y a pas besoin de bonne littérature ? : []
  9. Beaucoup de langages se vantent d’une certaine pureté et clarté naturelle dans la manière dont on les écrit. C’est vrai que s’il paraît plus facile de faire un programme propre dans certains langages, la pureté ne m’impressionne pas et ne justifie pas que je préfère un langage à Perl (sauf Haskell. Haskell, tu me fous par terre.). []
  10. Qui c’est qui doit faire tourner une JVM 1.3 pour une bouze proprio en Java achetée très chère en 2002 ? Qui c’est qui doit trouver un Python 2.4 pour un vieux Zope ? Qui c’est qui ne doit trouver qu’une manière de faire quelque chose et qui doit hésiter entre optparse, getopt et argparse ? Qui c’est qui casse sa compatibilité tous les quatre matins ? Qui c’est qui pleure des larmes de sang pour gérer les dépendances de ses gems ? Qui c’est qui est bloqué sur une archi ou un système parce que le super langage trendy est un monstre à porter ? Qui c’est qui vomit partout quand on le compile en 64 bits ? []
  11. Il y a de nombreux pans de la culture geek qui m’agacent de plus en plus. []

Nicolas Legrand

Maîtrise d'histoire, DESS de compétence complémentaire en informatique, six ans à l'École nationale des chartes, trois à l'Observatoire de Paris-Meudon, à la BULAC depuis décembre 2013. Développeur Web, administrateur système et réseau, administrateur de système de gestion de bibliothèque.

More Posts - Website

Follow Me:
LinkedIn

Publié par

Nicolas Legrand

Maîtrise d'histoire, DESS de compétence complémentaire en informatique, six ans à l'École nationale des chartes, trois à l'Observatoire de Paris-Meudon, à la BULAC depuis décembre 2013. Développeur Web, administrateur système et réseau, administrateur de système de gestion de bibliothèque.

19 réflexions au sujet de « Perl pride ♥ »

  1. Je ne connais absolument pas Perl. En fait je suis un grand fan de Python, c’est le language avec qui j’ai le plus de plaisir à écrire avec SPIP, mais qui est un cas particulier (je connais peu de langage a vrai dire : PHP, Python, LaTeX et SPIP).

    Mais ce que tu décris là me fait penser aux genres de choses que l’on entend sur SPIP de la part de WordPressien ou de Drupalien : CMS obsolète, peu souple, peu lisible etc. Ce qui a mon avis est exactement le contraire.

    A mon avis tout ca sont des effets de mode et d’inculture, de personnes qui ne prennent pas le temps d’aller plus loin que la page d’accueil d’un projet (et j’ai eu la même tendance), et surtout qui évalue un projet … à l’aune d’une vieille version.

    Ps : je ne suis pas sûr que dans Python on pense qu’il n’y ait qu’une manière de faire les choses, même si on le répète comme un mantra. Après tout, on dit aussi en Python que les dev sont des grandes personnes et que le langage ne doit pas les contraindre

    1. Merci pour ton commentaire. Le moto de Perl, « il y a plus d’une manière de faire les choses », est souvent attaqué comme une des raisons qui font que le langage peut être facilement rendu peu accessible. Par exemple, je lis plutôt bien en anglais, mais il arrive que je tombe sur des romans avec un style et vocabulaire auquel je ne suis pas habitué et j’ai besoin de faire un effort de plus au début pour comprendre de quoi il s’agit. En fait, j’ai le même problème avec le français :). Bref, l’idée est de faire qu’une manière d’exprimer quelque chose soit unique afin de ne pas avoir à faire d’effort supplémentaire. Je trouve ça bien de faire ça au niveau d’un projet et quand un projet impose un style différent, et bien il faut s’adapter.

      Je suis d’accord avec le processus que tu décris. Je me demande dans quelle mesure ce n’est pas une forme de protection : on apprend un langage avec lequel on peut tout faire, on essaye d’éviter d’avoir à apprendre un autre langage, donc on pousse sur l’usage de celui avec lequel on est le plus à l’aise.

      En parlant de SPIP, le nouveau site de l’Observatoire de Paris a été monté avec. Nous avions des compétences en interne sur SPIP, et ces collègues n’avaient pas forcément le temps d’apprendre un nouveau CMS. Pourquoi se compliquer la vie quand SPIP rend très bien service et est toujours vivant ?

  2. Pour info, je crois que c’est trois fois le même lien pour « Le Camel Book, le Llama Book, l’Alpaca Book ».

    A part ça, très bon post :)

  3. Aaaah Koha! Aaaah Perl!
    J’espère que tu as bien attaché tes bretelles, il y a encore du travail dans Koha pour que la base de code soit belle/propre et que les autres développeurs de la communauté accepte les map et enlève les «foreach my $_» (petit clin d’œil aux anciens collègues).
    En tous cas, Koha, malgré l’usage obligatoire de l’ISO2709 à cause de ces satanés bibliothécaires, est un très bon logiciel comparé à ses concurrents, avec une communauté très agréable (re-clin d’œil aux anciens collègues).

    Concernant Perl, j’ai découvert plus en profondeur ce langage lorsque j’ai atterri dans le monde de Koha, et en fait je suis globalement d’accord avec toi, ce que j’aime beaucoup dans Perl c’est qu’il permet de comprendre/découvrir pleins de choses dont on n’avait pas forcément l’habitude de voir/utiliser avec d’autres langages plus «enterprise», découvrir est mon dada.

    En tous cas, bon courage pour tes péripéties autour de cette application et du monde des bibliothécaires, j’imagine te voir pointer le bout de ton nez sur #koha-fr@irc.freenode.org

    1. egrep -r ‘foreach +my +\$_’ * |wc -l
      0

      Bon ça a l’air d’être fait ça ^^. C’est marrant, ça me rappelle aussi Coders at Work : Brad Fritzpatrick a décidé de ne plus jamais utiliser ‘$_’ pour Livejournal parce qu’ils avaient passé des heures à débuguer des boucles imbriquées :).

      Oui, je m’attends plus ou moins à ça pour les bretelles, en fait, c’est un peu ce qui m’a attiré :). Je suis allé campé sur #koha-fr hier (nick npml, je viens de changer en nicolas_l pour faire plus couleur locale).

        1. Haaa. Du coup ça fera genre : je veux me faire embaucher par biblibre. Ça va faire jaser :).

          J’utilise massivement $_ dans les oneliner ou petits scripts avec opérateur diamant. Après, dès que j’ai des boucles imbriqués, je suis tout perdu :).

  4. Dans la note 1, “où l’on considère que l’on peut faire plusieurs choses de la même manière” — ne faut-il pas plutôt “qu’une même chose peut se faire de nombreuses manières” ?

      1. En fait, il faudrait même écrire “D’un monde où l’on considère que l’on *doit pouvoir* faire une chose, etc.”. En Python aussi il y a plein de manières de faire une seule chose, simplement toutes sauf une sont mauvaises.

          1. Je persiste à ne pas trouver la formulation très claire, mais effectivement je n’en ai pas de meilleure (ce sont des nuances bien subtiles…).

            Et pour la note 8 qui m’avait échappé: sur Java, j’avais adoré (il y a longtemps de ça), le Thinking in Java de Bruce Eckel. Pour le C++, The C++ Programming Language de Bjarne Stroustrup résume ma conception de la Parole Révélée, mais je pense que tout le monde le connaissait…

          2. J’avais laissé une dernière réponse qui a l’air de s’être perdue dans les méandres de l’antispam. Elle tenait en deux points:

            a) je suis d’accord sans être d’accord, mais je n’ai pas de meilleure formulation à proposer. (donc je fais comme si j’étais d’accord, mais je grommelle)

            b) en réponse à la note 8, sur Java j’avais adoré le Thinking in Java de Bruce Eckel, et en C++ la Parole Révélée est retranscrite par le Premier Apôtre dans Stroustrup: The C++ Programming Language, dont la 4ème édition de 2013 est un bonheur plein de fautes de frappe. Je suis pas certain que ça soit des livres qui « changent la vie », mais je ne suis pas certain que les livres de programmation changent la vie en vérité (ou alors, dans le mauvais sens)

            Je mets pas les liens cette fois ça a a l’air de faire paniquer la plateforme.

            1. Ha merci ! C’est marrant, C++ est justement aussi un langage qui se fait tailler régulièrement des costards. Je participais aussi au bashing, alors que je ne le connais pas du tout… J’ai récemment vu un copain se plonger avec plaisir dans le Stroustrup, ça m’avait donner envie d’y jeter un œil. :) Il faudra vraiment que je regarde à l’occasion.

              1. Hahaha mais c’est un bonheur le C++ ! Un bonheur de masochiste, mais un bonheur. C’est quoi les “arguments” du bashing ? (Je suppose que c’est un résumé de ses qualités : puissant donc complexe et relativement lent à compiler, polyvalent donc multiparadigmes donc pas forcément homogène et long à apprendre et à compiler, bas niveau donc pas pour les feignasses :-) et pas aussi évident à debugger)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *