「自然言語プログラミング」はなぜ愚策なのか、1978年にDijkstraが喝破していた
The foolishness of "natural language programming" (1978)
Edsger W. Dijkstraが1978年に著したエッセイ「自然言語プログラミングの愚かさについて」。プログラミングに形式記号の厳密さを求めるのは欠点ではなく特権だと主張する。母語による命令は機械の負担を増やすだけで人間の負担も軽くしないと論じ、数学史における記号の勝利を引き合いに出す。
母語を使うときの「自然さ」とは、結局のところ、ナンセンスであることが明らかでない主張をいとも簡単に作れてしまうことの裏返しにすぎない。
HNでの議論
159- benrutter
このエッセイはかなり色褪せず、今でも的を射ていると思う。
エージェント開発は「自然言語プログラミング」だと言う人もいるが、それは違うと思う。その場合、プログラミングをしているのはエージェントであり、プログラミングは常にRustやPython、TypeScriptなどの決定論的な言語で行われる。それは変わるかもしれないが、少なくとも私には逆のやり方は大惨事になるように思える。
ただ、私が知る最良の例外は間違いなく、テキストアドベンチャーを書くためのInform 7言語だ[0]。多くのファンがいて、私は深く掘り下げたことはないが、自然言語とプログラミングを独特な方法でエレガントに結びつけているようだ。
いずれにせよ、自然言語プログラミングに興味のある言語オタクには必見だ。
- nickm12
英語が今や高水準プログラミング言語であり、機械語から<お気に入りの言語>への抽象化の次の段階だと言う人全員にこの記事を送っている。この類推はたいてい「ほとんどのプログラマーがアセンブリコードを見ないのと同じように、高水準のソースコードを見るのは一部の人だけになるだろう」と続く。
ダイクストラの議論は彼らの考えを変えることはあまりない。この類推が定着するのは、そこに一片の真実があるからだと思う。AIモデルは今や自然言語でプログラミングする魔法の能力を与えてくれるが、AIモデルがコンパイラの一種であるという含意は深く欠陥がある。AIモデルはコンパイラを置き換えるのではなく、ソフトウェア開発者を置き換える。ソフトウェア開発者がアセンブリコードをほとんど見ないのは、コンパイラ（やエミュレータ、VM）が元のプログラムのセマンティクスを正確に保持できるからだ。
自然言語の仕様はプログラムではなく、その仕様を満たすプログラムは多数あり得る。ソフトウェアエンジニアやAIモデルは仕様をコードに変えるが、そのコードは仕様ではない。この類推は、コンピュータが何をすべきかを形式的に記述し、人間にもAIモデルにも任せるべきでないプログラムの特性を強制するツールとしてのプログラミング言語の価値について、私たちの思考を曇らせていると思う。
- froh
違いは、純粋に機械的な存在とコミュニケーションするか、知的な存在とコミュニケーションするかだと思う。プログラムは純粋に形式言語だが、私たちは教科書や論文を人間言語と形式言語の混合で書く。しばしば「ちょうど十分に形式的な」記法を導入する。そして知的な読者は行間を読む。inter legereは文字通り「間を読む」という意味だ。隙間を埋め、点と点を結ぶ。
実際、適用可能なところでは形式言語で重要なアイデアを表現するのは非常に効果的だと思う。ここに少しEBNF、そこにPythonやPrologや他の言語のスニペット。そしてLLMは点を埋めるのに素晴らしいし、ここでの話題だが、私たちの半形式的な会話を厳密で形式的な言語に翻訳するのにも素晴らしいと思う。
さらに一歩踏み込むと、LLMは技術提案の定式化と洗練にも役立つと思う。人間のピアレビューとLLM駆動の実装のためだ。もちろんこれらの提案は自然言語の散文と半形式・形式の詳細を混ぜている。PEP-12やPEP-1スタイルのように。そしてこれらはSDDのように各々が仕様をループするワークパッケージになる。
今のところうまくいっているようだ :-)
- uriegas
コーディングエージェントが登場して以来、同じ見解を持っている。LLMは要約が得意なので、コードを理解するために使う傾向がある。しかし、コードベースを理解すればするほど、エージェントに対してより細かく注文を付けるようになる。逆にコードベースをあまり知らないほど、エージェントに任せることに寛容になる。
エージェントは「良い」コードを書かないことに気づいた。むしろ、私の期待するものについての漠然とした理解が、そう思わせているのだ。AIのコードを見ると、コードを書く前に取る必要があったより多くのニュアンスや決定があることがわかる。仕様があれば十分だと言う人もいるだろうが、Leslie Lamportが開発者にプログラムやアルゴリズムについて批判的に考えるのを助けるために作ったTLA+を思い出す。腰を据えて自分のやりたいことを形式的に書くことは、問題をよりよく理解し、漠然と定義されたものではない本当の解決策を思いつくのに役立つ。
- GianFabien
自然言語はニュアンスや暗黙の文化的・ドメイン固有の含意に満ちている。LLMが機能するのは、それらの隠れた意味の一部（すべてではない）をエンコードした大規模なコーパスで訓練されているからだ。
仕様駆動開発では、プロンプトは要求されるものを正確に生成するために非常に詳細である必要がある。
- imhoguy
今日の自然言語プログラムは、自然言語の不安定な性質のため明日には動かなくなる。
意味の自然な進化は別として、（クラウド）モデルが課すオーウェル的な制限を見てほしい。私たちの自然言語プログラムが違法になるのだ。トピックや単語の組み合わせによって、プログラムはフラグを立てられ、まもなく三文字機関に報告される可能性が高い。
次に、RMSならこう尋ねるだろう。自然言語プログラムコンパイラをゼロから作れるか？
（非常に高価な）ローカルモデルがあることは知っているが、GPUが適切なオンラインサブスクリプションと監視の盗聴を受けるようになるまで待ってほしい。
- mpweiher
おそらく関連する：
自然言語（英語と日本語）に似た言語を設計する実験は成功しなかった。 -[1]- William R. Cook, AppleScript, HOPL IV
今の新しいLLMは違う。なぜなら「自然言語に似た言語」ではなく、実際の自然言語を使うからだ。しかし、この教訓は依然として示唆に富む。ダイクストラの理論的議論と比較できる経験的証拠を与えてくれるからだ。
そしてそれは、自然言語がせいぜい諸刃の剣であるということだ。はい、利点はあるが、大きな欠点もある。そして一つの問題は、利点が前倒しで現れ、欠点が長期的な問題になることだ。
私にとって欠けていることの一つは、LLMが私たちのために行うことには実際に2つの部分があるということだ。
1. 自然言語を使えるようにし、曖昧であることを許す。
2. 通常よりはるかに高いレベルで欲しいものを指定できるようにする。
私たちのLLMでは、この2つは本質的に結びついている。この全体がはるかに価値があるものになるのは、これらを分離できた場合だと思う。
- riknos314
> 私たちの母語——オランダ語、英語、アメリカ語、フランス語、ドイツ語、スワヒリ語であれ——でプログラムされるべき機械は、作るのも使うのも同じくらい困難だろうと私は疑っている。
彼はまだかなり正しい。私は一般に、機械はソース管理で追跡されているもので「プログラムされている」と見なす。だからあなたのgitリポジトリがJavaの変更を追跡している限り、たとえそのJavaがLLMの助けを借りて生成されたとしても、それはまだJavaでプログラムされている。この記事の主張が無効になるのは、大多数のリポジトリがソフトウェアの動作を定義する主要な成果物としてプログラミング言語ではなく自然言語を追跡し始めたときだけだろう。