Geek, man and machine
Le but premier et ultime d’un programme informatique est qu’il fonctionne, c’est-à-dire qu’il compile (pas d’erreur qui empêche de le transformer en langage binaire exécutable par l’ordinateur) ET qu’il fait ce qu’on veut qu’il fasse (un ordinateur est bête : il fait toujours ce qu’on lui dit de faire, pas nécessairement ce qu’on veut qu’il fasse). Pourtant, rappelle Knuth (le dieu que révère Vikram Chandra), programmer, ce n’est pas seulement indiquer à un ordinateur ce que l’on veut qu’il fasse ; c’est aussi expliquer à un être humain ce qu’on vaut que l’ordinateur fasse. Cet être humain peut aussi bien être un collègue que vous-même quelques mois après l’écriture du code ; rien de tel, en effet, que de reprendre un ancien bout de code pour vérifier que je est un autre. Pour que votre moi du futur remercie votre moi du passé, il faut, nous dit Knuth, bien choisir le nom des variables (ok), expliquer ce qu’elles représentent (sous forme de commentaires), et introduire les concepts dans l’ordre qui sied à la compréhension humaine (yolo, Boileau). Comme s’il y avait un mode de compréhension humaine. Chacun a donc son idée sur la question, et ses propres critères pour en juger. On retrouve cependant avec récurrence l’idée qu’un code ne devrait pas se répéter.
D’une manière générale, le geek voit la répétition d’un mauvais œil : c’est le boulot de la machine, pas le sien – « any repetition of effort seemed like an insult. » (p. 15) Le geek pourra donc passer cinq heures à coder l’automatisation d’une tâche qui lui aurait pris 30 minutes – et ce, même s’il est probable voire certain qu’il n’aura pas à la reproduire 9 autres fois. Le geek, comme l’homme dont il hérite, est un animal raisonnable : ce n’est pas parce qu’il peut être raisonné qu’il est d’emblée rationnel.
Le plaisir de coder
Le code peut-il être esthétique ? « The beauty of code » est l’un des leitmotiv de l’essai de Vikram Chandra, et le titre de son chapitre central. Pour autant, vous pouvez ranger Kant, l’émotion esthétique due au vertige des interprétations infinies n’est pas à l’ordre du jour. Vu qu’un programme a pour finalité d’être exécuté par une machine, mieux vaut qu’il n’ait qu’un sens bien défini ; contrairement aux interprétations, les boucles gagnent à ne pas être infinies. Exit la polysémie.
Exit le plaisir esthétique. Bonjour le plaisir sportif. Oui, vous avez bien lu. Pour Yukihiro Matz Matsumoto, le beau code a vocation à rendre le développeur « heureux et productif » (p. 122), et à en croire Vikram Chandra, cela passerait très concrètement par les endorphines : face à problème ardu, « the world fell away, my body vanished, time receded. And three or five hours later, when the pieces of the problem came together just so and clicked into a solution, I surfed a swelling wave of endorphins. » (p. 19) Et si le développeur était accro au code comme d’autres aux sport ?
En 6 ans de Palpatine, je peux vous dire qu’un geek, un vrai geek, ne lâche jamais le morceau. Lorsqu’un problème lui résiste, il y pense tout le temps, fusse en arrière-plan : en marchant (très péripatétique), sous la douche (un grand classique), au concert (la musique aère l’esprit et permet à la pensée de mieux circuler), mais aussi en société, ce qui peut parfois occasionner un freeze en pleine conversation : les pièces click into a solution, réelle ou supposée. (Je le soupçonne de continuer à ruminer au lit, mais il y a des choses que je préfère ne pas savoir avec certitude).
De quoi la métaphore du code comme art est-elle la revendication ?
Palpatine rappelle régulièrement à qui veut l’entendre qu’en France, le code est régi par le code de la propriété intellectuelle, exactement comme un roman (eh non, un programme ne se brevète pas). La métaphore du code comme art a de quoi surprendre, parce que l’on oublie généralement que l’artiste est d’abord un artisan. Le développeur n’est pas un mécanicien qui sert des boulons binaires, c’est un artisan, qui adapte, polit, peaufine… et revendique donc un savoir-faire. Car non, coder, ce n’est pas (uniquement) appliquer des principes mécaniques qui s’enchaîneraient comme le développement d’une équation ; c’est structurer une réalité foisonnante, la mettre en forme, la concevoir. On ignore généralement que le bon développeur est créatif – on l’imagine rusé, oui, mais pas créatif.
Si les développeurs se comparent à des peintres, des musiciens ou des essayistes, c’est pour faire valoir cet aspect méconnu de leur travail. Et revendiquer le statut qui devrait aller avec. Id est la considération, le salaire et… le sex appeal ? Vikram Chandra cite l’interprétation toute personnelle de Ceglowski sur le recours aux comparaisons artistiques : « Great paintings… get you laid in a way that great computer programs never do […] especially if you have the slighteste hint of being a tortured, brooding soul about you… » (p. 8-9). En bref : le geek ne veut pas être un nerd (le retour en grâce du terme geek, employé à tout va, ne doit pas nous faire oublier qu’à la base, c’est un synonyme de nerd, le mec antisocial un peu zarb avec qui on n’a pas du tout envie de traîner)(Palpatine, en tant que ‘vrai geek’, s’offusque régulièrement de ce que n’importe quel bidouilleur soit aujourd’hui honoré d’un qualificatif qu’il a eu à souffrir comme insulte avec ses camarades pendant sa jeunesse ; être geek, ça se mérite !).
Architecture
L’art est utile comme métaphore pour exprimer les rapports de proportions et d’harmonie. On pourra dire, par exemple, qu’un beau programme est comme une symphonie : chaque morceau en est une phrase musicale, qui peut être jouée seule, mais trouve sa raison d’être au sein de l’oeuvre, nuancée, enrichie par les phrases musicales qui la précèdent, la suivent, et l’entourent de leurs résonances. « Each small part is coherent, singular in its purpose, and although all these small sections fit together like the pieces of a complex mosaic, they come apart easily when one element needs to be changed or replaced. » (p. 123) Cette modularité, je me la représente sous la forme des sas de station spatiale, par lesquelles les astronautes des films passent toujours pour entrer et sortir sans danger. En cas d’urgence (et dans les films comportant des astronomes, il y a toujours une urgence), ces sas permettent de se défaire d’une partie endommagée sans détruire l’ensemble de la station. C’est-à-dire, pour le développeur, de modifier facilement une fonctionnalité pour le client qui a encore changé d’avis et veut son nouveau choix là tout de suite ; mieux vaut, donc, ne pas avoir à aller fouiller dans tous les recoins du programme pour modifier une fonctionnalité réduite.
Big Ball of Mud
L’effet boule de neige boue
L’architecte, qui veille au bon agencement de toutes les parties, joue ainsi un rôle primordial. Et ce n’est pas de la tarte : même un projet très simple se révèle toujours plein d’exceptions et de cas spéciaux qu’il faut gérer (si possible, sans faire rejaillir la complexité de ces exceptions sur les manipulations ordinaires). On a vite fait, les deadlines aidant, de se laisser embringuer : « you know that functionality should be somewhere else but you don’t have the time to bother, the users ask for a new feature and you patch it in, and of course you mean to come back later and clean everything up, but then, before you know it, you are trapped inside an unwholsome, uncontrollable atrocity, a Big Bull of Mud » (p. 126), « and yes, it is a technical term of art » (p. 127). Devenue incontrôlable, une Big Ball of Mud peut atteindre un nombre de ligne et une complexité tels que le programme échappe purement et simplement à la capacité de conception humaine. Plus personne ne comprend comment il fonctionne de bout en bout. « No temple, no cathedral has ever contained as many moving parts. » (p. 124)
[Go to indique au programme d’aller à telle ou telle ligne… qui a de fortes chances de bouger lors du développement. C’est le truc crade par excellence, à ne pas faire. Une pratique qui vaut -42, vous dira Plapatine.]
Dinosaures sous respiration artificielle
Comment traquer des bugs et ajouter des fonctionnalités à un programme que l’on ne comprend pas, quand la moindre modification effectuée dans un coin peut avoir des répercussions inattendues à l’autre bout du système ? Généralement, nous dit Vikram Chandra, on est pris de l’envie de tout réécrire de manière propre. Sauf qu’on n’en a jamais le temps ni le budget. Alors on rajoute une rustine, un peu de boue à la Big Ball of Mud.
Il existe ainsi des programmes qui tournent depuis des décennies et qui ne peuvent pas être correctement maintenus ni mis à jour parce que plus personne ne comprend comment ils fonctionnent dans leur ensemble. C’est par exemple le cas du logiciel comptable du Pentagone, apparemment célèbre pour ses erreurs dans les fiches de paye des soldats (p. 128)… Le secteur bancaire est également un beau tas de boue : 90 % des transactions financières dans le monde se font via des logiciels en COBOL, « the computing equivalents of Mesopotamian cuneiform dialects ». Hé oui, le site web tout beau tout neuf tout responsive de votre banque cache un système vieilli jusqu’à la moelle (p. 129)…
La programmation orientée objet
Au milieu des années 1980, on a imaginé de rassembler à un même endroit du code les différentes types de données et ce qu’on peut faire avec (i.e. les fonctions qui s’y rapportent). En encapsulant ces informations thématiques dans des objets, on espérait en mettre un peu moins partout. Et cela a fonctionné. Un peu. La programmation orientée objet a résolu certains problèmes, parfois même avec une certaine élégance, souligne Vikram Chandra ; elle a permis de mettre de l’ordre dans la « spaghetti code jungle » (la jungle est de Foote et Yoder, dans Big Ball of Mud, mais le « code spaghetti » est aussi un terme technique consacré, désignant les kilomètres de lignes de code enchevêtrées, issus de la programmation procédurale.). Pour autant, la programmation orientée objet n’est pas une solution miracle et les Big Balls of Mud continuent de proliférer (un peu comme le bordel dans mon studio en dépit des placards)…
« If you’ve ever writen code, the fact that so much software works so much of the time can seem profoundly miraculous. » (p. 124) Le bug est la normalité, pas le fonctionnement. Comme dirait Palpatine, ça « tombe en marche ».
Les travaux et les jours
Les bons outils font les bons… jongleurs ?
Un précepte geek enjoint de ne pas réinventer la roue et de se hisser sur les épaules d’un géant, en utilisant ce qui a déjà été fait. Il existe ainsi tout un tas de briques pré-construites qui permettent de réutiliser le travail déjà fait, des librairies dans lesquelles aller piocher un savoir patiemment accumulé ; et tout un tas d’outils pour gérer le code et éviter sa prolifération anarchique. Git, par exemple, permet de gérer le versionnement, pour que plusieurs personnes puissent travailler sur le même programme sans risquer d’effacer le travail des autres, et que l’on puisse à tout instant revenir à une version antérieur. Un outil puissant et précieux, donc, mais complexe à utiliser, qui constitue une compétence en soi (au point de figurer sur les annonces d’emploi au même titre que les langages à maîtriser).
Les outils, remarque Vikram Chandra, deviennent un savoir à part entière – problème du moyen qui devient une fin. « Each tool and pre-constructed library solves a problem that you must otherwise solve yourself, but each solution is a separate body of knowledge you must maintain. » (p. 139-140) D’où pour certains développeurs l’impression de ne plus être à l’aise dans quoi que ce soit. L’assurance d’avoir toujours quelque chose de nouveau à apprendre est l’un des attraits du métier, mais cela peut aussi se transformer en course épuisante contre la montre et l’obsolescence. Se former aux nouveaux langages pour les projets de demain tout en bossant à fond sur les projets en cours…
Le nouveau langage à la mode
« Our industry [remarks Steve Yegge] is fashion-driven to a degree that would embarrass haute couture designers from New York to Paris… » Aussi surprenant que cela peut paraître de l’extérieur, la mode dicte les langages que les gens étudient à l’école, qu’il utilisent ensuite dans projets professionnels, ceux à propos desquels des bouquins sont publiés, etc. Palpatine pestait récemment contre les choix de langage faits par ses associés : parce qu’un geek, par principe, peste toujours contre les langages qui ne sont pas ses préférés, mais aussi parce que le choix du langage n’en a pas été un. Il n’a pas fait l’objet d’un choix rationnel après mise en balance avec d’autres langages et étude de leurs avantages et inconvénients pour ce projet particulier ; ses associés l’ont choisi parce que c’est ce qui se fait et ce qu’ils savent faire. (Je soupçonne tout de même Palpatine d’un léger snobisme geek, à kiffer des langages paraît-il d’une grande élégance, mais à peu près jamais utilisés dans l’industrie.)(Un mignon snob, évidemment.
Et demain ?
À l’heure où l’on taquine l’idée d’enseigner le code à l’école, Vikram Chandra remarque que la promesse de démocratisation du code, déjà ancienne, n’a jamais vraiment été tenue. La forme de programmation la plus courante dans les entreprises, au final, est celle des feuilles Excel. « The biggest problem is that anyone can create Excel spreadsheets – badly. » (Kwak, The Importance of Excel). Même quand on maîtrise Excel, surtout quand on le maîtrise et qu’on y fait des calculs complexes, ce type de programmation peut s’avérer dangereux, car il est très difficile à auditer et débuguer – pas fait pour. J’ai d’autant moins de mal à le coire qu’il y avait un pro des tableaux Excel dans l’équipe où j’étais en apprentissage ; vous n’avez pas idée du nombre d’entrées et de formules qu’il y avait là-dedans, d’une complexité telle que… lui seul pouvait s’y retrouver. Vikram Chandra cite même le cas d’une erreur financière monstrueuse (à plusieurs millions) due à une feuille de calcul où une cellule calculait la somme au lieu de la moyenne… (p. 142)
Ouais, je sais, c’est moyen glamour d’envisager le futur sous la forme d’un tableau Excel. Du coup, Vikram Chandra se lâche pas mal en imaginant tout un tas de trucs, dont une rencontre du troisième type entre programmation informatique et génétique. Si vous voulez lire là-dessus, je vous conseille plutôt l’article d’Eliness où elle explique son métier de bio-informaticienne.