Philosophie de l'ingénierie : Yukihiro Matsumoto (Matz)

Points clés à retenir

• Concevoir pour les humains, pas pour les machines. Matz a fait du plaisir du programmeur la fonction objectif et a laissé le silicium régler l’addition. Chaque choix syntaxique répond à la question « comment une personne se sentira-t-elle en lisant ceci ? » avant « à quelle vitesse les octets se déplaceront-ils ? »
• La moindre surprise, c’est ma moindre surprise. Le principe n’est pas un sondage sur les attentes des débutants ; c’est un auteur expérimenté qui minimise sa propre frustration, mesurée après avoir bien appris Ruby.
• MINASWAN : la culture est un résultat de conception. « Matz est gentil, alors nous sommes gentils » montre que la communauté d’un langage est une surface que l’on peut concevoir, et non un simple accident découlant de sa grammaire.
• Ruby, c’est un seul goût appliqué sans relâche. Sa cohérence vient de la synthèse : Perl, Smalltalk, Lisp, Ada, Eiffel harmonisés en une seule voix plutôt qu’en moyenne d’un comité.

Le principe

« Pour moi, le but de la vie consiste en partie à éprouver de la joie. Les programmeurs ressentent souvent de la joie lorsqu’ils peuvent se concentrer sur le côté créatif de la programmation, c’est pourquoi Ruby est conçu pour rendre les programmeurs heureux. » – Yukihiro Matsumoto¹

La plupart des langages sont conçus en optimisant pour la machine. Vitesse de compilation, organisation de la mémoire, nombre d’instructions, tout ce qui importe au silicium. Matz a inversé la priorité. Il a décidé que l’humain au clavier était l’interlocuteur qui comptait, et que le rôle de la machine était de le servir. « Les machines devraient servir les êtres humains », a-t-il dit. « Souvent, les programmeurs servent les machines inconsciemment. Laissez les machines vous servir. »²

La joie est ici une contrainte de conception stricte, et non un sentiment vague déguisé en ingénierie. Si la joie de l’humain est la fonction objectif, alors chaque choix syntaxique, chaque nom de méthode, chaque valeur par défaut devient une question sur la manière dont une personne se sentira en lisant et en écrivant le code, plutôt que sur la vitesse de déplacement des octets. Matz a rendu le compromis explicite et honnête : Ruby dépenserait les cycles de la machine pour acheter le confort du programmeur. La même conviction fait du goût un système structurel plutôt qu’une décoration : l’expérience de la personne qui fait le travail devient la préoccupation porteuse au lieu d’une réflexion après coup appliquée à la fin.

Une seule décision gouverne tout ce qui suit : concevoir pour les humains, pas pour les machines. La syntaxe, la culture, la devise de la communauté en découlent toutes. Le reste de cet article retrace comment la quête du bonheur personnel d’une seule personne s’est durcie en une position d’ingénierie défendable, et pourquoi « servir l’humain » se révèle aussi rigoureux que « servir la machine », loin d’en être un repli.

Contexte

Yukihiro Matsumoto est né dans la préfecture d’Osaka, au Japon, le 14 avril 1965, et a grandi à Tottori à partir de l’âge de quatre ans.³ Il se décrit comme un passionné des langages, non pas un linguiste, mais un passionné des langages de programmation. Il était programmeur autodidacte jusqu’à la fin du lycée, et il a obtenu un diplôme en sciences de l’information à l’Université de Tsukuba, où il a travaillé dans un laboratoire de recherche axé sur les langages de programmation et les compilateurs.³ La fascination est venue d’abord ; Ruby en a été le résultat final.

Il a baptisé Ruby en février 1993 : le nom a surgi lors d’une discussion en ligne avec son collègue Keiju Ishitsuka, avant qu’une seule ligne de code n’ait été écrite, puis il l’a développé au fil des années suivantes.¹³ La motivation était l’insatisfaction. « Je voulais vraiment un langage de script véritablement orienté objet et facile à utiliser », a-t-il expliqué. « J’en ai cherché un, mais je n’en ai pas trouvé. »⁴ Perl était puissant mais, à son goût, pas vraiment orienté objet. Python était orienté objet mais, à son goût, pas assez agréable. Il a donc construit le langage qu’il voulait lui-même utiliser. Il a publié la première version publique le 21 décembre 1995.³

Le nom était une petite plaisanterie. Les deux hommes ont opté pour Ruby, une pierre précieuse, un clin d’œil à Perl, le langage auquel Ruby répondait en partie. Une perle, puis un rubis : un successeur nommé comme une mise à niveau progressive.⁴ Pendant des années, Ruby fut un phénomène principalement japonais, ses listes de diffusion et sa documentation étant en japonais. La percée mondiale est venue plus tard et de l’extérieur : David Heinemeier Hansson a construit Ruby on Rails par-dessus, et Rails a porté Ruby au reste du monde au milieu des années 2000.⁴ Le langage qu’une seule personne avait construit pour son propre bonheur est devenu le substrat des applications web de toute une génération.

Le travail

La conception de Ruby : la joie et le principe de moindre surprise

L’idée la plus citée à propos de Ruby est le « principe de moindre surprise » : le langage devrait se comporter comme on s’y attend, afin que l’on consacre son attention au problème et non à l’outil. Matz adhère au principe mais corrige une lecture erronée fréquente. « Le principe de moindre surprise, c’est le principe de ma moindre surprise », a-t-il dit. « Et cela signifie le principe de moindre surprise après avoir très bien appris Ruby. »⁵

Cette correction résume toute la philosophie en une seule phrase. Il n’a pas sondé les programmeurs pour faire la moyenne de leurs attentes. Il a conçu le langage pour minimiser sa frustration, pariant qu’un langage qui ravissait son propre auteur, un utilisateur expérimenté et exigeant, en ravirait d’autres une fois qu’ils auraient atteint la maîtrise. « Je voulais minimiser ma frustration pendant la programmation, donc je veux minimiser mon effort en programmation », a-t-il dit. « Je veux moi-même prendre du plaisir à programmer. »⁵ Ruby est un langage personnel qui a su passer à l’échelle. Sa cohérence n’est pas celle d’un comité ; c’est la cohérence d’un seul goût appliqué sans relâche.

Concevoir pour les humains, pas pour les machines

Matz traite le logiciel comme un médium destiné aux personnes, et non comme un ensemble d’instructions pour le matériel. « Ne sous-estimez pas le facteur humain », a-t-il dit. « Même si nous sommes devant des ordinateurs, ce sont des médias. Nous travaillons pour l’humain, avec l’humain. La plupart de nos tâches sont liées aux humains après tout. »⁵ Il pousse l’idée au-delà du slogan : l’interface, pour Matz, c’est le produit tout entier. « Si votre système a une mauvaise interface, personne ne l’utilisera. L’interface ou la surface du système, qu’elle s’adresse aux utilisateurs ou à d’autres machines, est donc très importante. »²

Le corollaire est un refus de se soumettre aux préférences de la machine. Interrogé sur la relation entre l’humain et l’ordinateur, Matz a été direct : « Nous sommes les maîtres. Ce sont les esclaves. »⁶ La machine existe pour servir l’intention du programmeur, et un langage qui force l’humain à penser comme un processeur inverse la relation. Les blocs de Ruby, son modèle où tout est objet, ses noms de méthodes lisibles – Array#each, Integer#times, String#upcase – dépensent tous de la complexité d’implémentation pour que la surface se lise comme une intention.

MINASWAN : la culture comme résultat de conception

L’artefact le plus inhabituel de Ruby n’est pas une fonctionnalité ; c’est une norme communautaire. Matz a une attitude célèbre pour sa gentillesse et sa patience, et cette disposition s’est propagée en une devise : MINASWAN – « Matz est gentil, alors nous sommes gentils ».⁷ Aux débuts de Ruby, lorsque les discussions s’envenimaient sur les listes de diffusion, des membres de la communauté la brandissaient pour instaurer un ton plus chaleureux. Elle s’est répandue jusqu’à devenir une identité.⁸

La leçon que la plupart des concepteurs de langages manquent, c’est que la culture est elle aussi une surface de conception. Un langage est plus que sa grammaire ; c’est l’expérience de poser une question et d’obtenir une réponse généreuse, de lire une bibliothèque dont l’auteur tenait à ce que vous compreniez. Matz a conçu la syntaxe, et par l’exemple il a également conçu la posture sociale qui l’entoure. Un langage construit pour rendre les programmeurs heureux a fait naître une communauté attachée à la bienveillance parce que la même valeur animait les deux : la communauté, c’est le principe de moindre surprise appliqué aux personnes.

mruby : la philosophie dans un espace contraint

En avril 2012, Matz a publié mruby en open source – une implémentation légère et embarquable de Ruby conçue pour fonctionner là où Ruby complet est trop lourd : microcontrôleurs, systèmes embarqués, appareils grand public.⁹ Elle respecte un sous-ensemble de la spécification Ruby ISO/IEC 30170 et se présente comme un petit interpréteur doté d’un compilateur de bytecode et d’une machine virtuelle, embarquable dans du C ou du C++ à la manière de Lua.¹⁰

mruby est intéressant précisément parce qu’il met la philosophie à l’épreuve sous pression. Lorsque l’on dispose de kilo-octets de RAM et d’aucun luxe en matière de cycles, « concevoir pour les humains » survit-il ? La réponse de Matz a été de conserver l’expressivité de Ruby tout en allégeant le poids de l’environnement d’exécution – d’apporter le plaisir d’écrire Ruby jusqu’à la couche du firmware plutôt que de forcer les développeurs embarqués à descendre vers le C. Le pari centré sur l’humain a tenu même là où il était le plus hostile.

La méthode

La méthode de Matz, c’est de l’empathie formalisée en une discipline de conception. Le geste récurrent consiste à se demander non pas « qu’est-ce qui est correct pour la machine ? » mais « que ressentira la personne ? » – puis à payer quel que soit le coût d’implémentation qu’exige cette réponse.

Le deuxième geste est la synthèse. Ruby est ouvertement dérivatif : la pragmatique et les expressions régulières de Perl, le modèle objet pur et le passage de messages de Smalltalk, la flexibilité de Lisp, des éléments d’Ada et d’Eiffel.⁴ Matz n’a pas inventé un nouveau paradigme. Il a emprunté les meilleures idées des langages qu’il admirait et les a harmonisées en une seule voix cohérente. Peu de concepteurs exercent ce goût : la discipline de prendre plutôt que d’inventer, et la discipline plus difficile encore de faire en sorte que les parties empruntées s’accordent au lieu de s’entrechoquer. Le principe de moindre surprise est en partie une cohérence interne : une fois que vous avez appris un coin de Ruby, le suivant se comporte de la manière que le premier vous a appris à attendre.

Le troisième geste est l’honnêteté quant au compromis. Matz n’a jamais prétendu que Ruby était le choix rapide, et il l’a dit clairement, plutôt que de revendiquer la chaleur tout en optimisant discrètement pour les bancs d’essai. Le coût est réel et concret : parce que tout en Ruby est un objet, même un entier est un objet de première classe, et l’arithmétique s’effectue en lui envoyant le message + plutôt qu’en exécutant une instruction machine brute.¹⁴ La commodité de 5.times ou de (1..n).map – traiter les nombres comme des objets auxquels on peut parler – se paie par une surcharge de répartition et d’allocation qu’un int en C n’engage jamais. Matz a choisi la surface lisible et a laissé l’environnement d’exécution absorber la facture, ce qui est exactement le pari énoncé clairement.

Chaîne d’influence

Qui l’a façonné

Larry Wall et Perl. Ruby a hérité de la sensibilité pragmatique et orientée résultats de Perl, ainsi que de son ADN d’expressions régulières. Matz lui-même a présenté Ruby comme une réponse à Perl – en conservant le côté pratique, en corrigeant ce qu’il percevait comme son absence de véritable orientation objet. (Influence directe)⁴

Smalltalk. La conviction que tout est un objet – les entiers, les classes, nil – et que le calcul s’effectue par l’envoi de messages provient de Smalltalk. C’est l’héritage structurel le plus profond du modèle objet de Ruby. (Influence directe)⁴

Lisp, Ada et Eiffel. Lisp a apporté la flexibilité et l’idée que le langage devrait se plier au programmeur ; Ada et Eiffel ont apporté d’autres éléments concrets de syntaxe et de conception. Ruby en est la synthèse. (Influences formatrices)⁴

Qui il a façonné

Le web de l’ère Rails. Ruby on Rails a fait de Ruby le langage par défaut de toute une génération de startups et a donné au « bonheur du développeur » un argument commercial : des programmeurs plus heureux livraient plus vite, de sorte que le langage centré sur l’humain remportait des projets sur l’économie, et pas seulement sur le ressenti.

L’attente de base de toute une génération. Après Ruby, les programmeurs s’attendaient à ce que les langages soient agréables – qu’ils se lisent comme de la prose, qu’ils pardonnent, qu’ils enchantent. Cette attente a redéfini le seuil que les langages plus récents devaient franchir pour être pris au sérieux.

Crystal et Elixir. Crystal emprunte la syntaxe de Ruby presque entièrement tout en se compilant en code natif via un backend LLVM.¹¹ Elixir, le langage fonctionnel de José Valim pour la BEAM, transporte la sensibilité ergonomique de Ruby dans le monde concurrent ; Valim cite son « expérience antérieure en Ruby » pour nombre de ses constructions empruntées.¹² L’esthétique de Ruby a survécu à son environnement d’exécution. (Lignée stylistique)

Le fil conducteur

Voici la tension productive. Matz optimise pour le bonheur humain et reconnaît honnêtement qu’il dépense les cycles de la machine pour y parvenir. L’autre pôle de l’ingénierie optimise pour la machine – John Carmack comptant les cycles jusqu’à ce que l’image tienne dans le budget, Linus Torvalds défendant le « bon goût » comme la structure de données qui fait disparaître le cas particulier. Carmack et Torvalds demandent ce que le matériel mérite ; Matz demande ce que l’humain mérite. Aucun des deux pôles n’a tort. Les meilleurs systèmes vivent dans la dispute entre les deux – assez expressifs pour qu’une personne prenne plaisir à les écrire, assez disciplinés pour que la machine ne soit pas insultée. Matz est la preuve que « concevoir pour l’humain » est une position d’ingénierie légitime et rigoureuse, et pas seulement un confort. (Pont de la série)

Ce que j’en retiens

Je construis des outils pour développeurs et des infrastructures d’orchestration pour agents d’IA, et le pari de Matz est celui que je continue de faire : l’humain dans la boucle est l’interlocuteur qui compte. Un agent de programmation, tout comme un langage de programmation, est une interface entre l’intention d’une personne et l’exécution d’une machine. S’il vous surprend, vous combat, ou vous force à penser comme la machine au lieu de penser au problème, il a échoué – aussi astucieux que soient ses rouages internes. Tout l’intérêt de ces rouages internes est de rendre l’expérience lisible pour la personne. C’est aussi pourquoi je garde la surface honnête et la pile mince – le manifeste sans build, c’est le principe de moindre surprise appliqué à une chaîne d’outils. Et tout comme Matz refusait de prétendre que Ruby était rapide, je préfère être honnête sur le compromis plutôt que de le cacher : la qualité est la seule variable, et le bonheur du programmeur fait partie de la qualité, il ne s’y oppose pas.

FAQ

Quelle est la philosophie d’ingénierie de Yukihiro Matsumoto ?

Matz conçoit des langages de programmation pour le bonheur et la productivité de l’humain plutôt que pour l’efficacité de la machine. Son but déclaré : « Ruby est conçu pour rendre les programmeurs heureux. »¹ Il traite l’expérience du programmeur – lisibilité, joie, moindre surprise – comme la contrainte de conception primordiale, et accepte un environnement d’exécution plus lent comme le prix honnête de ce service. « Les machines devraient servir les êtres humains », a-t-il dit. « Laissez les machines vous servir. »²

Qu’est-ce que le principe de moindre surprise dans Ruby ?

C’est l’idée que le langage devrait se comporter comme un utilisateur expérimenté l’attend, en minimisant les frictions. Matz précise que cela signifie « le principe de ma moindre surprise » – il a conçu Ruby pour minimiser sa propre frustration en tant qu’utilisateur expérimenté, et « le principe de moindre surprise après avoir très bien appris Ruby », et non la surprise d’un débutant le premier jour.⁵

Que signifie MINASWAN ?

MINASWAN signifie « Matz est gentil, alors nous sommes gentils » – une devise de la communauté Ruby née de l’attitude gentille et patiente de Matsumoto. Les premiers rubyistes la brandissaient pour instaurer un ton généreux sur les listes de diffusion, et elle est devenue une partie de l’identité culturelle de Ruby.⁷⁸ Elle reflète l’idée que la communauté d’un langage est elle-même une surface de conception.

Quels langages ont influencé Ruby ?

Ruby est une synthèse délibérée. Il a puisé la sensibilité pragmatique et les expressions régulières de Perl, le modèle objet pur et le passage de messages de Smalltalk, la flexibilité de Lisp, ainsi que des éléments d’Ada et d’Eiffel. Matz a combiné les fonctionnalités qu’il admirait en un seul langage cohérent plutôt que d’inventer un nouveau paradigme.⁴

Sources