Philosophie de l'ingénierie : Edsger Dijkstra, l'élégance n'est pas optionnelle

L’essentiel à retenir

• L’élégance n’est pas optionnelle. Pour Dijkstra, la simplicité est la condition préalable à la correction, et non une récompense que l’on récolte après coup — vous ne pouvez pas prouver ce que vous ne comprenez pas pleinement.
• La preuve l’emporte sur les tests. « Les tests révèlent la présence de bugs, jamais leur absence. » La confiance dans la correction vient du raisonnement sur un programme, jamais de l’accumulation de tests réussis.
• Réfléchissez avant de coder. Il a conçu son algorithme de plus court chemin sans crayon ni papier, le contraignant à rester assez petit pour tenir dans une seule tête — la contrainte a produit l’élégance.
• Écrire, c’est penser. Les manuscrits EWD, composés à la main au stylo-plume sans possibilité d’annuler, faisaient que les arguments tenaient ou échouaient à l’encre — la même discipline appliquée à la prose.

Le principe

« La simplicité est la condition préalable à la fiabilité. » — Edsger W. Dijkstra, attribué (vers 1975)¹

La phrase nous est parvenue sous la forme d’un aphorisme tenant en une ligne, presque une note marginale, associée à ses mémos délibérément provocateurs des environs de 1975. Dépouillée de son contexte, elle se lit comme un slogan, mais Dijkstra l’entendait comme une affirmation logique stricte. La fiabilité n’est pas quelque chose que l’on ajoute à un système compliqué en le testant plus durement. Un système que vous ne pouvez pas pleinement comprendre est un système que vous ne pouvez pas prouver correct, et un système que vous ne pouvez pas prouver correct échouera de façons que vous n’aviez pas anticipées. La simplicité n’est pas une préférence stylistique qui rivalise avec la correction. Elle est ce dont la correction est faite. On n’obtient pas la seconde sans la première.

Cela inverse la manière dont la plupart des logiciels sont réellement écrits. L’instinct courant consiste à construire la chose, à la faire fonctionner, puis à la tester jusqu’à ce que les bugs cessent d’apparaître — en traitant la simplicité comme un luxe à rechercher plus tard, s’il reste du temps. Toute la carrière de Dijkstra fut un plaidoyer affirmant que cet ordre est inversé et dangereux. Sa phrase la plus citée est l’avertissement qui en découle directement : « Les tests révèlent la présence de bugs, jamais leur absence. »² Un test réussi ne vous dit rien sur les entrées que vous n’avez pas essayées. La seule façon de savoir qu’un programme est exempt de bugs est de raisonner à son sujet — et vous ne pouvez raisonner que sur ce qui est assez simple pour tenir dans une seule tête humaine. Pour Dijkstra, l’élégance « n’est pas un luxe superflu, mais un facteur qui décide souvent entre le succès et l’échec ».³

Cette conviction le place à la source de cette série. Là où Linus Torvalds remodèle un problème jusqu’à ce que le cas particulier disparaisse et où John Carmack dépouille un problème jusqu’à son noyau rapide, Dijkstra a fourni l’affirmation sous-jacente dont tous deux ont hérité : la solution élégante et la solution correcte sont une seule et même solution. C’est le plaidoyer originel pour traiter le goût comme un système technique plutôt que comme une complaisance esthétique — et le plaidoyer pour la preuve plutôt que la plausibilité des décennies avant que quiconque ne lui donne ce nom.

Contexte

Edsger Wybe Dijkstra naquit le 11 mai 1930 à Rotterdam, aux Pays-Bas, et mourut le 6 août 2002 à Nuenen.⁴ Son père était chimiste et président de la Société chimique néerlandaise ; sa mère était mathématicienne, dotée, selon ses propres dires, d’un sens exceptionnellement clair de ce qui rend un argument mathématique élégant et de ce qui le rend seulement fonctionnel. Il étudia les mathématiques et la physique théorique à Leyde, puis prit un poste de programmeur au Centre mathématique d’Amsterdam en 1952 — à une époque où « programmeur » n’était pas encore une profession reconnue. Lorsqu’il tenta de l’inscrire comme métier sur son certificat de mariage en 1957, les autorités néerlandaises auraient refusé de l’accepter, parce qu’un tel métier n’existait pas officiellement ; il dut écrire « physicien théoricien » à la place.⁴

Ce détail n’est pas une anecdote anodine. Dijkstra passa le reste de sa vie à soutenir que la programmation était une discipline intellectuelle rigoureuse plutôt qu’un travail de copiste, et cette insistance commença avant même que la discipline n’ait un nom. Il occupa un poste au Centre mathématique, puis devint professeur à l’Université de technologie d’Eindhoven en 1962, passa les années 1970 comme chercheur associé chez Burroughs Corporation, et prit en 1984 la chaire Schlumberger Centennial en sciences informatiques à l’Université du Texas à Austin, où il resta jusqu’à sa retraite en 1999.⁴

En 1972, il reçut le prix Turing de l’ACM. La citation mérite d’être lue dans son intégralité, car elle nomme le principe mieux que tout résumé : « Pour ses contributions fondamentales à la programmation en tant que défi intellectuel élevé ; pour son insistance éloquente et sa démonstration pratique que les programmes devraient être composés correctement, et non simplement déboggués jusqu’à la correction ; pour sa perception éclairante des problèmes aux fondements de la conception de programmes. »⁵ Composés correctement, et non simplement déboggués jusqu’à la correction. Cette phrase, c’est l’homme tout entier.

L’œuvre

L’algorithme de plus court chemin (1956, publié en 1959)

En 1956, on demanda à Dijkstra de trouver un problème qui mettrait en valeur le nouvel ordinateur ARMAC lors de son inauguration officielle — quelque chose qu’un public non technique pourrait suivre. Il choisit le plus court trajet entre deux de 64 villes néerlandaises, parce que tout le monde pouvait comprendre la question et vérifier la réponse. La solution lui vint d’une manière qu’il ne se lassa jamais de raconter : « Un matin, je faisais des courses à Amsterdam avec ma jeune fiancée, et, fatigués, nous nous sommes assis à la terrasse d’un café pour boire une tasse de café, et je me demandais justement si je pouvais le faire, et j’ai alors conçu l’algorithme du plus court chemin. »⁶ Cela prit une vingtaine de minutes.

La méthode par laquelle il le trouva, voilà la leçon. « L’une des raisons pour lesquelles il est si beau, dit-il plus tard, c’est que je l’ai conçu sans crayon ni papier. J’ai appris par la suite que l’un des avantages de concevoir sans crayon ni papier, c’est que l’on est presque forcé d’éviter toutes les complexités évitables. »⁶ Il ne pouvait pas s’appuyer sur des brouillons, alors l’idée devait être assez petite pour tenir entièrement dans son esprit. La contrainte produisit l’élégance. Il ne le publia pas pendant trois ans — l’article de 1959, « A Note on Two Problems in Connexion with Graphs », paru dans Numerische Mathematik, dépasse à peine une page — parce que, selon ses mots, la programmation n’était pas encore considérée comme une activité assez respectable pour qu’on en écrive.⁶

L’algorithme est glouton : il étend toujours d’abord le nœud non visité le plus proche, un front d’onde qui s’élargit et atteint chaque point par sa plus courte distance à tour de rôle. Il est assez simple pour être expliqué à une table de café, et il est prouvablement optimal — la première fois que le front d’onde touche l’objectif, ce chemin ne peut être battu. Simple et correct ne sont pas en tension ici. Ce sont le même fait.

« Go To Statement Considered Harmful » et la programmation structurée (1968)

En 1968, Dijkstra soumit une lettre à Communications of the ACM sous le titre « A Case Against the Goto Statement ». L’éditeur, Niklaus Wirth, la rebaptisa « Go To Statement Considered Harmful » — une formule qui engendra tout un genre d’imitations et qui est aujourd’hui plus célèbre que tout ce que contient la lettre elle-même.⁷ L’argument de Dijkstra n’était pas un guide de style. Il était épistémologique. Un goto sans contrainte permet au contrôle de sauter n’importe où, ce qui signifie que pour comprendre ce qu’un programme fait à une ligne donnée, il vous faut peut-être retracer tous les chemins qui auraient pu y mener. Le texte du programme et le comportement du programme se dissocient. Avec un contrôle structuré — séquence, sélection et boucles —, le texte et l’exécution restent en correspondance, et vous pouvez raisonner sur un bloc en lisant ce bloc.

L’argument est le même principe que la contrainte du plus court chemin, appliqué à la conception du langage : garder la chose assez petite pour pouvoir raisonner dessus. La programmation structurée ne consistait pas à bannir un mot-clé. Il s’agissait de préserver la capacité de l’humain à prouver, par la lecture, que le programme est correct. L’inventaire de son vocabulaire dans la citation Turing — « deadly embrace », « semaphore », « go-to-less programming », « structured programming » — est le témoignage de la profondeur avec laquelle il remodela le langage dans lequel pensent les programmeurs.⁵

Son travail sur les systèmes d’exploitation portait le même ADN. Le système de multiprogrammation THE (1968) fut construit comme des niveaux d’abstraction strictement superposés, chacun vérifiable à lui seul. Pour coordonner des processus concurrents, il inventa le sémaphore et ses opérations P et V, et il formula le problème du dîner des philosophes comme une distillation pédagogique de l’interblocage et de la famine — une question ardue de concurrence rendue assez petite pour tenir dans l’esprit.⁴⁵ Vinrent ensuite l’auto-stabilisation et, dans A Discipline of Programming (1976), le calcul des transformateurs de prédicats / de la précondition la plus faible : une méthode pour dériver un programme et sa preuve de correction ensemble, main dans la main, plutôt que d’écrire du code en espérant le vérifier après coup.⁴⁵

The Humble Programmer : la preuve plutôt que les tests (1972)

La conférence du prix Turing de Dijkstra, « The Humble Programmer » (EWD340), est l’exposé le plus clair des raisons pour lesquelles la simplicité est une préoccupation morale et non seulement pratique. Son affirmation centrale porte sur la taille de l’esprit humain. « Le programmeur compétent est pleinement conscient de la taille strictement limitée de son propre crâne ; c’est pourquoi il aborde la tâche de programmation en toute humilité et, entre autres choses, il évite les astuces malignes comme la peste. »⁸ La maligneté n’est pas une vertu. C’est un pari : celui de croire que vous pouvez retenir dans votre tête plus que vous ne le pouvez réellement, et le pari se règle en production, à vos dépens.

La conférence aboutit à une prescription qui se lit comme la charte fondatrice du logiciel correct par construction : « Nous ferons un bien meilleur travail de programmation, à condition d’aborder la tâche en pleine conscience de son immense difficulté, à condition de nous en tenir à des langages de programmation modestes et élégants, à condition de respecter les limitations intrinsèques de l’esprit humain et d’aborder la tâche en Programmeurs Très Humbles. »⁸ Les tests, dans ce cadre, sont fondamentalement insuffisants — non parce qu’ils sont inutiles, mais parce qu’ils ne peuvent jamais qu’échantillonner l’espace des entrées. La forme longue canonique de son avertissement, tirée de « Notes on Structured Programming », est sans ambiguïté : « Les tests d’un programme peuvent servir à montrer la présence de bugs, mais jamais à montrer leur absence ! »⁹ Si vous voulez l’absence de bugs, vous devez la prouver, et vous ne pouvez prouver que ce que vous pouvez comprendre.

Les manuscrits EWD comme pratique (années 1960–2002)

Pendant une quarantaine d’années, Dijkstra écrivit une série numérotée de manuscrits — mémos, preuves, comptes rendus de voyage, essais et argumentations — préfixés de ses initiales, « EWD ». La série va jusqu’à EWD1318, avec plus d’un millier de documents réels ; les numéros dépassent les documents parce qu’il attribuait un numéro lorsqu’il commençait un texte, et que tous les textes ne furent pas achevés.⁴¹⁰ La plupart furent composés à la main, dans une écriture d’une précision célèbre, au stylo-plume. Il ne rédigeait pas sur ordinateur. Il écrivait un manuscrit, le photocopiait et l’envoyait par la poste à un petit cercle de collègues, qui le copiaient et le transmettaient plus loin — un samizdat d’avant Internet qui donna aux EWD une influence démesurée au regard du fait que presque aucun ne fut formellement publié.⁴¹⁰ La série complète est aujourd’hui numérisée et librement accessible dans le E.W. Dijkstra Archive de l’Université du Texas à Austin.¹⁰

La pratique était indissociable de la philosophie. Écrire à la main, lentement, sans possibilité d’annuler, impose la même discipline que concevoir sans crayon ni papier : vous ne pouvez pas vous cacher derrière le volume ou la révision. Un argument tient ou ne tient pas, et vous vous y engagez à l’encre. Les EWD montrent ce que cela donne lorsqu’un ingénieur traite l’écriture elle-même comme un outil pour penser clairement, et la clarté comme l’unique objectif.

La méthode

La méthode est une conviction unique appliquée sans relâche pendant quarante ans.

Rendez la chose assez petite pour pouvoir raisonner dessus. L’algorithme du café, le flot de contrôle structuré, le système THE en couches, la distillation du dîner des philosophes — chacun est un acte de réduction d’un problème jusqu’à ce qu’un esprit humain puisse en retenir la totalité et la vérifier. La complexité que vous ne pouvez pas embrasser du regard est une complexité à laquelle vous ne pouvez pas vous fier.

Prouvez, ne testez pas. Les tests échantillonnent ; la preuve certifie. Le calcul des transformateurs de prédicats de Dijkstra existe pour que la preuve et le programme soient dérivés ensemble, et non pour que l’un soit écrit et l’autre greffé par-dessus. « Composés correctement, et non simplement déboggués jusqu’à la correction » : voilà la méthode en cinq mots.⁵

Traitez l’élégance comme une preuve, non comme une décoration. Lorsqu’une solution est laide, cette laideur est généralement le signe que le problème n’a pas été compris. L’élégance « décide entre le succès et l’échec » parce que la forme élégante est celle qui offre le moins d’endroits où se tromper.³

Écrivez pour penser. Les EWD n’étaient pas une documentation produite après le travail. Ils étaient le travail — le raisonnement rendu visible, dans un médium qui sanctionnait le flou. Concevoir sans crayon ni papier, puis confier le résultat au stylo-plume, c’est la même discipline deux fois.

Chaîne d’influence

Ceux qui l’ont façonné

Sa mère, la mathématicienne. Dijkstra lui attribuait son sens de l’élégance mathématique — l’instinct exercé de reconnaître quand une preuve n’est pas seulement valide mais nette. Cette distinction, entre un argument qui fonctionne et un argument qui est beau, devint l’axe de toute sa carrière. (Influence formatrice)

L’effort Algol 60. Dijkstra coconstruisit l’un des premiers compilateurs Algol 60, et la structure en blocs et la récursivité du langage lui fournirent la matière première de la programmation structurée. Algol fut la preuve qu’un langage de programmation pouvait être conçu pour la clarté plutôt qu’accrété par commodité. (Influence directe)

La tradition mathématique de la preuve. Formé comme mathématicien et physicien avant l’existence de l’« informatique », Dijkstra importa intégralement l’exigence de preuve. Pour lui, un programme était un objet mathématique, et la question n’était jamais « semble-t-il fonctionner ? » mais « pouvez-vous démontrer qu’il le doit ? ». (Influence formatrice)

Ceux qu’il a façonnés

Tout programmeur qui écrit du code structuré. La disparition du goto de la programmation quotidienne, l’universalité de la séquence/sélection/itération, et tout le vocabulaire de la concurrence — sémaphores, interblocage, exclusion mutuelle — sont son héritage, opérant invisiblement dans chaque base de code écrite depuis.

Les méthodes formelles et la vérification de programmes. Le calcul des transformateurs de prédicats et l’idéal du correct par construction sont les ancêtres directs de la vérification moderne, du model checking et du code porteur de preuve. Le regain actuel des logiciels système formellement vérifiés, c’est l’argument de Dijkstra rencontrant enfin un matériel assez rapide pour l’exécuter.

L’image que la discipline se fait d’elle-même. Plus que tout artefact précis, Dijkstra établit l’idée que la programmation est une branche des mathématiques appliquées méritant de la rigueur — et non un métier à apprendre par tâtonnements. La conscience du domaine, pour le meilleur et pour le pire, parle encore avec sa cadence.

Le fil conducteur

Dijkstra est la source d’où découle le reste de cette série. Le « bon goût » de Linus Torvalds — la réécriture où le cas particulier s’évanouit — c’est la simplicité-comme-correction de Dijkstra dans l’idiome d’un hacker du noyau : moins de branchements, c’est moins d’endroits où se tromper. Le noyau rapide et simple de John Carmack est la même soustraction, visant le plafond du matériel au lieu de la preuve. Et l’insistance d’Andrej Karpathy à reconstruire un système à partir de zéro pour le comprendre vraiment, c’est le « concevoir sans crayon ni papier » de Dijkstra coiffé d’un chapeau d’apprentissage profond. Les quatre sont en désaccord sur presque tout, sauf sur la seule chose qui compte : la structure élégante n’est pas appliquée par-dessus la solution correcte. Elle est la solution correcte. (Pont de la série)

Ce que j’en retiens

La phrase à laquelle je reviens est l’inversion : la simplicité est la condition préalable à la fiabilité, et non une récompense que l’on récolte après l’avoir atteinte. La plupart des logiciels lents et fragiles ne sont pas lents et fragiles parce que quelqu’un a sauté les tests. Ils sont lents et fragiles parce que personne ne les a jamais rendus assez petits pour être compris, de sorte que personne ne pouvait raisonner dessus, de sorte que la seule stratégie de qualité disponible était de tester jusqu’à ce que les bugs visibles cessent — ce qui, comme le disait Dijkstra, ne certifie rien. L’inversion est la même exigence que la qualité comme unique variable : la question n’est jamais « les tests sont-ils passés ? » mais « est-ce que je comprends cela assez bien pour savoir qu’il est correct ? ».

Dans le monde où je construis aujourd’hui — agents d’IA, boucles d’outils, systèmes qui génèrent du code plus vite qu’aucun humain ne peut le lire —, l’avertissement de Dijkstra est plus tranchant qu’il ne l’a jamais été. Quand un agent écrit mille lignes et que les tests sont au vert, c’est précisément la situation qu’il décrivait : la présence de bugs n’a pas été montrée, et leur absence ne peut l’être. Le geste de Dijkstra consiste à refuser de laisser la compréhension diminuer à mesure que la génération augmente — à exiger que le système reste assez petit, assez en couches et assez lisible pour que quelqu’un puisse encore le prouver correct. Cette discipline est la raison pour laquelle je considère la couche de vérification comme porteuse même quand aucun humain ne lit le code : les tests montrent la présence, pas l’absence, et un front d’onde de coches vertes n’est pas une preuve.

FAQ

Quelle est la philosophie de l’ingénierie d’Edsger Dijkstra ?

Dijkstra soutenait que la simplicité est la condition préalable à la fiabilité : un programme doit être assez simple pour qu’un humain le comprenne pleinement, car seul un programme compréhensible peut faire l’objet d’un raisonnement et être prouvé correct. Il affirmait que les programmes devaient être « composés correctement, et non simplement déboggués jusqu’à la correction », que les tests peuvent montrer la présence de bugs mais jamais leur absence, et que l’élégance n’est pas une décoration mais « un facteur qui décide souvent entre le succès et l’échec ». La maligneté, selon lui, était un vice, car elle excédait la capacité limitée de l’esprit humain.³⁵⁸⁹

Qu’a inventé Edsger Dijkstra ?

Dijkstra a inventé l’algorithme de plus court chemin qui porte son nom (conçu en 1956, publié en 1959), introduit le sémaphore et les opérations P/V pour coordonner des processus concurrents, construit le système de multiprogrammation THE en couches, formulé le problème du dîner des philosophes, fait progresser la programmation structurée, créé le concept d’auto-stabilisation dans les systèmes distribués, et développé le calcul des transformateurs de prédicats / de la précondition la plus faible pour dériver les programmes en même temps que leur preuve de correction (dans A Discipline of Programming, 1976). Il reçut le prix Turing de l’ACM en 1972.⁴⁵

Que signifie « Les tests révèlent la présence de bugs, jamais leur absence » ?

Cela signifie qu’un test ne peut que démontrer qu’un bug existe, en le déclenchant — il ne peut jamais démontrer qu’aucun bug n’existe, car aucun ensemble fini de tests ne couvre toutes les entrées possibles. Dijkstra l’énonça à la conférence de génie logiciel de l’OTAN en 1969 et en donna la forme longue canonique dans « Notes on Structured Programming » : « Les tests d’un programme peuvent servir à montrer la présence de bugs, mais jamais à montrer leur absence ! » Sa conclusion était que la confiance dans la correction doit venir de la preuve et de la conception de programmes assez simples pour faire l’objet d’un raisonnement, et non de l’accumulation de tests réussis.²⁹

Pourquoi Dijkstra écrivait-il à la main et diffusait-il les manuscrits EWD par photocopie ?

Les EWD étaient une série de plus d’un millier de manuscrits numérotés que Dijkstra écrivit sur une quarantaine d’années, la plupart à la main au stylo-plume, puis photocopiés et envoyés par la poste à un petit cercle qui les copiait et les transmettait plus loin. Écrire lentement à la main, sans touche pour annuler, imposait la même discipline que son habitude de concevoir des algorithmes sans crayon ni papier : cela forçait la clarté et sanctionnait le flou, car un argument confié à l’encre devait réellement tenir. La série complète est archivée et librement accessible à l’Université du Texas à Austin.⁶¹⁰

Sources