- プログラミングの難しさを 形式記号 のせいにする見方は、機械が自然言語を理解すれば人間の負担が減るという誤った期待を生む
- 初期の機械語の危険性は 高級プログラミング言語 によって一部緩和されたが、誤った答えがエラーメッセージに置き換わっただけで、精密な指示が必要だという本質は残っている
- 自然言語インターフェースは労働を分け合う解決策ではなく、人間と機械のあいだの 協力・コミュニケーションコスト を増やし、双方の負担を重くしうる
- 数学の発展は、Vieta、Descartes、Leibniz、Boole のような人物が作った 形式記号体系 が複雑な思考を扱うための中核的な道具だったことを示している
- 自然言語プログラミングを基本の入出力にしていたなら、コンピュータ科学は結局、実用可能な 形式体系 へ戻るための長い回り道になっていた可能性が高い
自然言語プログラミングへの期待と錯覚
- 自動計算の初期から、一部の人々は、プログラミングが 形式記号 に求められる注意と正確さを必要とする点を欠点だと考えていた
- 機械が誤った命令さえ厳密に実行することを問題視し、些細な事務的ミスを拒否する、より「分別ある」機械を期待した
- 機械語は冗長性がほとんどなく、人間と機械のあいだの 危険なインターフェース だった
- これに対応して高級プログラミング言語が開発された
- 時間がたつにつれ、多くの些細なミスが誤った答えではなくエラーメッセージにつながるよう改善された
- しかし、プログラミング言語に対応する抽象機械は、なお与えられた命令を忠実に実行する自動機械であり、無意味な命令すら実行できる
- 自然言語で機械に指示しようという提案は、機械をより複雑にしても人間の負担を減らせるという論理に依拠している
- この論理がもっともらしく見えるのは、「形式記号を使う義務」を難しさの原因とみなす場合に限られる
- インターフェースの変更は、労働を単純に分配することではなく、インターフェースをまたぐ 協力とコミュニケーションのコスト を追加する
- 経験的には、インターフェースの変更は双方の作業量を大きく増やしうるため、「狭いインターフェース」への選好が強まる
形式記号が思考を拡張する仕組み
- 数学の歴史では、自然言語的・図形中心のやり方は繰り返し限界を露呈してきた
- ギリシャ数学は言語的・図形的活動にとどまり、停滞した
- イスラム世界の「algebra」は象徴の使用を一時試みた後、修辞的な方式へ戻って消えていった
- 西ヨーロッパは、Vieta、Descartes、Leibniz、そして後の Boole のような人物による 意識的に設計された形式記号 のおかげで、中世スコラ学の言語的精密さの試みから抜け出した
- 形式的テキストの利点は、正当な操作がいくつかの単純な規則を満たすだけでよい点にある
- この規則性は、自然言語では避けがたいさまざまな種類の無意味さを排除する道具となる
- 形式記号の使用は負担ではなく、特権 に近い
- 形式記号のおかげで、以前は天才にしかできなかったことを学生でも学べる
- 1977年のある技術報告書の序文にある「明確さのために論理結合子の標準記号すら避けた」という文は、こうした誤解が一人に限られたものではないことを示している
- 自然言語の「自然さ」は、無意味さが明白でない文を容易に作れてしまうことにつながる
自然言語しか許されない世界のコンピュータ科学
- もし最初から情報処理装置の入出力が 母国語 のみで行われていたなら、コンピュータ科学は、十分に定義された形式体系へ移行するための「black art」に近いものになっていただろう
- 実用的な水準までインターフェースを絞り込むには、世界中の知性が必要だったはずだ
- 人類の歴史を考えれば、再び数千年を要した可能性すらある
- 西洋の教育の流れが知的訓練から遠ざかるなかで、人々の自国語を扱う能力が大きく低下したという懸念も添えられている
- 科学論文、技術報告書、政府刊行物などですら、注意深く読むと意味のない言葉が多いことを例に挙げる
- この現象は「The New Illiteracy」と呼ばれ、自然言語プログラミングの失敗を予測する技術的洞察を持たない支持者たちへの警告にもなる
- 自然言語でプログラミングされる機械は、Dutch、English、American、French、German、Swahili のどの言語を使うとしても、作るのと同じくらい使うのも難しいだろうという疑いで締めくくられる
1件のコメント
Hacker News の意見
ここで LLM を擁護するのはいいとして、逆をやってみたらどうだろう。中程度の複雑さのプロジェクトを持ってきて、好きな LLM でコードを自然言語に戻してみる、ということだ。
ソースコードに含まれる動作と要件を、プログラムを再現できるだけの詳細を失わずに、合理的に説明してくれるだろうか。その自然言語の説明のほうが推論しやすいだろうか。
人々が見せるバイブコーディングアプリがたいてい単純なのには理由があると思う。複雑性と精密さを管理するのが難しくなる水準があり、平易な英語で定義できるとしても、その説明が拡張可能で理解可能かつ精密な言語より説明的なのかは疑問だ。
法律文書が平易な英語ではない理由も、単に参入障壁を作る以上のものだと思う。
METAR YSSY 031000Z 08005KT CAVOK 22/13 Q1012 RMK RF00.0/000.0のような形だ。新人パイロットはほぼ例外なく「なぜ言葉で書かないのか？」と尋ねるし、実際ほとんどの飛行計画アプリはこのコードを散文に変換してくれる。
しかしプロのパイロットや管制官は、コード形式をはるかに好む。1行なので圧縮的で、形式がよく定義されているため必要な項目をどこで探せばいいか正確に分かり、曖昧さがなく明確だからだ。
数学やコーディングも同じで、ある程度以上の熟練度に達すると、自然言語の複雑さと冗長さは利益よりコストが大きくなる。あらゆる専門分野に当てはまるように見える。
散文から情報を再び取り出すには時間がかかり、長い文章を読む人は下線を引いたりメモを取ったりして、自分なりの略記を作り始める。
圧縮された形式と抽象化は、作業記憶と情報探索の負担を減らしてくれる。だから必ずしも言語の精密さだけの問題ではないかもしれない。
その文から実際に動くアプリまで行くには多数の実装詳細が必要だと思うかもしれないが、その程度の情報だけでも、自分の必要を満たす動くアプリケーションに到達できる可能性はある。
そしてそれで十分に作れるなら、「それをコーンフラワーブルーに変えてくれる？」のような依頼も簡単になり、ユーザーはそこから反復改善できる。
ISA とディスプレイドライバだけを与えて、LLM にアセンブリでグラフィックアプリを作らせようとしても、何も得られないだろう。
しかし抽象化が山ほど積み上がっていれば、おそらく可能になる。
LLM を擁護したいわけではなく、正しい抽象化と再利用可能な構成要素を提供すれば、ずっと近づけると見ているのだ。
Hal Abelson の古い引用を思い出す。
「このテーマに対する私たちのアプローチの下には、『コンピュータサイエンス』は科学ではなく、その重要性はコンピュータとはほとんど関係がない、という確信がある。コンピュータ革命とは、私たちの考え方と考えを表現する方法の革命である。この変化の本質は、手続き的認識論と呼ぶのが最も適切な何かの出現である。それは、古典的な数学分野が取るより宣言的な観点とは異なり、命令的な観点から知識の構造を研究するものだ。数学は『何であるか』という概念を精密に扱う枠組みを提供する。計算は『どう行うか』という概念を精密に扱う枠組みを提供する。」
いくら見事なデモや「AI によってコーディングは死んだ」という宣言があっても、実際の作業の大半は AI を取り巻く前処理・後処理・評価へと移る。
プログラミングへのアクセス性を高めるという点では良いが、プログラミングを本当に置き換えることはできない。
ついに誰かがこう表現してくれた。自然言語には、人間の精神的限界に由来する内在的な限界がある。人の心は時に抽象的すぎたり具体的すぎたりして考え、重要な詳細や一般化を見落とす。
プログラマーとして直接感じるのは、ある課題の問題点や、ときには不条理さでさえ、コードをコードとして、つまり厳格な記号体系として実装し始めて初めて明らかになることが多いということだ。
そのうえ、何かを自然言語で正確に説明するのにかかる時間が、単にアルゴリズムをコードで書く時間より長くなることも多い。
文を書き直したり、「実は言いたかったのは…」と言ったり、送信前にメールを言い換えたりすることがどれほど頻繁にあるだろうか。私たちは人間であり、最初の試みで完璧なことはめったにない。
いま私たちは、この不完全なコミュニケーション形式である自然言語を、意図した通りではなく言われた通りに実行することで悪名高い機械の言語、つまりコードへ変換している。
自然言語処理は、アプリやスクリプト作成を正しい方向に始めさせるうえで非常に有用だ。だが最終的には、あちこちでリファクタリングが必要になるかもしれない。
LLM から価値を得るのにコードの達人である必要はないが、それでもコーディング能力は依然として役に立つし、時には必要になる。
/s: まだ十分に先へ進んでいないからだ。人々は自然言語でコンピュータプログラムを生成しているが、代わりにプロンプトを直接実行すべきだ
「あなたはグラフィックシステムです。画面に何があるかを管理する存在です。すべてのプログラムから『ウィンドウ』を作成・削除する要求を受け取ることができ、以前に作成したウィンドウにテキスト、線、円などを描画せよという追加要求も受け取れます。項目はどんな色でも構いません。
また、ユーザーがマウスをクリックしたウィンドウを作成した側に、より多くのクリック情報を送らなければなりません。
ウィンドウマネージャーは特別なプログラムであり、システムに接続されたすべてのモニター上で、どのウィンドウがどこに表示されているかをあなたに知らせることができます」
そして「あなたは三目並べプログラムです。画面に何があるかを管理するグラフィックシステムがあります。あなたはそのシステムに『ウィンドウ』を作成・削除するよう命令でき、以前に作成したウィンドウにテキスト、線、円などを描画するよう指示できます。項目はどんな色でも構いません。
あなたが描くグラフィックは、ユーザーがマウスをクリックしながら手番を進める三目並べゲームを表示しなければなりません。ユーザーが勝ったら…
ユーザーがクリック課金のサブスクリプションに加入していない限り、ゲームに広告を追加しなさい」
これくらいでゲームを動かすには十分だろう
保存するにはまた別のプロンプトが必要だ。「あなたはファイルシステムです。ディスクにデータを永続化する存在です…」
そして「あなたはマルチタスクOSです。複数のLLMに、システムのCPUとメモリを完全に制御しているという感覚を与えます。あなたは…」も必要だ
来年の4月初めにこれを見るのを楽しみにしている
「機械語はほとんどあらゆる形の冗長性を欠いていたため、人間と機械の間の不必要に危険なインターフェースだとすぐに認識された。この認識への部分的な対応として、いわゆる『高水準プログラミング言語』が開発され、時が経つにつれて私たちは愚かなミスに対する保護をある程度強化する方法を学んだ。今では多くの愚かなミスが、誤った答えではなくエラーメッセージにつながるというのは重要な改善だった。」
私たちは集団として、LLMプログラミングにあまりにも早く飛びつきすぎた気がする。Rustが愚かなミスを指摘し、修正方法をはるかに明確にする方向で発展してきた点は本当に良かった
開発者として、作業中のコードの文脈と理解は依然として自分の側にあり、コンパイラが明白なエラーと修正方法を教えてくれる。一方でLLMの利用は、半分知的な当て推量ゲームのように感じる
Rustコンパイラは弟子を教える師匠で、LLMは師匠を添削する自信満々の卒業生のようなものだ。Rustのアプローチの方がはるかに好みで、可能ならさらに発展してほしい
自然言語は規則や命令を伝える媒体としては貧弱だ。現在の米国の状況がよい例だ
私たちはいまだに、どの法律や憲法修正条項が何を意味するのかを議論している。単語の意味は時とともに変わり、歴史的文脈も不足していく
機械を自然言語で操作できればよいとは思うが、80年代半ばからプログラミングしてきた立場からすると、BASICからGoへと続くコンピュータ言語の頑固さがよいバランスを作っていると思う。命令を出す側に、機械が何をすべきかを正確に表現するだけの責任を負わせるからだ
この主張にはある程度同意しない。現実の企業では、新機能のアイデアは何らかの事業担当者の頭の中から始まることが多い。この人はどんな形式言語も話さないだろう
したがって、どう見ても機能を実装するには自然言語から機械語への翻訳が必要だ
通常、最初の段階である自然言語から形式言語への翻訳はビジネスアナリストとプログラマーが担う。ならば、その過程でコンピュータの助けを借りない理由があるだろうか？
だから彼は、プログラムを自然言語で仕様化すべきだという考えだけでなく、形式言語を理解する必要を取り除けば複雑なシステムを作る能力が高まる、という考えにも反論している
多くの「翻訳」は実際には翻訳ではなく、論理的な曖昧さ、不整合、誤った仮定を直す作業だ。Dijkstraを真剣に受け止めるなら、そのかなりの部分は自然言語の中でも可能だ。なぜなら、その場には生涯にわたって形式化を行ってきたプログラマーたちがいるからだ
数学のように、かなりの形式的思考を必要とする他の職業もある。また、古い証明をコンピュータ証明に変換する中で、広く受け入れられてきた多くの証明に穴や隙間が見つかることもあった
ひっくり返されたものは多くないが、私たちはまだフェルマーの最終定理について完全な証明も持っていない https://xenaproject.wordpress.com/2024/12/11/fermats-last-th...
形式体系の中で考えなければ、アイデアはより悪くなる。自分の考えを形式的なものとして扱わないからだ
例に出ている「事業担当者」のアイデアをどう翻訳するかについて、彼は特に意見を持たないだろう。彼の観点では、事業担当者のアイデアはすでに形式主義に従っておらず、浅くて悪いものであり、翻訳する価値がないからだ
「コンピュータに途中で助けさせる」と、機械から十分に良い結果を得るために、ますます形式的な自然言語が必要になるという問題にすぐ突き当たる
プログラミング言語ほど形式化されていなくても、確かに存在する
どんなプロセスであれ定義しようとすれば、自分では意識していなくても結局は形式化の方向へ傾くことになる
「多くの愚かなミスが、間違った答えではなくエラーメッセージにつながるようになったのは重要な改善だった。この改善でさえ、誰もが好んだわけではなかった。無視できないエラーメッセージを誤った結果よりも煩わしいと感じる人もいたし、プログラミング言語の相対的な利点を判断する際、いまだに『プログラミングの容易さ』を、見つからないミスを簡単に犯せることと同一視しているように見える。」
誰が書いたのか知らなければ、Rust嫌いの人たちを真正面から刺す言葉のように見えただろう
Rustよりも型でより強い不変条件を表現できる言語であるScalaをしばらく使ってみてからは、その特性がどんな状況でも明確な勝利だとは見なくなった。もはや「より強い型 == 無条件により良い」とは思わない
「ミスを許さない」ことには代償がある。型システムが本当に厳格だと、探索的な作業がかなり難しくなる。高速な反復が不可能になることもある
小さな変更のために、型システムを再び満たすべくプログラムの半分を再設計しなければならないこともある
これはトレードオフだ。他のすべてと同じ。堅牢な最終製品には良いが、素早い実験の妨げになる
この問題をRustとゲーム開発の文脈でうまく説明した人がいる: https://loglog.games/blog/leaving-rust-gamedev/
ただし、Rustやゲーム開発だけに限られた問題ではない
ある種の愚かさは時代を超えるようだ
ここで彼が言っているのはインタプリタ言語のことだ
彼はまた、今ではコンピューター科学者と呼ばれる数学者の一人で、彼の「アルゴリズム」は数学を単に言い換えたものに近く、デバイスを必要としない。実際のコンピューターをプログラムするという気まずい活動に、気質的に敵対的な人だ
自然言語でアプリケーションを仕様化して作ることは、ゲームのプロトタイプを始める前にゲームデザイン文書を持つことにかなり似ている
しかし、望むものの大半を実装し終えると実装物が基準になり、GDDは実際のゲームとずれていくため、たいてい捨てることになる
変更するたびにGDDを読んで機能を実装し、その後GDDを再び同期しなければならないと主張するのは面倒で、実際にはうまく機能しない。そういうことが起きるのを見たことがない
いつかAI/LLMが一連のプロンプトだけでLinuxやWindowsの次期バージョンをゼロからコーディングできるようになれば、すべての前提は変わるだろうが、今は明らかにそこまで到達していないし、今後そうなるかも分からない
自然言語は複雑なシステムの技術要件を説明するのにはかなり向いている。つまり、現在のコード実装そのものではなく、なぜ他の可能な実装ではなく現在の実装を選んだのかを説明するのに向いている
コードが何をしているかではなく何をすべきか、言い換えればリポジトリではなくJiraのような場所にある欠けた部分を含めるのに適している
また、システム全体が外部ルールで説明され、そのルールをコードベース全体に強制できるなら、より良いリファクタリング能力を提供できるかもしれない
私たちは自動化・コンピューターの文脈で書きやすいのでプログラミング言語を使ってきたし、正直LLM以前にはそれが唯一の方法でもあった
プログラミング言語は局所的な規模では曖昧さのなさを与えてくれるが、誰かがコードの一部をコピー＆ペーストした瞬間、全体的な規模では機能しなくなる
その部分が従うべきすべての上位レベルの制約を守った正しいプログラムだと確信できるだろうか？ コンパイルできれば実行されるプログラムではあるだろうが、実行の定義はかなり緩い。C++ではメモリをすべて壊すプログラムでも実行可能だ