J’ai fait cette traduction, vous pourrez trouver l’article d’origine ici.
Pourquoi Python ?
Par Eric Raymond
Le cardinal Biggles a gardé Eric au confessionnal pendant quatre heures avant d’entendre cette confession…
La première fois que j’ai dû me pencher sur Python… c’était par pur accident. Et je n’ai pas vraiment apprécié ce que j’ai vu à ce moment là. C’était début 1997, et le livre sur la programmation Python de Mark Lutz (O’Reilly & Associates) venait tout juste de sortir. Parfois les livres O’Reilly arrivent sur le pas de ma porte, en suivant un processus complètement aléatoire pour lequel j’ai abandonné tout essai de compréhension.
L’un deux était « Programmation Python ». Comme je collectionne les langages de programmation, j’ai trouvé cela intéressant. Je connais déjà une bonne douzaine de langage génériques, j’ai écrit quelques compilateurs et des interpréteurs pour le fun, et j’ai déjà designé quelques langages qui avaient des objectifs spécifiques et qui devaient suivre un certain formalisme. Récemment j’ai d’ailleurs écrit SNG, un langage écrit spécifiquement pour manipuler des images PNG (Portable Network Graphics). Les lecteurs intéressés peuvent regarder la page en question ici : http://www.catb.org/~esr/sng/. J’ai aussi écrit quelques implémentations de vieux langages, vous pouvez voir ça sur ma page du musée de la rétro-programmation (« Retrocomputing Museum page ») ici : http://www.catb.org/retro/.
Concernant Python, j’avais juste entendu que c’était un langage de « scripting », donc un langage destiné à écrire des scripts, avec son propre gestionnaire de mémoire intégré, et de grandes facilités pour appeler et coopérer avec d’autres programmes. Je me suis donc plongé dans « La Programmation Python » avec une idée bien précise en tête : que fait Python que Perl ne peut pas faire ?
Perl, bien sûr, était le poids lourd des langage modernes de scripting (NDT : c’était en 2000). Il est souvent devenu le langage de prédilection pour les administrateurs système en lieu et place du langage de scripting shell, souvent grâce à sa librairie UNIX et ses appels système, et aussi grâce à sa collection énorme de modules Perl construits par une communauté Perl très active. En 2000, ce langage est estimé être à l’origine de 85% du contenu « live » que l’on peut trouver sur le Net. Larry Wall, son créateur, est souvent considéré, à juste titre, comme l’un des leaders les plus importants dans la communauté Open Source, et apparait souvent en troisième place derrière Richard Stallman, et Linus Torvalds dans le panthéon des hackers demi-dieux.
A cette époque, j’avais utilisé Perl pour plein de petits projets. J’avais trouvé ce langage assez puissant, même si la syntaxe et quelque autres aspects de ce langage semblaient rebutants. Je pensais que Python avait un sacré chemin à faire en tant que nouveau langage de script, et au moment où j’ai commencé ma lecture, je me suis intéressé d’abord à ses aspect qui le rendaient unique.
J’ai fait immédiatement un mauvais trip sur la première chose que tout le monde remarque quand on lit un script Python pour la première fois : le fait que les espaces (= l’indentation) signifie quelque chose dans la syntaxe du langage. Ce langage n’a aucun délimiteur du type des crochets que l’on trouve en C ou en Perl ; au lieu de cela, les changements dans l’indentation délimitent naturellement les groupes. Et, naturellement, comme la plupart des hackers, lorsque j’ai réalisé cet état de fait, je suis retombé immédiatement dans une phase de dégoût.
Je suis suffisamment vieux pour avoir programmé en FORTRAN dans les années 1970. Au jour d’aujourd’hui, personne – ou presque – ne l’a jamais fait, mais le fait de l’avoir fait a mis en tête à ceux qui ont dû « subir » ça, quel point il est énervant de pratiquer le principe de « champs prédéterminés ». En fait, le terme « formatage libre » utilisé pour décrire le nouveau style de langage orienté « mot-clé », par exemple en Pascal et en C, a presque été oublié ; c’est parce que tous les langages d’aujourd’hui sont basés sur ce principe. Enfin presque tous. C’est difficile de blâmer quelqu’un, si, lorsqu’il voit un code Python, réagit comme s’il avait marché dans une bouse de dinosaure.
C’est un peu ce que j’ai ressenti. J’ai alors lu le reste de la description du langage, sans trouver quelque chose d’autre d’intéressant. Je n’y voyais aucune raison de recommander Python, à part le fait peut-être que la syntaxe semblait un peu plus claire que celle de Perl et qu’il semblait plutôt facile de créer des éléments d’interface utilisateur (« GUI elements ») tels que les boutons et les menus.
J’ai remis le livre sur l’étagère, en pensant qu’il faudrait que je me fasse un petit projet orienté GUI en Python, juste pour m’assurer que j’avais bien compris les fondements du langage. Jamais je n’aurais cru que ce que j’allais voir éclaterait littéralement la compétition avec Perl.
C’est à ce moment là qu’une conspiration de choses inutiles à faire s’est organisée autour de moi, et j’ai mis la priorité de « Test Python » tout en bas de la liste des choses à faire. Cela dura plusieurs mois. Entretemps j’ai même écrit le livre « The Cathedral and the Bazaar ». Mais j’ai tout de même trouvé le temps d’écrire quelques programmes en Perl, dont deux assez gros et complexe. L’un deux, « keeper », est un assistant qui est encore utilisé (NDT : en 2000) lors de soumissions de nouveaux fichiers qui arrivent au gestionnaire d’archives du laboratoire Metalab. Il génère les pages web que vous pouviez voir à metalab.unc.edu/pub/Linux/!INDEX.html. L’autre, « anthologize », était utilisé pour générer automatiquement la documentation PostScript de la sixième édition de l’archive des HowTos du Projet de Documentation Linux. Ces deux programmes sont disponibles à Metalab.
Écrire ces programmes en Perl m’a laissé progressivement un gout amer. Les gros projets semblaient transformer les petites choses ennuyeuses de Perl en problèmes sérieux et récurrents. La syntaxe qui parait simplement un peu excentrique au début, se transforme au bout de plusieurs centaines de lignes en une jungle vierge pratiquement impénétrable, et je ne vous raconte pas quand il s’agit de milliers de lignes. La maintenance devient exponentielle en fonction du nombre de lignes de code. Beaucoup de ces problèmes ont été résolus en ajoutant des patches à Perl (objets, variables locales, « use strict », etc.), mais cela m’avait bien refroidi.
De plus, la résolution de bogues, déjà anormalement difficile à résoudre, se transformait en mission presque impossible si on s’absentait quelques jours pour faire autre chose. Plus le temps passait, plus je me battais avec les problèmes du Perl au lieu de me pencher sur les problèmes de l’application proprement dite. Le pire de tout, c’est que le code devait être sale. C’est simple : des programmes laids et sales sont comme des ponts suspendus : ils ont beaucoup plus de chances de s’effondrer que des ponts classiques, parce que la manière dont nous percevons la beauté (particulièrement les ingénieurs) est intimement reliée à notre capacité de gérer et de comprendre la complexité sous-jacente. Un langage qui empêche, de par sa nature, d’écrire un code élégant, empêche aussi d’écrire un bon code.
Avec une expérience d’une vingtaine de langages dans mes valises, je pouvais distinguer tous les petits signes qui me disaient que j’avais poussé tel ou tel langage jusqu’à ses propres limites. A la mi-1997, je me disais « il doit y avoir une meilleure solution ». Et je me suis mis à rechercher un langage de scripting plus élégant.
Je n’ai même pas imaginé replonger dans le C. Les jours où il semblait censé d’écrire ses propres allocations mémoire et son propre gestionnaire d’allocations sont largement révolus, mis à part certaines niches de développement comme l’écriture de code pour le noyau, le graphisme 3D, bref, des endroits où on doit gagner un maximum de temps machine et par là même un contrôle personnalisé de l’utilisation mémoire.
Dans toutes les autres situations, il est impensable d’imaginer passer du temps en plus, à déboguer les débordements de buffer (buffer overruns), la mauvaise gestion des pointeurs, les fuites mémoire générées par les malloc/free et tous les autres inconvénients liés à cela. C’est bien mieux de se dire que la machine va mettre un peu plus de temps et que le programme va consommer un peu plus de mémoire, et économiser sur le facteur humain. C’est d’ailleurs cette stratégie qui a conduit à l’explosion de Perl vers le milieu 1990.
J’ai commencé par tester Tcl, et j’ai rapidement découvert que c’était encore pire que Perl. Le vieux LISPer que je suis s’est alors penché sur les variantes de Lisp et Scheme, mais comme cela l’a été depuis le début pour Lisp, même un bon design est rendu complètement inutile s’il n’existe aucune documentation (ou très peu) sur les liens POSIX/UNIX, et si la communauté est très faible et, de plus, fragmentée. Si Perl est devenu populaire ce n’est pas par accident. La plupart de ses compétiteurs étaient simplement plus mauvais.
La seconde fois où je me suis penché sur Python était aussi accidentelle que la première fois. En octobre 1997, j’ai reçu plein de questions sur « fetchmail », la plupart venant d’utilisateurs basiques, qui montraient clairement qu’ils avaient des difficultés à générer des fichiers de configuration pour mon utilitaire « fetchmail ». La configuration du programme utilise une syntaxe classique, du style UNIX, mais peut devenir extrêmement compliquée à partir du moment où un utilisateur a des comptes POP3 et IMAP sur plusieurs sites. Par exemple, voici un fichier de configuration : Listing 1.
J’ai alors décidé d’écrire un éditeur facile à appréhender, pour aider à la configuration : « fetchmailconf ». L’objectif était clair : cacher complètement la complexité de la syntaxe derrière une interface utilisateur simple, claire et conviviale, avec des boutons de sélection, et des fiches simples à remplir.
Rien que l’idée de faire ça en Perl me faisait peur. J’avais déjà vu du code GUI en Perl, et c’était un vague mélange de Perl et de Tcl qui était encore plus laid au final que mon propre code Perl. C’est à ce moment là que je me suis souvenu de Python, que j’avais à peine survolé six mois auparavant. C’était le moment ou jamais.
Bien sûr, l’objectif allait sûrement tester sévèrement mes compétences en tant que personne inexpérimentée dans ce langage. La première chose que j’ai revue était cette fameuse indentation. Cette fois néanmoins j’ai passé outre, et j’ai commencé à taper un code grossier pour faire quelques éléments GUI. Aussi bizarre que cela puisse paraitre, après une vingtaine de minutes, ce procédé d’indentation ne m’a plus du tout paru anormal. J’ai juste indenté comme je l’aurais fait en C, sans me poser plus de question, et ça a fonctionné.
C’était ma première surprise. La seconde est venue après plusieurs heures de codage du projet, lorsque j’ai remarqué durant mes « va-et-viens » entre le programme et le livre sur Python, que j’écrivais du code pratiquement aussi vite que je le tapais. Lorsque j’ai réalisé cela, j’ai été comme électrifié. Si on y pense bien, une grosse partie de l’effort du codage correspond à tous les moments où lorsqu’on veut résoudre un problème, cette résolution ne s’écrit pas comme on se la représente mentalement. Et on met toujours beaucoup de temps à réaliser que ce que l’on a écrit ne correspond pas forcément à la résolution du problème. Ce principe aide énormément à mesurer la qualité d’un langage : lorsque vous apprenez un langage, combien de fois il vous a fallu ré-écrire une portion de code tant que vous ne connaissiez pas bien ce langage.
Lorsque vous écrivez un code qui fonctionne presque aussi vite que vous le tapez, vous ne revenez pratiquement jamais en arrière, et en général cela signifie que vous maitrisez parfaitement ce langage. Mais ce n’était pas du tout logique, parce que c’était mon premier jour de Python et je faisais régulièrement des pauses pour regarder, dans le livre, les appels à faire aux différentes librairies !
C’est le premier indice qui m’a fait penser que Python avait un design exceptionnellement bon. La plupart des langages ont des spécificités et des choses si particulières à apprendre qu’il faut toujours énormément de temps avant de pouvoir bien les maitriser. Python était le premier langage qui invalidait ce principe.
J’ai mis très peu de temps avant de comprendre des particularités. J’ai écrit « fetchmailconf », avec GUI, en six jours, dont deux ont été utilisés pour apprendre Python lui-même. Cela reflète une autre propriété utile de ce langage : il est compact. Vous pouvez avoir toutes ses caractéristiques facilement et rapidement en tête (tout au moins son concept et ses librairies de base). C est un langage connu pour être compact. Perl est connu pour ne pas l’être. On a beau dire ce qui a fait le succès de Perl : « Il n’y a pas qu’une seule manière de l’écrire », dans tous les cas, ce n’est jamais concis.
Le moment le plus dramatique de ma découverte était encore à venir. Mon design avait un problème : il était facilement possible de générer un fichier de configuration, mais après, lorsqu’il fallait mettre les mains dans ce fichier de configuration on retombait à nouveau dans le problème d’origine.
Le parseur du fichier de configuration de « fetchmail » est plutôt élaboré. Pour tout dire, il est écrit en YACC et Lex, deux outils classiques UNIX qui sont utilisés pour générer le code C d’un parseur. Pour que « fetchmailconf » puisse éditer des fichiers de configuration existants, je me suis dit que je devais faire un parseur fonctionnant à l’identique en Python. Je n’en avais pas du tout envie, d’une part à cause de tout le travail que cela impliquait, et d’autre part parce que je n’étais pas sûr que les comportements allaient être de manière fiable absolument identiques. C’était bien la dernière chose dont j’avais besoin : du boulot supplémentaire pour tenir à jour deux parseurs en même temps lors des futures évolutions de « fetchmail ».
Ce problème m’a bloqué pendant quelque temps. Puis j’ai eu une inspiration subite : je vais laisser « fetchmailconf » se servir du parser de « fetchmail » ! J’ai alors ajouté l’option –configdump à « fetchmail » afin qu’il puisse parser un fichier « .fetchmailrc » et en sortir un fichier sous la forme d’un initialiseur Python. Voici un exemple de fichier qu’il était possible de sortir : Listing 2 (pour gagner de la place un peu d’information pas liée au sujet a été supprimée).
Python pouvait évaluer la sortie de la commande « fetchmail –configdump ».
Ce n’est pas fini ! Je ne voulais pas que « fetchmailconf » puisse lire la configuration courante, mais je voulais la transformer en arbre d’objets dynamiques. Il devait y avoir trois types d’objets dans cet arbre :
- Configuration (l’objet de plus haut niveau qui représente toute la configuration)
- Site (objet qui représente entièrement l’un des sites)
- User (les données d’un utilisateur particulier rattachées à un site)
Le fichier d’exemple précédent décrit cinq objets « Site », chacun ayant un objet « User » rattaché à lui.
J’avais déjà écrit ces trois classes d’objets (c’est ce qui m’a pris quatre jours, pendant lesquels j’ai surtout passé du temps à mettre les objet GUI à la bonne place). Chaque classe avait une méthode qui pouvait faire surgir un pop up d’édition qui éditait les données de l’objet proprement dit. Il ne me restait plus qu’à transformer les données lues d’origine en objets réels.
J’ai tout d’abord imaginé écrire du code qui connaitrait les informations de chaque classes et utiliserait ces connaissances afin de faire une correspondance, mais j’ai rapidement oublié cette idée, parce qu’en imaginant ajouter des nouveautés il y aurait des problèmes de compatibilité.
Ce que je voulais vraiment c’était un code qui analyserait la forme et les membres de l’initialiseur, en demandant directement au code qui définissait les classes, et qui s’ajusterait automatiquement afin de faire concorder les données d’un côté et les objets de l’autre.
Ce genre de choses est appelé « bidouille de méta-classes » (« metaclass hacking ») et est souvent considéré comme quelque chose d’ésotérique et d’effrayant (de la magie noire). La plupart des langages « orienté-objet » n’ont pas cette capacité ; pour ceux qui le peuvent (Perl y compris), cela a tendance à rendre le code plutôt complexe et dur à appréhender. J’avais déjà été impressionné par la rapidité d’apprentissage de Python mais là on arrivait à un vrai test. Quelle complexité de code est-ce que cela allait engendrer ? Je savais par expérience que cela allait être difficile, et même en arrivant à mes fins, le résultat allait être sale. J’ai tout de même pris le livre et je me suis penché sur les capacités Python concernant les méta-classes. La fonction résultat est dans le Listing 3, et le code qui l’appelle est dans le Listing 4.
Ça n’a pas l’air super compliqué soi-disant pour de l’affreuse magie noire, pas vrai ? Trente deux lignes en comptant les commentaires. En sachant juste ce que j’ai dit sur la structure de la classe, le code appelant est compréhensible. Mais ce n’est pas la taille qui est vraiment impressionnante. Tenez-vous bien : il m’a fallu quatre-vingt-dix minutes pour écrire ce code, et il a fonctionné correctement la première fois où je l’ai testé.
Dire que j’étais épaté est un euphémisme. Rien que le fait d’avoir un code qui fonctionne dès la première écriture est déjà remarquable en soi ; mais en plus, c’était ma première bidouille avec des méta-classes, six jours après avoir appris le langage ! Même en essayant d’imaginer que je suis un sacré bon hacker, ça n’en resterait pas moins une preuve vivante de la clarté, de la concision, et de l’élégance du design de Python.
C’est bien simple : il n’y a aucune possibilité simple de faire cela en Perl, même avec mon expérience plutôt poussée avec ce langage. C’est à ce moment là que j’ai réalisé que c’en était fini de Perl.
C’était un moment très intense. Bon, j’avoue qu’avec du recul, on peut juste constater que ce n’était qu’une bidouille subtile et élégante rendue possible grâce la souplesse de Python. L’utilité à long terme d’un langage ne se trouve pas que dans la possibilité, justement, de faire des bidouilles subtiles, et élégantes, mais aussi dans l’utilité qu’on a du langage au jour le jour. Le travail au jour le jour ne consiste pas qu’à écrire de nouveaux programmes, mais principalement à en lire et à en modifier des existants.
La vraie conclusion de cette anecdote est celle-ci : plusieurs mois après avoir écrit « fetchmailconf », je pouvais toujours lire et comprendre mon code sans avoir de gros effort de concentration pour tout comprendre à nouveau. Je stresse déjà rien qu’en imaginant avoir à replonger dans le code de « keeper » ou « anthologize » à nouveau, mais « fetchmailconf » ne pose aucun problème.
Perl a toujours son utilité. Pour des petits projets (100 lignes ou moins) qui impliquent énormément de filtres de texte (« pattern matching »), je pense que je pencherai peut-être vers une bonne expression régulière Perl plutôt que du code Python. En regardant les scripts « timeseries » et « growthplot » Perl de la distribution « fetchmail », je peux dire que ce sont presque des choses qu’on pourrait faire en utilisant une bonne combinaison de awk/sed/grep/sh. Pour tout le reste, je préfère de loin les vertues de Python, je pense que si vous testez, vous en arriverez certainement à la même conclusion.
