CPU ⬜ Carré Petit Utile

Extrait de l'émission CPU release Ex0242 : 🍜 Ramen ta pasta.

[Note : Une version longue de cet article nettement plus détaillée est disponible ici]

Le code spaghetti, ou programmation spaghetti en bon Français, désigne un logiciel incompréhensible au motif que son auteur a fait un usage excessif d'instructions de saut, particulièrement des instructions non structurées.

Bon, je sais, juste avant de passer à table, la transition est rude. Reprenons :
[professoralement] Un programme d'ordinateur se compose de fichiers de code source. Code source qui s'écrit dans un langage de programmation, où le programmeur donne ses instructions à la machine.

L'arrivée du mot spaghetti en informatique remonterait aux années 1960s. Dans son article de 1972 pour l'ACM (Association for Computing Machinery), Martin Hopkins propose

d'éliminer l'instruction GOTO dans l'espoir que les programmes cesseront ainsi de ressembler à un plat de nouilles.

Ce monsieur ne devait pas aimer les féculents.

Le terme est repris dans plusieurs livres et articles tout au long des années 1970s et 1980s, et plus récemment dans le rapport d'expertise judiciaire sur l'accélérateur électronique des voitures Toyota, dont le logiciel bogué serait responsable de dizaines d'accidents mortels entre 2005 et 2009.

On ne rigole plus : en informatique, un code incompréhensible implique d'être un nid à bogues et impossible à maintenir, c'est-à-dire que personne n'a envie de le corriger.

Dans « The Art of doing science and engineering », le dernier livre de Richard Hamming (il est mort l'année suivante), l'auteur remonte avant l'invention des langages de programmation, quand les programmeurs écrivaient directement les instructions-machine comprises par le processeur. En binaire !

Insérer des instructions pour corriger un algorithme aurait nécessité de déplacer toutes les instructions suivantes, et notamment recalculer tout un tas d'adresses-mémoire. Il était donc plus simple de remplacer une instruction par un saut vers une région mémoire inutilisée, y placer les instructions à ajouter, puis terminer par un saut vers la suite du programme.
[Sur une voix confidentiel] Comme une parenthèse en plein milieu d'une phrase à rallonge. Oui exactement ce qu'on évite de faire en radio…

Sauf que quand vous placez des correctifs au 4 coins de la mémoire au lieu d'attaquer le problème à la racine, c'est-à-dire réécrire le programme, vous pouvez être sûr que ça finira mal : non seulement vous ne viendrez pas à bout des erreurs, mais en plus le résultat sera ingérable, parce que le chemin d'exécution à travers toutes ces sauts finira par ressembler à un plat de nouilles. Quand je disais que c'est une correction plus simple, c'était à court terme. Certains disent repousser le tas de sable. J'ai jamais compris cette expression, il me semble que quand on pousse un tas de sable, il s'étale. Cacher la poussière sous le tapis, à la rigueur.

[Bruit de savane et voix-off de documentaire animalier] Tapis et caché, observons dans son habitat naturel comment se manifeste le code spaghetti en langage machine mais aussi dans différents langages de programmation.

Les premiers langages évolués sont Fortran, Lisp, Cobol et Algol, entre 1957 et 1959. Ces langages n'étaient qu'une première itération dans le long chemin vers plus d'abstraction, ils gardaient le concept de saut vers une adresse, provenant du langage machine, mais au lieu d'opcodes spécifiques à chaque machine, l'instruction s'appelle GOTO, ou GO TO en deux mots : ALLER À. Toutefois la destination n’est pas un nom, mais le numéro de la ligne vers laquelle dérouter l'exécution.

Mais c'est surtout par le Basic dans les années 1980, que notre génération a invoqué l'infâme GOTO. En Basic, sans GOTO le programme s'exécute en ligne droite et se termine très vite, une fois arrivé au bas des lignes de code que vous avez tapées. Enfin, vous pouvez faire des boucles FOR… mais toujours avec des numéros de ligne. Basic avait un début de programmation structurée, mais sans indentation, et sans pouvoir nommer les sous-programmes : spaghetti assuré !

Des dialectes de Basic ont bien fini par rendre les numéros de ligne optionnels, se doter de boucles WHILE repompées du langage Pascal, et nommer les sous-programmes plutôt que faire GOSUB numéro_de_ligne, mais pour cela il faudra attendre GFA Basix, Turbo Basic et autre Quick Basic… On en a déjà parlé dans cette émission.

J'ai mentionné plusieurs fois programmation structurée. Mais qu'est-ce donc ? C'était censé être le vaccin contre le code spaghetti : si on élimine le GOTO à la racine, les programmes n'en seront que plus maintenables. N'est-ce pas ?

En programmation structurée, on remplace l’unique GOTO par plusieurs instructions spécialisées ci dans les boucles, là dans les tests de condition, etc…

Fin de la sous-fonction, retournons au programme principal.

En 1968, l'honorable Prof. Edsjer Dijkstra dans une lettre à ses honorables confrères, ne propose pas du tout de remplacer les numéros de ligne par IF/THEN/ELSE, mais suggère que ces conditionnelles sont inutiles car exprimables par le concept de récursion. C’est parfaitement exact en informatique théorique, c'est à dire en théorie. Mais prendre cela au pied de la lettre pour en faire un langage de programmation… et bien ça a été fait, dans LISP, Scheme, des langages fort élégants… et utilisables que par quelques super-héros dont Daniel Goossens.

À cet article « Go To Statement Considered Harmful » de Dijkstra, un certain Frank Rubin répondit par une lettre intitulée « GOTO Considered Harmful Considered Harmful », à laquelle Donald Moore répondit par une lettre intitulée « GOTO Considered HarmfulConsidered Harmful Considered Harmful ? » !!! Quant à Edsger Dijkstra, lui aussi se fendit d’une réponse intitulée « À propos d’une correspondance assez décevante ».
Si si, tous les liens sont dans le texte de ma chronique. GOTO notre site web !

Est-ce que ces joutes oratoires ont fait progresser le problème du code spaghetti ? Le prof. Dijkstra en disserte dans son livre « Structured Programming ». Qu’eussiez-vous cru qu’il advint ? un article de 12 pages intitulé « Structured Programming Considered Harmful » par un universitaire New-Yorkais. Et un autre article du même titre, cette fois par deux étudiants, 3 ans plus tard dans le même journal !
À l’époque, on savait rigoler ! Vos trolls sont fades…

Même Donald Knuth, l’auteur de la sainte-bible « L’art de la programmation » en 7 évangiles, s’en est mélé en 1974 dans son article « Structured Programming with go to Statements ».
Eh oui, ils sont lourds.

Revenons au langage machine. Au tout début de l'ENIAC, les programmes s'écrivaient en déplaçant des cordons comme dans un central téléphonique d'arrière grand-papa, mais la machine a ensuite été transformée selon les préceptes de John Von Neumann : le programme devenait stocké en mémoire, une vraie révolution. Comme nous l'a expliqué le prof. Hamming, les programmeurs pouvaient être tentés de patcher leur code à coup de sauts opportunistes, parce que flemme…

Puis vint le premier ordinateur commercial, le BINAC, sur lequel on trouve le langage C-10, ancêtre de l'assembleur, une notation symbolique pour le langage machine.

Et on n'a jamais cessé de programmer en langage machine ! Dans le BIOS de votre ordinateur, dans votre compilateur C++, y'a du code en assembleur. Certes, plus besoin de calculer les adresses à la main, mais le langage machine n'est pas structuré, et s'il est parfaitement possible de structurer volontairement son programme, il faut une discipline de fer pour échapper à la malédiction du code spaghetti.

Vous programmez exclusivement en langage structuré ? Vous pouvez créer du couplage horriblement complexe sans même passer par des instructions : il suffit de faire n'importe quoi avec les données !
Eh ! les devs C++ ! Osez me dire en face que vous n'avez jamais écrit le mot-clé friend.
[Rires enregistrés puis indicatif par The Rembrands de la série « Friends »]

Et il y a mille et une façons de sauter, même sans GOTO.

[Da Scritch, aka Xavier Mouton-Dubosc] — Eh oh !

Très peu de langages poussent la pureté de la programmation structurée au point d'interdire plus d'un point de sortie par sous-programme ; En C, PHP, Javascript vous pouvez mettre return autant de fois que vous voulez. Mais… réfléchissez un instant : si vous avez plusieurs motifs de sortie, est-il plus lisible d'assigner une variable drapeau que vous testerez à plusieurs endroits de votre fonction ? Non seulement vous l'alourdissez à chaque vérification, mais en plus, en l'indentant, vous la décalez dangereusement vers l'extrême-droite.

En interdisant les return multiples, vous n'aurez fait que déplacer le problème, et pas que de tabulation. Alors déstructurez un peu votre programmation ! vous avez ma bénédiction tant que vos fonctions tiennent en une page-écran. [tel un Emile Zola de bureau d’étude] J’accuse la règle 15.5 de la norme MISRA C:2012 d’hérésie ! et si interpeller Toyota sur le nombre de règles MISRA non respectées était parfaitement justifié, il serait naïf de croire que ces règles, seules, suffiraient à obtenir un code source de bonne qualité.

Il y a pire ! il faut que je vous parle de multitâche, et du langage Intercal. A priori, aucun rapport. Intercal est un langage inventé par deux potaches de l'université de Princeton ayant manifestement beaucoup trop de temps libre. Imaginez un langage où il faut écrire plusieurs fois PLEASE devant les instructions pour augmenter les chances qu'elles soient réellement exécutées. Le consentement, déjà. Et ces grands malades ont décrété que pour sortir d'une boucle, il fallait dire oublie de reboucler, avec une instruction FORGET.

Et c'est pas tout : dans un article satirique de 1973, Lawrence Clark se moque de l'article « Go To Statement Considered Harmful » et propose… l'instruction COME FROM. Qui a été ajoutée à C-Intercal : vous pouvez écrire n'importe où dans le programme un COME FROM 120, et quand l'exécution arrivera à la ligne 120, qui n'avait rien demandé, le flot de contrôle sera dérouté vers la ligne contenant le COME FROM 120 ! L'enfer à déboguer : il faut connaître par cœur la totalité du code source !

Le rapport entre COME FROM et le multitâche ? À votre avis, que se passe-t-il si le programme contient deux lignes COME FROM 120 ? Dans les vieux dialectes d'Intercal, l'exécution est non-déterministe, ce qui, vous me direz, est approprié pour un langage BDSM dont la bonne exécution dépend du nombre de PLEASE. Mais en Threaded Intercal les deux COME FROM s'exécutent en parallèle, parce que,… pourquoi pas ? Le programme se divise en deux qui vivent joyeusement leur vie !

Enfin, joyeusement… tant qu'ils n'accèdent pas aux mêmes variables, qui sont globales. Vous commencez à comprendre… les communications entre fils d'exécution dans la programmation concurrente, encore un bon plat de nouilles.

Et je n'ai pas parlé des exceptions, cette drogue dont abusent certains programmeurs Java ou Python, à tel point que vous n'êtes pas sûrs d’où vous ressortirez.
Les exceptions, une bonne idée pour la gestion d'erreurs, un cauchemar si on les laisse se propager.

GOTO existe en C, en C++, https://wiki.freepascal.org/Standard_Pascal même en Pascal, et même en Go.
[Façon Homer Simpson] Toh !
Il existera dans beaucoup de langages à venir, et c'est pas le problème, car le code spaghetti, il est dans le cerveau brumeux de certains développeurs : pour éviter que vos programme deviennent ingérables, ce n'est pas la programmation structurée qui vous sauvera, mais le bon goût, et l'architecture. Alors documentez, documentez, il en restera toujours quelque chose ! Refactorisez-moi ces fonctions de 500 lignes ! Et par pitié, n'appliquez pas bêtement les Design Patterns juste parce que vous venez de lire un livre.

Le problème avec le logiciel n'est pas le code spaghetti, ni l'incompétence des programmeurs (quoique…), non non non : c'est que l'ordinateur est tellement versatile, le programmeur peut manipuler à lui seul une telle quantité d'unités de complexité, qu'il est injuste de lui mettre sur le dos les bugs qu'il commet. Car enfin, comparez la productivité d'un softeux avec celle d’un électronicien, et on en reparle. D'ici là, et j'ai largement le temps de me faire remplacer par une IA généraliste, [en fond, un chant gregorien généré par IA « Refugium In Altissimis » (psaulme 91) , qui semble avoir été généré par IA] chantons les louanges de John von Neumann , visionnaire créateur de l'ordinateur à programme stocké en mémoire [coupure de la musique et diction qui s’accélère] qui a publié l'idée trop tôt, ruinant ainsi tout espoir de ses collègues de breveter l'EDSAC !

Texte : Benoit
Voix complémentaire : Da Scritch
Illustration sonore : Générique de « Friends » par The Rembrands © Warner, D.R. / « Refugium In Altissimis » (psaulme 91), chant grégorien généré par IA, domaine public du coup
Photo : Pâtes maisons, CC-By-SA-NC Enflammée pour CPU