- Imputer la difficulté de la programmation aux symboles formels nourrit l’attente erronée selon laquelle, si la machine comprenait le langage naturel, la charge pesant sur l’humain diminuerait
- Les dangers des premiers langages machine ont été partiellement atténués par les langages de programmation de haut niveau, mais l’essentiel demeure : seules les mauvaises réponses ont souvent été remplacées par des messages d’erreur, tandis que la nécessité d’instructions précises subsiste
- Une interface en langage naturel n’est pas une solution de partage du travail : elle peut au contraire accroître les coûts de coopération et de communication entre l’humain et la machine, et alourdir la charge des deux côtés
- L’évolution des mathématiques montre que les systèmes de symboles formels créés par des figures comme Vieta, Descartes, Leibniz et Boole ont été des outils clés pour traiter des raisonnements complexes
- Si la programmation en langage naturel avait été le mode d’entrée/sortie de base, l’informatique aurait probablement suivi un long détour avant de revenir à des systèmes formels réellement utilisables
Attentes et illusions autour de la programmation en langage naturel
- Dès les débuts du calcul automatique, certains ont considéré comme un défaut le fait que programmer exige l’attention et la précision requises par des symboles formels
- Ils voyaient comme un problème le fait que la machine exécute rigoureusement même des commandes erronées, et espéraient une machine plus « raisonnable » qui rejetterait les petites erreurs administratives
- Le langage machine, presque dépourvu de redondance, constituait une interface dangereuse entre l’humain et la machine
- C’est dans ce contexte qu’ont été développés les langages de programmation de haut niveau
- Avec le temps, beaucoup de petites erreurs ont commencé à produire des messages d’erreur plutôt que des résultats faux
- Mais la machine abstraite correspondant au langage de programmation reste un automate qui exécute fidèlement les instructions données, et peut aussi exécuter des instructions dénuées de sens
- La proposition de commander la machine en langage naturel repose sur l’idée que l’on pourrait réduire la charge humaine, même au prix d’une machine plus complexe
- Cette logique n’est plausible que si l’on considère que « l’obligation d’utiliser des symboles formels » est la source de la difficulté
- Modifier l’interface ne consiste pas simplement à répartir le travail, mais ajoute des coûts de coopération et de communication à travers l’interface
- L’expérience montre qu’un changement d’interface peut fortement accroître la quantité de travail des deux côtés, d’où la préférence croissante pour une « interface étroite »
La manière dont les symboles formels étendent la pensée
- Dans l’histoire des mathématiques, les approches fondées sur le langage naturel ou sur les figures ont montré leurs limites à plusieurs reprises
- Les mathématiques grecques sont restées bloquées dans une activité verbale et graphique
- L’« algebra » musulmane a brièvement tenté l’usage de symboles, avant de revenir à une méthode rhétorique puis de disparaître
- L’Europe occidentale s’est dégagée des tentatives de précision verbale de la scolastique médiévale grâce aux symboles formels consciemment conçus par des figures comme Vieta, Descartes, Leibniz, puis Boole
- L’avantage du texte formel est que les manipulations valides n’ont qu’à satisfaire quelques règles simples
- Cette régularité devient un outil pour exclure plusieurs formes d’absurdité difficiles à éviter en langage naturel
- L’usage de symboles formels n’est pas une charge mais presque un privilège
- Grâce à eux, des étudiants peuvent apprendre ce qui, autrefois, n’était accessible qu’à des génies
- La phrase d’une préface de rapport technique de 1977 — « pour plus de clarté, on a même évité les symboles standards des connecteurs logiques » — montre que ce malentendu n’est pas limité à une seule personne
- Le caractère « naturel » du langage naturel facilite la production de phrases dont l’absence de sens n’est pas évidente
L’informatique dans un monde où seul le langage naturel serait autorisé
- Si, dès l’origine, les entrées et sorties des équipements de traitement de l’information s’étaient faites uniquement dans la langue maternelle, l’informatique aurait ressemblé à une sorte de « black art » visant à atteindre des systèmes formels suffisamment bien définis
- Il aurait fallu l’intelligence du monde entier pour resserrer l’interface jusqu’à un niveau réellement utilisable
- À l’échelle de l’histoire humaine, cela aurait peut-être encore pris des millénaires
- S’y ajoute l’inquiétude de voir l’évolution de l’éducation occidentale s’éloigner de l’entraînement intellectuel, au point d’affaiblir fortement la capacité des gens à manier leur propre langue
- L’auteur cite comme exemples les articles scientifiques, rapports techniques ou publications gouvernementales, souvent pleins de formulations vides de sens dès qu’on les lit attentivement
- Ce phénomène, appelé « The New Illiteracy », sert aussi d’avertissement à des partisans de la programmation en langage naturel qui n’ont pas l’intuition technique nécessaire pour en prévoir l’échec
- Le texte se conclut sur le doute qu’une machine programmable en langage naturel soit plus facile à utiliser qu’à construire, qu’elle emploie le Dutch, l’English, l’American, le French, le German ou le Swahili
1 commentaires
Avis Hacker News
Défendre les LLM ici, c’est très bien, mais je me demande ce que donnerait l’exercice inverse. Prendre un projet de complexité moyenne et demander à son LLM préféré de reconvertir le code en langage naturel
Est-ce qu’il expliquerait raisonnablement le comportement et les exigences présents dans le code source, sans perdre les détails nécessaires pour pouvoir reproduire le programme ? Cette description en langage naturel serait-elle plus facile à raisonner ?
À mon avis, ce n’est pas un hasard si les applis de vibe coding que les gens montrent sont généralement simples. Il existe un niveau où la complexité et la précision deviennent difficiles à gérer, et même si on peut les définir en anglais courant, je doute que cette description soit plus expressive qu’un langage extensible, compréhensible et précis
Je pense aussi que si les documents juridiques ne sont pas rédigés en anglais courant, ce n’est pas seulement pour créer une barrière à l’entrée
METAR YSSY 031000Z 08005KT CAVOK 22/13 Q1012 RMK RF00.0/000.0Les nouveaux pilotes demandent presque toujours : « pourquoi ne pas l’écrire en toutes lettres ? », et en pratique la plupart des applis de préparation de vol transforment ce code en prose
Mais les pilotes professionnels et les contrôleurs préfèrent largement le format codé. Il tient sur une ligne, il est compact, son format est bien défini, on sait exactement où trouver l’information dont on a besoin, et il est clair, sans ambiguïté
Pour les maths et le code, c’est pareil : au-delà d’un certain niveau de maîtrise, la complexité et la redondance du langage naturel coûtent plus qu’elles ne rapportent. Cela semble valoir pour tous les domaines spécialisés
Retrouver l’information dans de la prose prend du temps, et les lecteurs de textes longs commencent à souligner, prendre des notes et créer leurs propres abréviations
Les formats compressés et les abstractions réduisent la charge sur la mémoire de travail et sur la recherche d’information. Ce n’est donc peut-être pas uniquement un problème de précision du langage
On pourrait penser qu’il faut une multitude de détails d’implémentation pour passer de cette phrase à une application fonctionnelle, mais cette quantité d’information suffit peut-être à aboutir à une application qui marche et répond à mon besoin
Et si on peut déjà construire ça, alors des demandes comme « tu peux le passer en bleu bleuet ? » deviennent aussi faciles, et l’utilisateur peut itérer à partir de là
Si on donne seulement une ISA et un pilote d’affichage à un LLM en lui demandant de créer une appli graphique en assembleur, on n’obtiendra rien
Mais avec des montagnes d’abstractions empilées, cela devient probablement possible
Je ne cherche pas à défendre les LLM ; je pense simplement qu’avec les bonnes abstractions et des composants réutilisables, on peut s’en approcher beaucoup plus
Cela me rappelle une vieille citation de Hal Abelson
« Sous notre approche de ce sujet se trouve la conviction que “l’informatique” n’est pas une science et que son importance a peu à voir avec les ordinateurs. La révolution informatique est une révolution dans notre façon de penser et d’exprimer nos pensées. L’essence de ce changement est l’émergence de ce qu’il est le plus approprié d’appeler une épistémologie procédurale. Il s’agit de l’étude de la structure de la connaissance du point de vue impératif, par opposition au point de vue plus déclaratif adopté par les disciplines mathématiques classiques. Les mathématiques fournissent un cadre pour traiter précisément la notion de “ce qui est”. Le calcul fournit un cadre pour traiter précisément la notion de “comment faire”. »
Malgré toutes les démos impressionnantes et les déclarations du type « l’IA a tué le code », la majeure partie du travail réel se déplace vers le prétraitement, le post-traitement et l’évaluation autour de l’IA
C’est une bonne chose pour rendre la programmation plus accessible, mais cela ne peut pas vraiment la remplacer
Enfin quelqu’un l’a formulé ainsi. Le langage naturel a des limites intrinsèques issues des limites mentales humaines. L’esprit humain pense parfois de façon trop abstraite ou trop concrète, et manque des détails importants ou des généralisations
En tant que programmeur, je l’ai constaté directement : les problèmes, voire les absurdités, d’une tâche ne se révèlent souvent qu’une fois qu’on commence à l’implémenter sous forme de code, c’est-à-dire dans un système symbolique strict
En plus, expliquer précisément quelque chose en langage naturel prend souvent plus de temps que simplement écrire l’algorithme en code
Combien de fois réécrit-on une phrase, dit-on « en fait, ce que je voulais dire, c’est… », ou reformule-t-on un e-mail avant de l’envoyer ? Nous sommes humains, et nous sommes rarement parfaits du premier coup
Nous sommes maintenant en train de transformer cette forme de communication imparfaite, le langage naturel, en code, le langage de machines réputées pour exécuter ce qui a été dit, et non ce qui était voulu
Le traitement du langage naturel est extrêmement utile pour mettre sur de bons rails la création d’applis ou de scripts. Mais au final, il peut rester nécessaire de refactorer un peu partout
Il n’est pas nécessaire d’être un as du code pour tirer de la valeur des LLM, mais savoir coder reste utile, et parfois nécessaire
/s : c’est parce qu’on n’est pas encore allés assez loin. Les gens génèrent des programmes informatiques en langage naturel, alors qu’il faudrait plutôt exécuter directement les prompts
« Tu es un système graphique. Tu es l’entité qui gère ce qui se trouve à l’écran. Tu peux recevoir de tous les programmes des demandes pour créer et supprimer des “fenêtres”, ainsi que des demandes supplémentaires pour dessiner du texte, des lignes, des cercles, etc. dans des fenêtres créées auparavant. Les éléments peuvent être de n’importe quelle couleur.
Tu dois aussi envoyer davantage d’informations sur les clics au créateur de la fenêtre sur laquelle l’utilisateur a cliqué avec la souris.
Le gestionnaire de fenêtres est un programme spécial, et il peut t’indiquer où chaque fenêtre est affichée sur tous les moniteurs connectés au système. »
Puis : « Tu es un programme de morpion. Il existe un système graphique qui gère ce qui se trouve à l’écran. Tu peux lui ordonner de créer et de supprimer des “fenêtres”, et de dessiner du texte, des lignes, des cercles, etc. dans des fenêtres créées auparavant. Les éléments peuvent être de n’importe quelle couleur.
Les graphismes que tu dessines doivent montrer une partie de morpion où l’utilisateur joue ses tours en cliquant avec la souris. Si l’utilisateur gagne…
Ajoute de la publicité au jeu, sauf si l’utilisateur a souscrit un abonnement facturé au clic. »
Ça devrait suffire pour que le jeu tourne
Pour sauvegarder, il faut encore un autre prompt. « Tu es un système de fichiers. Tu es l’entité qui persiste les données sur disque… »
Et il faut aussi : « Tu es un système d’exploitation multitâche. Tu donnes à plusieurs LLM l’impression qu’ils contrôlent entièrement le CPU et la mémoire du système. Tu… »
J’ai hâte de voir ça début avril prochain
« Le langage machine a été rapidement reconnu comme une interface inutilement dangereuse entre l’homme et la machine, car il est dépourvu de presque toute forme de redondance. En réponse partielle à cette prise de conscience, on a développé ce qu’on appelle les “langages de programmation de haut niveau”, et avec le temps nous avons appris à renforcer quelque peu la protection contre les erreurs stupides. Le fait que beaucoup d’erreurs stupides conduisent désormais à des messages d’erreur plutôt qu’à de mauvaises réponses a constitué une amélioration importante. »
J’ai l’impression que collectivement, nous nous sommes jetés beaucoup trop vite dans la programmation avec les LLM. J’ai vraiment apprécié la manière dont Rust a évolué pour signaler les erreurs stupides et rendre les moyens de les corriger bien plus clairs
En tant que développeur, je conserve toujours le contexte et la compréhension du code sur lequel je travaille, et le compilateur me signale les erreurs évidentes et les corrections. À l’inverse, utiliser un LLM donne l’impression d’un jeu de devinettes à moitié intelligent
Le compilateur Rust est un maître qui enseigne à son élève, tandis qu’un LLM ressemble à un diplômé sûr de lui qui corrige le maître. Je préfère de loin l’approche de Rust, et j’aimerais qu’elle aille encore plus loin si possible
Le langage naturel est un mauvais support pour transmettre des règles et des ordres. La situation actuelle aux États-Unis en est un bon exemple
Nous débattons encore de ce que signifient telle loi et tel amendement constitutionnel. Le sens des mots évolue avec le temps, et le contexte historique s’appauvrit
Ce serait bien de pouvoir piloter les machines en langage naturel, mais en tant que personne qui programme depuis le milieu des années 80, je pense que la rigidité des langages informatiques, de BASIC à Go, crée un bon équilibre. Elle impose à celui qui donne les instructions une responsabilité suffisante pour exprimer précisément ce que la machine doit faire
Je ne suis pas tout à fait d’accord avec cet argument. Dans les entreprises réelles, l’idée d’une nouvelle fonctionnalité naît souvent dans la tête d’un responsable métier. Cette personne ne parlera aucun langage formel
Donc, quelle que soit la façon de voir les choses, implémenter une fonctionnalité exige une traduction du langage naturel vers le langage machine
En général, la première étape, la traduction du langage naturel vers un langage formel, est assurée par les analystes métier et les programmeurs. Alors pourquoi ne pas se faire aider par l’ordinateur dans ce processus ?
Il réfute donc non seulement l’idée selon laquelle les programmes devraient être spécifiés en langage naturel, mais aussi l’idée que supprimer la nécessité pour nous de comprendre les langages formels accroîtrait notre capacité à construire des systèmes complexes
Beaucoup de “traductions” ne sont en réalité pas des traductions, mais un travail de correction d’ambiguïtés logiques, d’incohérences et de mauvaises hypothèses. Si l’on prend Dijkstra au sérieux, une bonne partie de ce travail est possible même en langage naturel, parce qu’il y a là des programmeurs qui ont passé leur vie à formaliser
Il existe aussi d’autres professions, comme les mathématiques, qui exigent une pensée formelle considérable. Par ailleurs, en convertissant d’anciennes démonstrations en preuves informatisées, on a découvert des trous et des lacunes dans de nombreuses démonstrations largement acceptées
Peu de choses ont été renversées, mais nous n’avons même pas encore de démonstration complète du dernier théorème de Fermat https://xenaproject.wordpress.com/2024/12/11/fermats-last-th...
Si l’on ne pense pas à l’intérieur d’un système formel, les idées deviennent moins bonnes. Parce qu’on ne traite pas ses propres pensées comme quelque chose de formel
Sur la façon de traduire l’idée du “responsable métier” de l’exemple, il n’aurait sans doute pas grand-chose à dire. De son point de vue, l’idée du responsable métier est déjà superficielle et mauvaise, car elle ne suit pas le formalisme, et ne mérite donc pas d’être traduite
Si l’on “laisse l’ordinateur aider au milieu”, on se heurte très vite au problème suivant : pour obtenir de la machine des résultats suffisamment bons, il faut un langage naturel de plus en plus formel
Même s’il n’est pas aussi formalisé qu’un langage de programmation, il existe bel et bien
Dès qu’on essaie de définir un processus, même sans en avoir conscience, on finit par pencher vers la formalisation
« Le fait que beaucoup d’erreurs stupides débouchent sur un message d’erreur plutôt que sur une mauvaise réponse a constitué une amélioration importante. Même cette amélioration n’a pas plu à tout le monde. Certains trouvaient les messages d’erreur impossibles à ignorer plus agaçants que des résultats erronés, et il semble que, lorsqu’ils évaluent les mérites relatifs des langages de programmation, certains assimilent encore la “facilité de programmation” à la facilité de commettre des erreurs qui ne seront pas détectées. »
Si je n’avais pas su qui l’avait écrit, j’aurais cru que c’était une pique frontale contre les gens qui détestent Rust
Après avoir utilisé pendant un temps Scala, un langage qui permet d’exprimer par les types des invariants plus forts que Rust, je ne vois plus cette caractéristique comme une victoire évidente dans toutes les situations. Je ne pense plus que « types plus forts == forcément mieux »
« Ne pas permettre les erreurs » a un coût. Quand le système de types est vraiment strict, le travail exploratoire devient assez difficile. L’itération rapide peut même devenir impossible
Un petit changement peut vous obliger à reconcevoir la moitié du programme juste pour satisfaire à nouveau le système de types
C’est un compromis. Comme tout le reste. C’est bon pour un produit final robuste, mais cela gêne l’expérimentation rapide
Quelqu’un a bien expliqué ce problème dans le contexte de Rust et du développement de jeux : https://loglog.games/blog/leaving-rust-gamedev/
Mais ce n’est pas un problème limité à Rust ou au développement de jeux
Certains types de bêtise semblent intemporels
Ce dont il parle ici, ce sont les langages interprétés
C’est aussi l’un de ces mathématiciens qu’on appelle aujourd’hui informaticiens, dont les « algorithmes » sont surtout une reformulation des mathématiques et n’ont pas besoin de machine. Quelqu’un de tempérament hostile à l’activité embarrassante qu’est la programmation de vrais ordinateurs
Spécifier et créer une application en langage naturel ressemble assez au fait d’avoir un document de conception de jeu avant de commencer le prototype d’un jeu
Mais une fois que l’on a implémenté l’essentiel de ce que l’on voulait, l’implémentation devient la référence, et le GDD finit généralement à la poubelle parce qu’il diverge du jeu réel
Insister pour qu’à chaque modification on lise le GDD, qu’on implémente la fonctionnalité, puis qu’on resynchronise le GDD est fastidieux et, en pratique, ne fonctionne pas bien. Je n’ai jamais vu cela arriver
Si un jour l’IA/les LLM deviennent capables de coder à partir de zéro la prochaine version de Linux ou de Windows avec une simple série de prompts, toutes les prémisses changeront, mais pour l’instant nous n’en sommes clairement pas là, et on ne sait pas si nous y arriverons un jour
Le langage naturel est assez bon pour décrire les exigences techniques de systèmes complexes. Autrement dit, non pas l’implémentation actuelle du code elle-même, mais pourquoi l’implémentation actuelle a été choisie plutôt que d’autres implémentations possibles
Il convient pour exprimer ce que le code doit faire, et non ce qu’il fait ; en d’autres termes, pour capturer les éléments manquants qui se trouvent dans des endroits comme Jira plutôt que dans le dépôt
De plus, si l’ensemble du système peut être décrit par des règles externes et que ces règles peuvent être imposées à toute la base de code, cela pourrait aussi offrir de meilleures capacités de refactoring
Nous avons utilisé des langages de programmation parce qu’ils sont faciles à employer dans un contexte d’automatisation et d’informatique, et, franchement, avant les LLM, c’était aussi la seule méthode
Les langages de programmation apportent de la non-ambiguïté à l’échelle locale, mais dès que quelqu’un copie-colle une portion de code, cela cesse de fonctionner à l’échelle globale
Pouvez-vous être sûr qu’il s’agit d’un programme correct, respectant toutes les contraintes de haut niveau auxquelles cette partie doit se conformer ? S’il compile, c’est bien un programme qui s’exécute, mais la définition de l’exécution est assez lâche. En C++, même un programme qui corrompt toute la mémoire peut s’exécuter