Vers un logiciel compréhensible
(gracefulliberty.com)- La programmation est difficile à lire, tester et maintenir, et la compréhension d’un projet se concentre souvent entre les mains d’une minorité ; au lieu d’automatiser l’écriture du code avec des LLM, il faut des abstractions qui réduisent l’étendue même du besoin de code
- Les LLM se sont diffusés aussi bien chez les développeurs que chez les non-développeurs, mais des problèmes majeurs subsistent : impact environnemental, base fondée sur du code volé, résultats incohérents et création de dépendance
- Le point de départ consiste à inverser la pratique qui veut qu’on écrive d’abord le code puis qu’on ajoute la documentation, pour passer à une programmation lettrée où la documentation vient d’abord et le code ensuite
- La programmation visuelle fondée sur des GUI et la programmation en langage naturel déterministe peuvent faire du code une simple représentation parmi d’autres, mais dans les environnements visuels, une conception accessible — comme l’intégration de lecteurs d’écran — est indispensable
- Des tentatives antérieures comme Eve et Inform, ainsi que des outils comme Entangled et ReTangled, montrent qu’il est possible de créer des logiciels compréhensibles à la fois pour les débutants et pour les experts
Les LLM ne sont pas le modèle cible
- Les LLM sont devenus des outils importants dans le développement logiciel industriel, et même des experts expérimentés utilisent des agents LLM pour tester, déboguer et écrire du code
- Des non-développeurs créent eux aussi avec des LLM, depuis des scripts personnels jusqu’à des outils de traitement de données scientifiques
- La programmation offre un point de départ peu clair et reste peu accessible à ceux qui ne veulent pas apprendre la syntaxe d’un langage donné et les détails de ses bibliothèques
- Si les LLM se répandent, ce n’est pas tant parce qu’ils sont excellents en programmation que parce que la programmation elle-même est un travail complexe et pénible
- Entre des piles logicielles incompatibles, un boilerplate sans fin et des bibliothèques délicates, les frictions abondent
- Le travail du développeur moyen se réduit moins à produire du code intéressant qu’à raccorder des bibliothèques entre elles
- Les LLM ont encore de gros problèmes
- Ils sont destructeurs pour l’environnement
- Ils reposent fondamentalement sur du code volé
- Ils génèrent du code incohérent
- Ils créent de la dépendance
- Le paradigme actuel de la programmation est insuffisant, mais les LLM aussi ; il faut une meilleure alternative
Abstraire plutôt qu’automatiser
- Renoncer aux LLM ne veut pas dire renoncer à l’automatisation, aux abstractions de haut niveau ni aux interfaces pensées pour les humains
- L’objectif n’est pas seulement de faciliter l’écriture du code, mais de s’attaquer à la pile logicielle sous-jacente afin de réduire le besoin même d’écrire du code
- Lorsqu’on ressent de façon répétée le besoin d’automatiser une couche d’abstraction, il est plus pertinent de l’abstraire jusqu’à la faire disparaître que de simplement l’automatiser
- Le fait que les LLM soient largement utilisés pour programmer montre le désir d’automatiser le processus d’écriture du code ; c’est surtout le signe qu’il faut abstraire la nécessité d’écrire du code elle-même
- Au lieu de forcer les humains à penser comme des ordinateurs, il faut une nouvelle couche d’abstraction plus proche de la manière dont les humains pensent naturellement
Une programmation où la documentation passe d’abord
- La première étape vers un logiciel compréhensible, c’est la documentation
- Si l’on veut que d’autres comprennent un logiciel, il faut l’expliquer
- L’approche habituelle consiste à écrire d’abord le code, puis à ajouter ensuite des commentaires de documentation ou des exemples d’utilisation
- L’approche proposée inverse l’ordre : écrire d’abord la documentation, puis ajouter le code
- On explique d’abord à une personne ce que fait le programme, puis on indique ensuite à l’ordinateur ce qu’il doit faire
- Ce concept est connu sous le nom de programmation lettrée
- Dans cette approche, au lieu de lire directement le code de quelqu’un d’autre en essayant d’en déduire l’intention, on lit d’abord la documentation pour comprendre cette intention, puis on vérifie le code
- Entangled en est une bonne implémentation
- C’est un tangler bidirectionnel qui extrait le code depuis la documentation pour le placer dans les fichiers source appropriés
- On peut modifier les blocs de code dans le document, et les changements effectués dans des fichiers de code ordinaires sont eux aussi propagés vers les blocs de code du document
- Les outils existants — tests, refactorisation, formatage du code — continuent de fonctionner sans support spécial de la programmation lettrée
- Le tangler n’ajoute qu’une faible surcharge au système de build, particulièrement modeste en comparaison d’un compilateur
- Cette approche ne supprime pas en soi la complexité du code, mais elle peut remplacer les LLM lorsqu’il s’agit de comprendre le code d’autrui
Faire disparaître le code : GUI et représentations multiples
- Le code est un concept hérité d’une époque ancienne, utilisé parce qu’il fallait interagir avec l’ordinateur par le terminal
- Même si l’informatique a changé au cours des 40 dernières années, rien n’oblige à continuer de communiquer avec les ordinateurs uniquement par des chaînes unidimensionnelles de symboles et de mots-clés obscurs
- Les GUI permettent souvent de manipuler plus facilement des concepts complexes que les interfaces textuelles, et elles sont souvent plus accessibles aux nouveaux utilisateurs
- L’IDE peut devenir autre chose qu’un simple endroit pratique pour éditer du code : il peut devenir une nouvelle manière d’interagir avec le développement logiciel
- Certains IDE offrent déjà ce type de fonctionnalités
- On peut aller plus loin et imaginer une programmation visuelle assez universelle et simple pour que n’importe qui puisse créer ce qu’il veut sans apprendre à coder
- Il n’est pas nécessaire d’abandonner complètement le code lui-même
- Une représentation GUI peut n’être qu’une représentation éditable parmi d’autres
- De la même façon que certaines personnes préfèrent les interfaces textuelles des systèmes d’exploitation, d’autres pourront continuer à préférer l’édition de logiciels fondée sur le code
- Mais le code n’a pas besoin d’être le choix par défaut, ni le seul choix possible
- La programmation visuelle peut être conçue pour être plus accessible, mais un environnement centré sur le visuel peut aussi exclure les personnes aveugles ou malvoyantes
- Une intégration solide avec les lecteurs d’écran est nécessaire
- Il faut aussi des représentations alternatives riches, compréhensibles par l’audio ou le toucher
Faire du langage naturel une abstraction déterministe
- Contrairement à l’idée selon laquelle les LLM ajouteraient une couche d’abstraction, les LLM ressemblent davantage à une couche d’automatisation qu’à une abstraction
- Une couche d’abstraction doit être prévisible et fiable : une intention de haut niveau doit être exprimée avec précision et cohérence à un niveau plus bas
- Les LLM interprètent les prompts de manière probabiliste et tentent d’en prédire l’intention, ce qui les rend imprévisibles
- Ils automatisent un processus qui approxime le résultat de manière aléatoire
- Si c’est une abstraction, c’est une abstraction extrêmement lossy
- Les progrès du traitement automatique du langage naturel (NLP) ouvrent la possibilité de construire un pipeline prévisible allant du langage naturel au langage machine
- L’objectif est de pouvoir saisir quelque chose comme un prompt de LLM tout en produisant, à chaque fois, un programme prévisible et robuste
- Non pas en distillant le travail des autres comme une moyenne de code volé, mais en construisant directement à partir de définitions
- Cette approche peut lier bien plus fortement documentation et code
- Si, dans la programmation lettrée, on remplace la partie code par du langage naturel, il peut ne rester que la documentation
- Un texte qui explique à une personne comment fonctionne un programme peut en même temps être un texte qui communique avec la machine
- Cette programmation en langage naturel doit être déterministe
- Le NLP peut servir à analyser la grammaire et le sens sans recourir aux capacités génératives des modèles transformer
- La grammaire analysée peut être directement convertie en une représentation intermédiaire, ensuite compilée selon les contraintes de la plateforme comme n’importe quel autre langage de programmation
- L’idée se rapproche de Inform, mais avec une reconnaissance syntaxique plus avancée et des connexions à un réseau de définitions plus large
- Grâce à cette qualité déterministe, le prompt devient du code de façon fiable et cohérente ; c’est une véritable couche d’abstraction fondamentalement différente des LLM
Tentatives précédentes : Eve et Inform
- Ces idées ne sont pas nouvelles, et il y a déjà eu des tentatives d’implémentation
- Eve est à la fois un langage de programmation et un IDE qui cherchaient à rendre la programmation plus accessible aux humains
- Il utilisait une approche de programmation lettrée
- Il insérait un langage de programmation orienté données et spécialisé dans un domaine dans des documents décrivant le comportement du logiciel
- Le code était subordonné au document, et l’ensemble de l’environnement de programmation reflétait ce choix
- Eve a aussi tenté de pousser plus loin cette idée en remplaçant son propre langage par des requêtes NLP
- Le projet n’était pas prêt à assumer la complexité du traitement du langage naturel
- En 2016, un NLP plus avancé n’était pas facilement accessible à une entreprise qui ne reposait pas sur le machine learning
- Une approche orientée GUI a aussi été expérimentée
- Un ancien contributeur d’Eve exprime lui aussi des préoccupations similaires sur la complexité des projets et les limites des LLM
- Eve s’est arrêtée parce qu’il s’agissait d’un projet ambitieux financé par le capital-risque qui n’a pas réussi à se monétiser, et il n’a pas été possible de voir ces idées arriver à maturité
- Inform est un langage déclaratif destiné à créer de la fiction interactive, et montre que ces concepts peuvent s’appliquer plus largement
- Le langage naturel est peut-être fondamentalement une abstraction qui fuit, mais son potentiel pour permettre à l’utilisateur moyen de contrôler directement son ordinateur mérite bien davantage d’attention
Étapes suivantes et travaux proposés
- Un projet appelé ReTangled est en cours de développement pour créer un logiciel compréhensible
- Il s’agit d’un tangler bidirectionnel compatible avec Entangled, écrit en Rust
- Son objectif est d’étendre autant que possible la programmation lettrée tout en restant étroitement intégré aux toolchains existantes à un niveau raisonnable
- Le projet n’en est encore qu’à ses débuts et les contributions sont les bienvenues
- Il est prévu d’écrire des textes plus complets sur la programmation visuelle, la programmation lettrée et la programmation en langage naturel
- À l’échelle de la communauté, il est proposé de reprendre le flambeau laissé par Eve, mais avec une approche légèrement différente
- L’objectif est de créer un environnement de programmation visuel ou en langage naturel bien documenté, accessible et utile aussi bien aux débutants qu’aux experts
- Le point de départ consiste à mieux documenter les logiciels, et l’objectif final est de renverser le concept même de programmation
1 commentaires
Commentaires sur Lobste.rs
Je ne suis pas certain que jeter le code, ou le subordonner à de la prose en langage naturel, soit une solution efficace au problème de l’accessibilité de la programmation.
Les langages de programmation sont une interface utilisateur qui équilibre les besoins des ordinateurs et des humains. Une notation formelle claire et bien conçue peut devenir un outil de pensée qui aide à la compréhension individuelle et à la transmission d’idées entre humains et machines.
Apprendre les langages de la famille APL m’a beaucoup marqué ; cela a pris du temps, mais une fois appris, j’ai pu garder en tête des problèmes plus vastes et penser avec davantage de précision. K permet de résoudre des problèmes avec seulement son esprit, du papier et un simple REPL, sans IDE complexe.
Les projets bien documentés et la programmation littéraire ont de la valeur, mais la documentation demande aussi du temps pour être lue, écrite et corrigée. Comme pour les tests, plus de documentation n’est pas forcément mieux ; je préfère des explications concises et structurées, ainsi que des programmes simples faciles à expliquer. Le code peut être de la poésie, mais la plupart des poèmes ne sont pas des programmes.
La plupart des gens n’apprendront pas ces mécanismes internes, donc je voudrais abaisser la barrière à l’entrée pour permettre à davantage de personnes de participer.
C’est pour cela, à mon avis, que les LLM sont populaires. Je vois souvent des non-programmeurs écrire du code avec des LLM pour accomplir une tâche, mais comme le dit l’article, les LLM ont de gros défauts qu’on voudrait éviter. Les gens devraient pouvoir modifier des jeux, créer des scripts et étendre des programmes en langage naturel ou via une interface utilisateur confortable.
L’expression « abolir le code » était peut-être un peu excessive, mais beaucoup de gens ne veulent pas penser au code, et ne devraient pas avoir à le faire.
Les programmeurs ont en quelque sorte abandonné les non-programmeurs.
Visual Basic est mort, PHP sans framework ne semble plus très vivant, et Access est pratiquement mort aussi. Il reste des outils ressemblant à des bases de données, comme Notion ou Airtable.
Les programmeurs aiment tellement écrire du code que beaucoup se sont éloignés des solutions simples à des problèmes simples.
Si Python a un temps déferlé sur le monde des non-programmeurs, c’est parce qu’il avait l’air simple, et que des outils comme Pandas semblaient faciles à utiliser. Fait intéressant, beaucoup de programmeurs n’aiment pas vraiment Python ni Pandas. Par exemple, voir du code qui utilise Pandas pour faire quelque chose qui se ferait facilement avec la bibliothèque standard peut vite devenir assez pénible.
Autrefois, même les non-programmeurs créaient des pages HTML et y mettaient des couleurs et des images. Aujourd’hui, si l’on demande à un programmeur de créer un site statique, cela s’accompagne d’une complexité absurde. Une partie est nécessaire, mais la plupart ne l’est absolument pas. Si l’on donnait à des non-programmeurs les procédures que les programmeurs utilisent pour créer un site simple, même les gens qui auraient pris plaisir à modifier du HTML il y a 20 ans s’enfuiraient en hurlant.
Il est profondément ironique et inquiétant que certaines choses soient aujourd’hui devenues bien plus difficiles.
CSS est devenu puissant, les navigateurs sont moins cassés, et il existe des assistants de codage personnels pour aider sur tout. C’est pareil pour Python pur : il suffit de l’utiliser tel quel. La programmation n’a jamais été aussi facile.
La complexité des stacks techniques modernes a généralement une raison d’être, mais il faut l’utiliser une fois que cette raison existe ; un débutant n’a absolument pas besoin de s’en servir.
Si les gens ne créent pas de sites HTML ou de programmes basiques, c’est parce qu’ils n’en ont pas envie. On pensait qu’à l’avenir tout le monde connaîtrait les bases de la programmation, mais il s’avère en réalité que les gens n’en ont tout simplement pas envie. On pourrait aussi soutenir que tout le monde devrait savoir faire l’entretien de base d’une voiture ou d’un vélo, mais les gens refusent. Cela ne veut pas dire que la tâche est difficile ou impossible, mais plutôt qu’ils n’ont pas la volonté de la faire.
À mon avis, la culture informatique du grand public n’a presque pas progressé, et cela n’a rien à voir avec la complexité de la programmation. Dans l’éducation, certains disent même que cette culture informatique semble régresser, mais il est difficile d’attribuer cela aux frameworks frontend complexes.
Je suis d’accord avec une grande partie de l’article. Par exemple, j’aime la programmation littéraire, mais je ne pense pas que la programmation elle-même soit mauvaise.
Une partie de la programmation est mauvaise, et la programmation pratiquée dans les entreprises de Big Tech l’est souvent dans l’ensemble. Mais écrire des programmes pour moi-même ou pour des personnes que j’aime reste agréable.
Je ne connaissais pas Entangled, mais cela me semble être une bonne idée, qui traite le plus gros problème de la programmation littéraire : le fait que les LSP et les outils existants ne la reconnaissent pas. C’est pour cela que, jusqu’ici, j’ai surtout utilisé la programmation littéraire avec des langages déclaratifs comme la configuration NixOS.
Avec une programmation littéraire bidirectionnelle, la vie pourrait devenir plus simple lorsqu’on utilise des langages non déclaratifs. Je compte essayer ReTangled.
Les GUI semblent surtout exister pour permettre aux dirigeants et aux niveaux supérieurs de croire que les employés font des choses qu’eux-mêmes comprennent et pourraient faire.
J’ai suivi un cours sur un outil ETL visuel en glisser-déposer, et tout ce que j’en ai retenu, c’est qu’il serait difficile de recréer quelque chose de presque identique au premier système et de versionner l’ensemble. En 2010, le système visuel en glisser-déposer que mon entreprise utilisait pour remplacer cron était similaire.
Pour un dirigeant, il est facile de glisser-déposer, mais pour les opérationnels, il devient difficile de trouver les erreurs, de maintenir versions et sauvegardes, et de réutiliser le travail.
Pour faire passer un prototype amusant à quelque chose de prêt pour la production, il faut beaucoup de gestion d’erreurs, de sérialisation, de désérialisation, de projection de types, etc. L’une de mes règles est qu’une excellente expérience utilisateur s’accompagne presque toujours d’une structure interne désordonnée.
Personnellement, je n’aime pas la majeure partie de ce travail, et par le passé il m’est arrivé de prendre des raccourcis ou de ne pas le faire du tout.
Je suis assez fortement d’accord. Si l’on regarde les éditeurs WYSIWYG, ils n’ont pas complètement remplacé le développement web, mais ils ont réduit une niche importante pour les personnes qui veulent seulement un site web basique ou vendre quelques produits simples.
Il reste encore beaucoup de domaines logiciels qui pourraient être simplifiés avec de bonnes interfaces GUI.
Si, aujourd’hui, on se contente de coller du code bout à bout ou de faire tourner des LLM à tout-va, la programmation via GUI pourrait en réalité être une meilleure option. Une grande partie du code que j’utilise souvent consiste aussi en des serveurs REST ; il n’y a aucune raison de ne pas pouvoir créer quelque chose pour cela.
Je partage le même objectif, et cela fait des années que je réfléchis à une stack technique qui fournirait exactement la solution que j’aimerais utiliser.
J’ai bien publié un projet appelé Curv, mais ce n’est qu’une petite partie d’un système bien plus beau qui n’existe encore que dans ma tête.
Des milliers d’autres personnes se sont aussi attaquées à ce problème. Vu son ampleur, il semble nécessiter un travail d’équipe, mais en pratique il s’agit surtout de petits projets menés en solo. Les personnes qui ont la vision la plus forte sont souvent celles qui ne veulent pas compromettre leur propre vision au profit d’objectifs d’équipe. Je ne sais pas comment résoudre cela.
Parmi les projets inspirants, il y a la vision Dynabook d’Alan Kay, Smalltalk qui en est issu, le projet ultérieur d’Alan Kay STEPS Toward the Reinvention of Programming, les travaux de Bret Victor, et en particulier son accomplissement remarquable, Dynamicland.
Comme communauté intéressée par ce sujet, il y a Feeling of Computing, autrefois appelée Future of Coding. Si vous avez d’autres choses à ajouter, dites-le-moi.
L’idée consistant à « saisir des instructions comme dans un prompt de LLM pour créer un programme complet, mais en le faisant fonctionner de manière prévisible et robuste à chaque fois » repose sur une énorme hypothèse : qu’il serait possible de parser une sémantique déterministe et cohérente à partir du langage naturel.
Mais je ne pense pas que ce soit vrai au départ. Même en mettant de côté le fait qu’on n’a pas encore réussi à le faire fonctionner correctement, je doute que ce soit possible.
Le langage contient trop de contexte. On peut prononcer la même phrase douze fois, et elle prendra à chaque fois un sens subtilement différent selon l’intonation, le public, le lieu physique, le média d’énonciation ou le moment de la journée. Les techniques traditionnelles de traitement du langage naturel ne gèrent fondamentalement pas cette flexibilité.
C’est précisément pour cela que les LLM existent. Plutôt que d’essayer de définir des règles contextuelles strictes qui n’existent probablement pas, on entraîne des modèles capables d’encoder la détection du contexte dans leurs poids. Il s’est avéré que cela fonctionne étonnamment bien.
C’est aussi pour cette raison que les gens utilisent les LLM. Ils peuvent prendre le contexte en compte bien mieux que n’importe quelle interface en langage naturel construite jusqu’ici, et produire la réponse attendue. De ce point de vue, cela fonctionne vraiment. Le traitement du langage naturel hors LLM n’a pas montré le même niveau de réussite.
Si vous vous intéressez aux environnements de programmation visuelle riches, Glamorous Toolkit est un bon exemple d’une direction possible : https://gtoolkit.com/
Je ne le considère pas encore comme une forme achevée, mais c’est un outil qui pousse plus loin ce qui existait déjà. À l’ère du code généré par LLM, il y a aussi des choses à dire sur les environnements basés sur des images.
Ce qui manque, ce sont des abstractions prévisibles qui dépassent les primitives couramment utilisées aujourd’hui par les programmeurs, à savoir des lignes de code organisées en fonctions et en modules.
En particulier, lorsque l’on transpose avec ces seuls éléments des exigences qui ne relèvent pas d’une simple transformation de données mais de la modélisation de systèmes externes complexes, on obtient une boule de boue qui grossit toujours plus, même lorsqu’elle est créée par des programmeurs humains. Les LLM ne font qu’en imiter l’apparence.