La philosophie de l'ingénierie : Rich Hickey, le simple n'est pas le facile

L’essentiel à retenir

• Le simple n’est pas le facile. Simple veut dire dénoué – une seule préoccupation par chose – et c’est objectif ; facile veut dire familier et à portée de main, et c’est subjectif. Nous choisissons sans cesse le facile et le baptisons à tort « simple ».
• L’entrelacement est la racine de la complexité. La complexité ne tient pas au nombre de pièces, mais à leur degré d’enchevêtrement. Tresser l’état au temps, l’identité au comportement, ou la politique au mécanisme, voilà ce qui produit un système devant lequel on ne peut plus que prier.
• Désentrelacez sans relâche. Tirez les préoccupations tressées en pièces indépendantes que vous composez délibérément. La simplicité est « un choix » qui « exige une vigilance de tous les instants » – elle n’arrive jamais en saisissant l’outil familier.
• Préférez les valeurs aux emplacements, les données aux objets. Faites de l’immuabilité la valeur par défaut et laissez le passé s’accumuler sous forme de faits immuables plutôt que d’écraser l’état sur place – la discipline qui sous-tend à la fois Clojure et Datomic.

Le principe

« Les racines de ce mot sont “sim” et “plex”, ce qui signifie “un seul pli ou une seule tresse” […] juste à côté de “complex”, ou à l’opposé, qui signifie “tressé ensemble” ou “plié ensemble”. » – Rich Hickey, Simple Made Easy¹

Presque tout débat sur la qualité logicielle est en réalité deux débats déguisés sous un seul mot, et l’apport de Rich Hickey consiste à les disjoindre. Simple et facile ne sont pas synonymes. Ils ne se situent même pas sur le même axe : l’un mesure la chose, l’autre mesure votre distance à elle. Simple vient du latin simplex – un pli, une tresse, une torsade. Il décrit la chose elle-même : combien de préoccupations s’y trouvent entrelacées. C’est objectif, et son contraire est complexe – tressé ensemble, replié sur soi. Facile, en revanche, dérive d’une racine signifiant « être proche », la même racine qu’adjacent.² Facile décrit votre rapport à la chose : combien elle est à portée de main, familière, peu coûteuse à entreprendre. C’est subjectif, et son contraire est difficile.¹²

Une fois cette distinction perçue, vous ne pouvez plus ne pas la voir. L’outil que vous saisissez parce qu’il est à un npm install de distance est facile. Savoir s’il est simple – s’il emmêle la persistance dans votre validation, dans votre UI, dans vos règles métier – est une tout autre question, et la réponse est généralement non. Nous choisissons constamment le facile en l’appelant simple, puis nous nous noyons dans la complexité que nous avons invitée. Le mot de Hickey pour désigner l’acte d’emmêler est complect : « entrelacer, enchevêtrer ou tresser ».³ L’entrelacement est le péché originel. C’est lui qui transforme un système que vous pourriez raisonner en un système devant lequel vous ne pouvez plus que prier, car dès lors que deux préoccupations sont tressées ensemble, vous ne pouvez plus toucher à l’une sans comprendre l’autre et la mettre en péril.

La discipline consiste donc à désentrelacer – à tirer sans relâche les préoccupations tressées en pièces indépendantes – et Hickey ne mâche pas ses mots sur le prix à payer. « La simplicité est un choix », dit-il. « C’est votre faute si vous n’avez pas un système simple. »⁴ Elle ne survient pas en saisissant l’outil familier ; elle advient par une « vigilance de tous les instants » et un soin délibéré.⁴ Voilà tout le principe en cinq mots : le simple n’est pas le facile. La simplicité est le chemin plus ardu, choisi, dénoué, et c’est le seul qui produit des intérêts composés. La même conviction sous-tend l’idée que la qualité est la seule variable – on n’aboutit pas à un système propre en prenant à chaque fois le pas commode ; on le choisit, à contre-courant, à chaque fois.

Le contexte

Rich Hickey est un programmeur indépendant qui a passé une vingtaine d’années à écrire des systèmes en C++, Java et C# pour gagner sa vie avant de bâtir ce pour quoi il est connu.⁵ Il savait construire de grands systèmes dans ces langages, et sa conclusion après vingt ans n’était pas qu’il leur manquait des fonctionnalités. C’était que c’étaient des machines à entrelacer – ils rendaient le tressage des préoccupations sans effort et n’offraient presque aucune aide pour les démêler.

Alors il a bâti l’alternative lui-même, seul. À partir de 2005 environ, Hickey a consacré près de deux ans et demi à développer Clojure – en grande partie sur ses propres fonds, sans salaire : un Lisp pour la machine virtuelle Java qui ferait de l’immuabilité et de la simplicité la voie de moindre résistance plutôt qu’un acte d’héroïsme.⁵ Il l’a publié en 2007. Aucune entreprise derrière, aucun comité, aucune subvention. Un seul programmeur qui, ayant vu la maladie de près, a décidé de consacrer des années de sa propre réserve à bâtir le remède. Il a ensuite créé Datomic, une base de données immuable,⁵ et donné une série de conférences – Simple Made Easy, The Value of Values, Hammock-Driven Development, Are We There Yet? – qui constituent, ensemble, le corpus de philosophie de conception le plus influent de la programmation fonctionnelle moderne.⁶

Le travail

Simple Made Easy : simple contre facile, et l’entrelacement

Donnée à Strange Loop en septembre 2011, Simple Made Easy est la conférence qui a réorganisé la façon dont toute une génération de programmeurs parle de la complexité.¹ Toute sa force vient de son refus de laisser simple et facile vouloir dire la même chose. Simple porte sur le construit – est-ce un seul pli, ou plusieurs tressés ensemble ? Facile porte sur vous – est-ce à portée de main, familier, dans les limites de votre capacité actuelle ? On peut avoir des choses simples mais peu familières (difficiles à apprendre, faciles à vivre) et des choses faciles mais complexes (familières, confortables et discrètement ruineuses). La plupart de ce que l’industrie vend comme « productivité » relève de la seconde catégorie.¹

Le verbe au cœur de tout cela est complect : tresser, entrelacer, enchevêtrer.³ L’entrelacement est ce qui rend un système complexe – non pas le nombre de pièces, mais leur degré d’enchevêtrement. L’état entrelace la valeur et le temps. Les objets entrelacent l’état, l’identité et le comportement. L’héritage, les ORM, les conditionnelles éparpillées dans une méthode – chacun tresse des préoccupations qui auraient pu rester distinctes. Et le coût d’une tresse ne se paie pas une seule fois ; il se paie à chaque modification future, car vous ne pouvez plus toucher à un brin sans perturber tous les autres.

Le remède consiste à désentrelacer – à séparer les brins en choses indépendantes que vous pourrez composer plus tard, selon vos propres termes. L’affirmation de Hickey, et elle est forte, est que désentrelacer n’est pas une perte de puissance. « Vous pouvez écrire un système tout aussi sophistiqué avec des outils radicalement plus simples », dit-il – les mêmes programmes, mais que vous pouvez réellement raisonner, modifier et auxquels vous pouvez faire confiance.⁴ La simplicité n’est pas le sous-ensemble de débutant de la capacité. C’est la discipline d’expert qui consiste à refuser de tresser.

Clojure : un Lisp pour la JVM, les données plutôt que les objets

Clojure est le principe rendu exécutable : un dialecte Lisp dynamique et fonctionnel qui tourne sur la JVM, conçu par Hickey comme « un Lisp pour la programmation fonctionnelle en symbiose avec une plateforme établie conçue pour la concurrence ».⁷ Deux décisions encodent la philosophie. D’abord, l’immuabilité est la valeur par défaut, pas une option – les structures de données fondamentales de Clojure sont immuables et persistantes, si bien que la chose la plus naturelle à écrire est aussi celle qui ne peut être corrompue par une mutation lointaine.⁷ Ensuite, les données plutôt que les objets : au lieu d’un foisonnement de classes sur mesure, chacune avec son état privé et son comportement tressés ensemble, Clojure privilégie « de nombreuses fonctions définies sur peu de structures de données primaires » – séquences, maps, vecteurs, ensembles.⁷ Utilisez simplement des maps. Utilisez simplement des données.

Ce partage, c’est du désentrelacement au niveau de la grammaire même d’un langage. Les objets tressent ensemble l’état, l’identité et le comportement en une seule chose scellée ; Clojure les disjoint – des valeurs immuables pour ce qu’une chose est, de simples fonctions pour ce que vous lui faites, des types de référence explicites pour le changement géré au fil du temps. En faisant de la JVM la plateforme plutôt qu’un adversaire à combattre, Hickey a aussi désentrelacé le langage de l’environnement d’exécution : Clojure obtient gratuitement la maturité, les bibliothèques et les performances de la JVM, et dépense tout son budget de nouveauté sur le seul modèle de l’état et du temps.⁷

The Value of Values : l’immuabilité et Datomic

The Value of Values porte l’argument de l’immuabilité d’un cran plus haut, jusqu’à la base de données elle-même. La cible de Hickey est ce qu’il appelle la programmation orientée emplacement (PLOP) : « chaque fois qu’une information nouvelle remplace une information ancienne, vous faites de la programmation orientée emplacement ».⁸ Nous mettons à jour un enregistrement sur place, l’ancienne valeur disparaît, et avec elle l’histoire. Il soutient que c’est un héritage d’une époque de mémoire rare, et que cela jette précisément ce dont une entreprise a besoin pour raisonner – le passé. Une valeur, à l’inverse, est immuable par définition : un fait est « quelque chose qui s’est produit, dont on sait qu’il s’est produit », et un fait ne peut être mis à jour, seulement supplanté par un fait plus récent.⁸ Un nouveau président n’écrase pas l’ancien ; il s’ajoute.

Datomic est cette idée construite en base de données. Elle est fondamentalement immuable : « Une base de données Datomic est un ensemble de faits atomiques immuables appelés datoms », et « les transactions Datomic ajoutent des datoms, sans jamais les mettre à jour ni les supprimer, de sorte que vous disposez d’une piste d’audit complète ».⁹ Comme rien n’est jamais écrasé, la base peut être traitée comme une valeur à un instant donné – vous pouvez l’interroger « as-of » n’importe quel instant passé avec les mêmes requêtes que vous lancez sur le présent, sans aucune modification.⁹ La base cesse d’être un unique emplacement mutable et devient une série de valeurs au fil du temps. L’état, l’identité et le temps – désentrelacés, dans un magasin de données de production.

Hammock-Driven Development : penser d’abord

Le pendant de tout cela est une conférence sur le moment où s’accomplit le vrai travail, et la réponse de Hickey est : avant de toucher le clavier. Dans Hammock-Driven Development, il soutient que « l’endroit le moins coûteux pour corriger les bugs, c’est au moment où vous concevez votre logiciel », et que la plupart des défaillances logicielles graves sont des défaillances de conception erronée – nous n’avions pas compris le problème avant de commencer à le résoudre.¹⁰ Le remède est d’énoncer le problème explicitement, de rassembler les faits et les contraintes, puis de penser – y compris en confiant le problème à votre « esprit d’arrière-plan », qui établit les connexions que votre « esprit éveillé » analytique ne peut forcer.¹⁰ Le hamac est le meuble littéral pour ne rien faire d’autre que penser, sans être dérangé.

Le développement piloté par le hamac est la pratique qui rend la simplicité possible tout court. Vous ne pouvez pas désentrelacer un système que vous ne comprenez pas encore, et vous ne pouvez pas le comprendre en vous précipitant pour compiler. Le développement piloté par le hamac est la moitié avant, peu glorieuse, du simple n’est pas le facile : la réflexion délibérée, lente, vigilante qui doit avoir lieu avant que la conception dénouée puisse apparaître.

La méthode

La méthode tient en une distinction – le simple n’est pas le facile – appliquée avec une obstination peu commune à travers un langage, une base de données et une manière de travailler.

Séparez « simple » de « facile » avant chaque décision. Demandez-vous, de tout outil ou de toute conception : est-ce dénoué (simple), ou simplement familier et à portée de main (facile) ? Ce sont des axes différents, et les confondre, c’est ainsi que la complexité se glisse, déguisée en productivité.¹²

Traquez l’entrelacement et désentrelacez-le. La complexité n’est pas le compte des pièces ; c’est leur degré d’enchevêtrement. Repérez où l’état est tressé au temps, l’identité au comportement, la politique au mécanisme – et tirez les brins en pièces indépendantes que vous composez délibérément.³

Préférez les valeurs et les données aux emplacements et aux objets. Faites de l’immuabilité la valeur par défaut. Représentez l’information sous forme de données simples – maps, vecteurs – et agissez dessus avec des fonctions, plutôt que de sceller l’état et le comportement ensemble à l’intérieur d’objets.⁷⁸

Traitez le passé comme une valeur, non comme un état écrasé. Une information nouvelle doit s’ajouter, non détruire. Un système qui accumule des faits immuables au fil du temps peut être raisonné, audité et interrogé à n’importe quel instant – ce qu’un emplacement écrasé sur place ne pourra jamais.⁸⁹

Pensez avant de taper. L’endroit le moins coûteux pour corriger un défaut, c’est dans la conception. Énoncez le problème, confiez-le à votre esprit d’arrière-plan, et méritez la conception simple en comprenant le problème d’abord.¹⁰

Acceptez que la simplicité soit ardue et choisie. Elle n’advient pas en saisissant la chose facile. « La simplicité est un choix », et elle exige une « vigilance de tous les instants ». Le chemin commode et le chemin simple sont rarement le même chemin.⁴

La chaîne d’influence

Qui l’a façonné

Lisp et John McCarthy. Clojure est, selon les propres mots de Hickey, « un Lisp non contraint par la rétrocompatibilité » – l’homoiconicité du code-comme-donnée et la puissance des macros viennent en droite ligne de la lignée de McCarthy, étendue aux maps et aux vecteurs plutôt qu’aux seules listes.⁷ (Influence directe)

John Backus et la tradition de la programmation fonctionnelle. La conférence Turing de Backus en 1977, Can Programming Be Liberated from the von Neumann Style?, est l’argumentaire canonique contre l’informatique pilotée par l’affectation et orientée emplacement. La guerre de Hickey contre la programmation orientée emplacement et l’état mutable est cet argument porté en production. (Influence formatrice)

La machine virtuelle Java. Plutôt que de traiter l’environnement d’exécution comme un ennemi à faire disparaître par l’abstraction, Hickey a fait de la JVM la plateforme et a bâti le langage par-dessus – un désentrelacement délibéré du « langage » et de l’« environnement d’exécution » qui a donné à Clojure maturité et portée dès le premier jour. (Influence directe)

La pensée relationnelle et orientée valeur. La vision de Datomic, qui voit les données comme des faits immuables accumulés au fil du temps, interrogeables à n’importe quel instant, descend de la séparation, propre à la tradition relationnelle, entre les faits et leur stockage – l’idée que l’information a une existence indépendante de l’emplacement qui la détient à un moment donné.⁸⁹ (Influence formatrice)

Qui il a façonné

La renaissance de la programmation fonctionnelle. Clojure, aux côtés de Scala et d’autres sur la JVM, a contribué à faire passer la programmation fonctionnelle de la curiosité académique à la production grand public, et les conférences de Hickey sont devenues le vocabulaire commun – « simple », « facile », « complect » – que les programmeurs en exercice emploient désormais pour débattre de conception.

L’immuabilité, popularisée. L’idée que des données immuables par défaut sont la valeur par défaut raisonnable, et non une contrainte exotique, s’est propagée bien au-delà de Clojure. C’est aujourd’hui un acquis de base dans la conception des langages et des bibliothèques à travers toute l’industrie.

React, Redux et le monde du front-end. Le modèle orienté valeur – état immuable, transformations pures sur les données, identité et état disjoints – est la colonne vertébrale conceptuelle de React et surtout de Redux. Toute une génération d’ingénieurs front-end a absorbé la pensée-valeur de Hickey sans toujours savoir de qui elle venait.

Le fil conducteur

John Carmack réduit un moteur de rendu à son cœur rapide et simple et refuse toute fonctionnalité qui tresserait de la lenteur dans la boucle interne ; Hickey réduit un système à ses préoccupations dénouées et refuse toute abstraction qui les entrelacerait. Tous deux traitent la simplicité comme la chose ardue et choisie plutôt que comme l’option par défaut. Et là où Linus Torvalds prise le « bon goût » qui fait disparaître un cas particulier dans le cas général, Hickey prise le désentrelacement qui fait que deux préoccupations enchevêtrées se dressent à part comme une seule – le même instinct vu de deux bouts opposés : la bonne structure n’est pas un ornement posé sur le problème, c’est le problème correctement séparé en ses véritables parties. Yukihiro Matsumoto a optimisé Ruby pour ce qu’on ressent à l’écrire – le facile, dans le vocabulaire de Hickey – tandis que Hickey a optimisé pour ce que la chose est – le simple ; ensemble, ils cartographient les deux axes que Hickey a passé une conférence entière à nous supplier de cesser de confondre. (Pont de la série)

Ce que j’en retire

La leçon que je garde, c’est que le facile est un piège déguisé en vertu. Presque chaque regret dans une base de code a commencé comme un recours raisonnable à la chose à portée de main – la bibliothèque commode, la mutation rapide, la responsabilité de plus repliée dans une classe qui existait déjà. Rien de tout cela n’a paru être une erreur, parce que le facile n’en a jamais l’air. Le don de Hickey, c’est le vocabulaire pour le saisir sur le moment : s’arrêter et se demander est-ce simple, ou juste facile ? et savoir que la réponse honnête est généralement la plus malcommode. C’est le même étalon que la qualité comme seule variable – la question n’est jamais « que puis-je atteindre le plus vite ? » mais « qu’est-ce qui est réellement dénoué ici ? ».

Dans le monde où je bâtis désormais – des agents, des boucles d’outils, du code de cadre d’agent où l’état, les prompts, les nouvelles tentatives et les effets de bord adorent se tresser en une seule chose ingouvernable – la tentation est le facile maximal : empiler les frameworks, étaler l’état sur toute la boucle, entrelacer la logique de décision avec l’I/O et avec la journalisation jusqu’à ce que plus personne ne puisse changer une partie sans mettre en péril le tout. Le geste à la Hickey consiste à désentrelacer : tirer la politique hors du mécanisme, rendre l’état immuable là où c’est possible, traiter chaque exécution comme une valeur plutôt que comme un emplacement que j’écrase. Cette conviction – que le goût est un système technique que l’on choisit avec vigilance, et non une vibe dont on hérite en saisissant ce qui est proche – est le fil conducteur qui relie un Lisp autofinancé en 2007 à un cadre d’agent de 2026. Le simple n’est pas le facile. Choisissez-le quand même.

FAQ

Quelle est la différence entre simple et facile ?

Dans la formulation de Rich Hickey issue de Simple Made Easy, simple et facile relèvent d’axes entièrement différents. Simple vient du latin simplex – « un seul pli ou une seule tresse » – et décrit la chose elle-même : combien peu de préoccupations s’y trouvent entrelacées. C’est objectif, et son contraire est complexe (« tressé ensemble »).¹ Facile dérive d’une racine signifiant « être proche », la même racine qu’adjacent ; il décrit votre rapport à la chose – combien elle est familière et à portée de main.² C’est subjectif, et son contraire est difficile. Une chose peut être simple mais peu familière, ou facile mais profondément complexe. Le propos de Hickey est que nous choisissons sans cesse le facile et le baptisons à tort simple, et que nous payons la complexité plus tard.¹

Que signifie « complect » ?

Complect est le verbe que Hickey a ressuscité dans Simple Made Easy pour désigner l’acte de tresser des préoccupations ensemble. Il le définit sans détour : « Cela signifie entrelacer, enchevêtrer ou tresser. »³ L’entrelacement est ce qui rend un système complexe – non pas le nombre de pièces, mais leur degré d’enchevêtrement. Quand deux préoccupations sont entrelacées (disons, l’état et le temps, ou l’identité et le comportement), vous ne pouvez plus modifier l’une sans comprendre l’autre et la mettre en péril. Le remède est de désentrelacer : tirer les brins en pièces indépendantes que vous pouvez composer délibérément. Hickey traite le désentrelacement comme la discipline fondamentale de la construction de systèmes simples.³

Qu’a construit Rich Hickey ?

Rich Hickey est un programmeur indépendant qui a créé Clojure, un dialecte Lisp dynamique et fonctionnel qui tourne sur la machine virtuelle Java. Il l’a développé en grande partie seul sur près de deux ans et demi, dont une bonne part autofinancée et sans salaire, et l’a publié en 2007.⁵⁷ Il a ensuite créé Datomic, une base de données immuable qui n’écrase jamais les données mais accumule des faits immuables (« datoms ») au fil du temps, de sorte que la base peut être interrogée comme une valeur à n’importe quel instant passé.⁹ Il est aussi largement connu pour une série de conférences – Simple Made Easy, The Value of Values, Hammock-Driven Development et Are We There Yet? – qui ont façonné la façon dont l’industrie parle de complexité, d’immuabilité et de conception.⁵⁶

Rich Hickey a-t-il dit « les programmeurs connaissent les bénéfices de tout et les compromis de rien » ?

Cette formule est très largement attribuée à Hickey et capture sa pensée à la perfection, mais elle n’apparaît pas mot pour mot dans les transcriptions de ses conférences principales ; c’est une paraphrase cristallisée qui a circulé à travers des livres et des conférences.¹¹ La version primaire la plus proche, mot pour mot, se trouve dans Design, Composition, and Performance, où il invite à démonter une solution « pour voir non seulement les bénéfices, n’est-ce pas ? Ceux-là sont généralement assez évidents. Mais aussi les compromis : quelle part de tout cela ne va pas fonctionner ? ».¹² Le sentiment est sans équivoque le sien – que les ingénieurs surpondèrent ce qu’un outil leur apporte et sous-examinent ce qu’il coûte – mais l’aphorisme percutant est à traiter comme une paraphrase plutôt que comme une citation directe.

Sources