Dijkstra: Natürlichsprachige Programmierung ist ein Irrweg

Ich schicke diesen Artikel jedem, der mir erzählt, Englisch sei jetzt eine High-Level-Programmiersprache, die nächste Abstraktionsebene in der Kette von der Maschinensprache zu <seiner Lieblingssprache>. Auf diese Analogie folgt meist: "So wie die meisten Programmierer nie Assemblercode anschauen, wird das Anschauen von höhersprachigem Quellcode bald etwas sein, das nur noch wenige Leute tun".

Dijkstras Argumente ändern meist nicht ihre Meinung. Ich glaube, die Analogie setzt sich durch, weil ein Körnchen Wahrheit darin steckt. KI-Modelle geben uns jetzt die magische Fähigkeit, in natürlicher Sprache zu programmieren, aber die Implikation, dass ein KI-Modell eine Art Compiler ist, ist zutiefst fehlerhaft. KI-Modelle ersetzen keine Compiler, sie ersetzen Softwareentwickler. Der Grund, warum Softwareentwickler selten Assemblercode anschauen, ist, dass Compiler (und Emulatoren und VMs) in der Lage sind, die Semantik des ursprünglichen Programms präzise zu bewahren.

Eine Spezifikation in natürlicher Sprache ist kein Programm, und es gibt viele mögliche Programme, die die Spezifikation erfüllen können. Softwareentwickler und KI-Modelle verwandeln Spezifikationen in Code, aber der Code ist nicht die Spezifikation. Ich glaube, die Analogie vernebelt unser Denken über den Wert von Programmiersprachen als Werkzeug, um formal zu beschreiben, was der Computer tun soll, und um Eigenschaften des Programms durchzusetzen, deren Einhaltung man weder Menschen noch KI-Modellen überlassen sollte.

Ich denke, der Unterschied liegt zwischen der Kommunikation mit einem rein mechanischen Wesen und der Kommunikation mit einer intelligenten Entität: Anders als Programme, die rein formale Sprachen sind, schreiben wir Lehrbücher und Papers in einer Mischung aus menschlicher Sprache und formaler Sprache. Oft führen wir "gerade formal genug" Notationen ein. Und der intelligente Leser liest dazwischen, inter legere bedeutet wörtlich genau das: dazwischen lesen. Die Lücken füllen, die Punkte verbinden.

Und in der Praxis finde ich es _sehr_ effektiv, Schlüsselideen mit etwas formaler Sprache auszudrücken, wo es passt. Ein bisschen EBNF hier, ein paar Schnipsel Python oder Prolog dort oder andere Sprachen da. Und ich finde LLMs wunderbar darin, die Punkte zu verbinden und, und das ist hier das Thema, unsere halbformale Unterhaltung in eine rigorose, formale Sprache zu übersetzen.

Und ich wage einen Schritt weiter: Ich finde LLMs auch nützlich beim Formulieren und Verfeinern technischer Vorschläge, für menschliches Peer-Review und LLM-getriebene Implementierung, und natürlich mischen diese Vorschläge Prosa in natürlicher Sprache mit halbformalen und formalen Details. Denk an PEP-12 und PEP-1-Stil. Und diese bekommen dann Arbeitspakete, die jeweils eine Spezifikation einbinden wie bei SDD.

Scheint bisher ganz gut zu funktionieren :-)

Ich habe dieselbe Ansicht, seit Coding-Agenten aufgetaucht sind. LLMs sind gut im Zusammenfassen, deshalb nutze ich sie tendenziell, um Code zu verstehen. Je besser ich jedoch eine Codebasis verstehe, desto wählerischer werde ich gegenüber dem Agenten. Je weniger ich über die Codebasis weiß, desto offener bin ich, ihn einfach machen zu lassen.

Mir ist klargeworden, dass der Agent keinen "guten" Code schreibt, sondern mein vages Verständnis dessen, was ich erwarte, mich glauben lässt, dass er es tut. Wenn ich mir den KI-Code anschaue, sehe ich, dass es mehr Nuancen und Entscheidungen gab, die vor dem Schreiben des Codes hätten getroffen werden müssen. Man könnte sagen, eine Spezifikation würde reichen, aber dann erinnere ich mich an TLA+, entwickelt von Leslie Lamport, um Entwicklern zu helfen, kritisch über ihre Programme/Algorithmen nachzudenken. Sich hinzusetzen und formal aufzuschreiben, was ich tun will, hilft mir, das Problem besser zu verstehen und eine echte – nicht vage definierte – Lösung zu finden.

Natürliche Sprache ist voller Nuancen und impliziter kultureller und domänenspezifischer Konnotationen. LLMs funktionieren, weil sie auf einem riesigen Korpus von Materialien trainiert wurden, der einige (aber nicht alle) dieser verborgenen Bedeutungen kodiert.

Bei spezifikationsgetriebener Entwicklung müssen die Prompts sehr detailliert sein, um genau das zu produzieren, was erforderlich ist.

Das heutige Natural-Language-Programm wird morgen nicht funktionieren, wegen der instabilen Natur natürlicher Sprache.

Abgesehen von der natürlichen Evolution von Bedeutungen, schau dir die Orwellschen Einschränkungen an, die manche (Cloud-)Modelle uns auferlegen, sodass unser Natural-Language-Programm illegal wird. Aufgrund von Thema oder Wortkombination muss das Programm geflaggt und bald wahrscheinlich an eine Drei-Buchstaben-Behörde gemeldet werden.

Als Nächstes würde RMS fragen: Kannst du deinen eigenen Natural-Language-Programm-Compiler von Grund auf selbst bauen?

Ich weiß, wir haben (sehr teure) lokale Modelle, aber warte, bis GPUs ein richtiges Online-Abo brauchen, um zu funktionieren, und Überwachungsabhörmaßnahmen.

Möglicherweise relevant:

Das Experiment, eine Sprache zu entwerfen, die natürlichen Sprachen (Englisch und Japanisch) ähnelte, war nicht erfolgreich. -[1]- William R. Cook, AppleScript, HOPL IV

Nun sind unsere neuen LLMs anders, weil sie nicht "Sprache, die natürlichen Sprachen ähnelte" verwenden, sondern tatsächliche natürliche Sprache. Aber die Lektion ist trotzdem lehrreich, weil sie uns einige empirische Belege liefert, mit denen wir Dijkstras theoretische Argumente vergleichen können.

Und die lautet, dass natürliche Sprache bestenfalls ein zweischneidiges Schwert ist. Ja, es gibt Vorteile, aber es gibt auch enorme Nachteile. Und ein Problem ist, dass die Vorteile vorgelagert sind und die Nachteile langfristige Probleme.

Für mich fehlt uns eine Sache: Was LLMs für uns tun, hat eigentlich 2 Teile.

1. Es erlaubt uns, natürliche Sprache zu verwenden, was uns erlaubt, uns vage auszudrücken.

2. Es erlaubt uns, auf einem viel, viel höheren Niveau als üblich zu spezifizieren, was wir wollen.

Mit unseren LLMs sind diese beiden untrennbar verbunden. Ich glaube, das Ganze wäre viel, viel wertvoller, wenn wir sie trennen könnten.

[1] https://dl.acm.org/doi/10.1145/1238844.1238845

> Ich vermute, dass Maschinen, die in unseren Muttersprachen programmiert werden sollen – sei es Niederländisch, Englisch, Amerikanisch, Französisch, Deutsch oder Swahili –, genauso verdammt schwierig herzustellen wären, wie sie zu benutzen wären.

Er hat immer noch ziemlich recht. Ich betrachte eine Maschine im Allgemeinen als "programmiert in" dem, was in der Versionskontrolle verfolgt wird. Solange also dein Git-Repo Änderungen in Java verfolgt, ist es immer noch in Java programmiert, selbst wenn das Java mit Hilfe von LLMs generiert wurde. Ich würde die These dieses Artikels erst als widerlegt betrachten, wenn die Mehrheit der Repos anfängt, natürliche Sprache statt Programmiersprachen als primäre Artefakte zu verfolgen, die das Verhalten der Software definieren.