La fausseté de la programmation en langage naturel : relire Dijkstra en 2024
Sommaire
En bref
- Dijkstra (1978) arguait que programmer en anglais plutôt qu'en formalisme serait une catastrophe : les langages formels capturent la précision là où le langage naturel tolère l'ambiguïté et le non-sens.
- Le débat HN transpire la même tension 46 ans plus tard : les LLM permettent d'exprimer des vagues intentions et obtenir du code qui marche, mais cela ne valide pas la thèse. Le code généré reste stocké dans un langage formel (Python, Rust), pas en anglais brut.
- La vraie question n'est pas si le langage naturel remplace la programmation, mais si le flou toléré par l'IA compense la rigueur perdue.
Ce que dit la source
Dijkstra expose qu'on a longtemps rêvé de machines acceptant des instructions en langue naturelle (anglais, français, etc.) pour épargner au programmeur la discipline du formalisme. L'argument séduisant : la machine s'alourdit, mais l'humain s'allège. Dijkstra le conteste radicalement. Il soutient que l'histoire des mathématiques prouve l'inverse : la Grèce antique s'est enlisée dans le verbalisme, la formalisation par Viète, Descartes, Leibniz et Boole a sauvé la pensée moderne. Le formalisme n'est pas une chaîne : c'est un privilège. Les enfants d'école utilisent la notation formelle pour accomplir ce qui demandait du génie autrefois. En retour, le débat HN ramène cet article de 1978 au front : les LLM font-ils mentir Dijkstra ?
- Dijkstra : le langage naturel cache aisément du non-sens que le formalisme expulse ; changer d'interface (passer du code au texte naturel) ne diminue pas le travail total, l'augmente souvent.
- Histoire des maths : le grec classique, le verbalisme, l'algèbre rhétorique ont tous stagné jusqu'à l'émergence de notations formelles rigoureuses.
- Les LLM ne remplacent pas les compilateurs, ils remplacent les programmeurs : le code reste stocké en Rust, Python, TypeScript, pas en anglais brut. Un compilateur préserve la sémantique, un LLM engendre un ensemble de programmes possibles pour une spécification.
- Plusieurs commentateurs rapportent que les prompts vagues produisent du code qui « paraît bon » à première lecture, mais manquent de rigueur pour passer dix exécutions identiques avec résultats identiques.
- Inform 7 (langage pour jeux textuels) est cité comme exception notoire : il marie langage naturel et programmation de façon cohérente, mais dans un domaine très spécialisé.
- Spécification formelle (TLA+, EBNF, semi-formelle) améliore la clarté, même mixée avec prose naturelle, et les LLM aident à formaliser ensuite.
Dans les commentaires
Débat partagé mais lucide : personne ne croit à la « programmation en anglais » au sens de Dijkstra (1978), mais beaucoup trouvent les LLM utiles pour la vitesse d'itération et l'abstraction. Le clivage réel oppose ceux qui voient l'artefact de vérité dans le code formel (rigoreux pour la production) et ceux qui acceptent le flou si ça marche assez vite en pratique.
- Plusieurs commentateurs distinguent nettement l'usage utile des LLM (complétion, compréhension, écriture plus vite) de la thèse fausse que le langage naturel remplace la programmation formelle. L'un souligne que tant que git traçabilite du code en Python ou Rust, pas en anglais, Dijkstra reste valide.
- Un partie du fil conteste l'analogie « LLM = niveau d'abstraction plus haut » (comme assembly → C → Python) : c'est une confusion catégorique. Un compilateur préserve la sémantique point-par-point, un LLM navigue un espace de solutions compatibles avec une spec floue.
- Objection pratique : clients et non-experts confrontés à une textarea de spécification naturelle restent paralysés, même avec 30 ans d'expérience ; la « facilité » du langage naturel suppose déjà une compétence masquée : bien écrire une spécification.
- Un thread évoque la précarité de la « programmation » en LLM : les modèles changent, les policies de contenu censurent certains prompts, pas de versioning sain du comportement. Un spec en formule n'a pas ce problème.
- Critique de forme : AppleScript (années 80) a tenté le langage ressemblant au naturel, c'était un deux-tranchants doublé d'une catastrophe de collaboration. Les LLM utilisent du vrai naturel, mais Dijkstra rappelle la leçon : la clarté apparent du naturel vient du manque de rigueur.
Notre lecture
Dijkstra n'a rien perdu de sa pertinence. La vraie contribution des LLM n'est pas de remplacer la programmation formelle, c'est de faire oublier aux gens qu'elle est nécessaire. Un LLM produit du code qui marche assez souvent pour sembler magique, mais tolère les ambiguïtés qu'un compilateur refuserait. Cela accélère le prototypage tant que la complexité reste basse et l'acceptabilité du flou haute. Mais on ne peut pas « scaler » du flou : au-delà d'un certain seuil de couplage, de dépendances ou de correctness critique, on retombe sur les DSL, la TLA+, la spécification rigoureuse. Les LLM sont un excellent outil de productivité, un excellent résumeur, un piètre substitut à la pensée formelle. Ne pas confondre ces trois statuts.