理解可能なソフトウェアへ向けて
(gracefulliberty.com)- プログラミングは読む・テストする・保守するのが難しく、プロジェクト理解が少数に集中しがちなため、LLMでコード作成を自動化するよりも、そもそもコードが必要な範囲自体を減らす抽象化が必要である
- LLMは開発者にも非開発者にも広がったが、環境破壊的であること、盗用コードベースであること、一貫性のない結果、依存を生むことといった問題は依然として大きい
- 出発点は、先にコードを書いて文書を後から付け足す慣行を逆転させ、文書先行で書き、その後にコードが続く文芸的プログラミングへ移ることにある
- GUIベースの視覚的プログラミングと決定論的な自然言語プログラミングは、コードを複数ある表現の一つにできるが、視覚環境にはスクリーンリーダー統合のようなアクセシビリティ設計が必須である
- EveやInformのような先行事例、Entangled・ReTangledのようなツールは、初心者と専門家の双方にとって理解可能な方法でソフトウェアを作れる可能性を示している
LLMは目標モデルではない
- LLMは産業ソフトウェア開発における重要なツールとなっており、経験豊富な専門家もテスト、デバッグ、コード作成にLLMエージェントを使っている
- 非開発者もLLMで個人用スクリプトから科学データ処理ツールまで作っている
- プログラミングは出発点が不明確で、特定言語の文法やライブラリの詳細を学びたくない人にとってはアクセスしにくい
- LLMの普及は、LLMがプログラミングを非常にうまくこなすからというより、プログラミング自体が複雑で不快な作業であることのシグナルに近い
- 衝突するソフトウェアスタック、終わりのないボイラープレート、扱いづらいライブラリが多い
- 平均的なソフトウェア開発者の仕事は、興味深いコードを開発することよりライブラリをつなぎ合わせる作業へと縮小している
- LLMには依然として大きな問題が残っている
- 環境破壊的である
- 盗用コードに根本的に依存している
- 一貫性のないコードを生成する
- 依存を植え付ける
- 現在のプログラミングパラダイムにも不足はあるが、LLMについてもより良い代替が必要である
自動化ではなく抽象化する
- LLMを捨てるとしても、自動化、高水準の抽象化、人間に優しいインターフェースまで捨てる必要はない
- 目標はコード作成を楽にすることにとどまらず、コードの下にあるソフトウェアスタックを扱い、コードを書く必要そのものを減らすことである
- ある抽象化レイヤーを何度も自動化したくなるなら、そのレイヤーを自動化するより、抽象化して消す方向のほうが適切である
- LLMがプログラミングで広く使われている現象は、コード作成プロセスを自動化したい欲求を示しており、これはコード作成の必要自体を抽象化すべきだというシグナルでもある
- 人間にコンピュータのように考えさせるのではなく、人間が自然に考える方法に近い新しい抽象化レイヤーが必要である
文書が先にあるプログラミング
- 理解可能なソフトウェアへの第一歩は文書化である
- 他人にソフトウェアを理解してほしいなら、そのソフトウェアを説明しなければならない
- 一般的なやり方は、先にコードを書き、後からdoc-commentや使用例を付ける流れである
- 提案されているのは、その順序を逆にして先に文書を書き、その後にコードを付けることだ
- 人にプログラムが何をするのかを説明してから、コンピュータに何をすべきかを伝える
- この概念は文芸的プログラミングとして知られている
- この方法では、他人のコードをいきなり読んで意図を推測するのではなく、まず文書を読んで意図を理解し、その後でコードを確認する
- Entangledはこのアプローチの優れた実装である
- 文書からコードを抽出して適切なソースコードファイルへ配置する双方向tanglerである
- 文書内のコードブロックを編集でき、通常のコードファイルで編集した内容も文書内のコードブロックへ反映される
- テスト、リファクタリング、コードフォーマットのような既存ツールを、特別な文芸的プログラミング対応なしに引き続き使える
- tanglerはビルドシステムに小さなオーバーヘッドを加えるだけで、コンパイラと比べれば特に小さい
- このアプローチはコード自体の複雑さを取り除きはしないが、他人のコードを理解する局面ではLLMの代替になりうる
コードをなくす: GUIと複数の表現
- コードは古い時代の概念であり、端末を通じてコンピュータとやり取りしなければならなかったために使われてきた方法である
- この40年でコンピューティングは変化したのだから、曖昧な記号やキーワードの一次元文字列だけでコンピュータと対話し続ける理由はない
- GUIはテキストベースのインターフェースより複雑な概念を扱いやすくし、新しいユーザーにもよりアクセスしやすい場合が多い
- IDEは単にコードを便利に編集する場所を超え、ソフトウェア開発と相互作用する新しい方法になりうる
- 一部のIDEはすでにこうした機能を提供している
- さらに進めば、視覚的プログラミングは誰もがコード学習なしに欲しいものを作れるほど普遍的でシンプルになりうる
- コード自体を完全に放棄する必要はない
- GUI表現は人が編集可能な複数の表現の一つになりうる
- テキストベースのOSインターフェースを好む人がいるように、コードベースのソフトウェア編集を好む人も今後も存在しうる
- ただし、コードが既定値や唯一の選択肢である必要はない
- 視覚的プログラミングはよりアクセシブルに設計できるが、視覚中心の環境は視覚障害者の排除につながるおそれがある
- 強力なスクリーンリーダー統合が必要である
- 聴覚的または触覚的に豊かに理解できる代替表現も必要である
自然言語を決定論的な抽象化にする
- LLMが抽象化レイヤーを一段引き上げるという話とは異なり、LLMは抽象化ではなく自動化レイヤーに近い
- 抽象化レイヤーは予測可能で信頼できるものでなければならず、高水準の意図が低水準でも正確かつ一貫して表現される必要がある
- LLMはプロンプトを確率的に解釈して意図を予測するため、予測不能に動作する
- 作業結果をランダムに近似する過程を自動化している
- 抽象化だとしても、きわめて損失の大きい抽象化に近い
- 自然言語処理（NLP）の発展は、自然言語から機械語へ至る予測可能なパイプラインを作れる可能性を与えている
- 目標は、LLMプロンプトのように入力しつつ、毎回予測可能で堅牢なプログラムを作ることである
- 他人の作業を盗用コードの平均のように蒸留するのではなく、定義を通じて直接構築する
- このアプローチは文書とコードをより強く結び付けられる
- 文芸的プログラミングでコード部分を自然言語に置き換えれば、文書だけが残るかもしれない
- 人にプログラムの動作を説明する文章が、同時に機械と対話する文章にもなりうる
- この自然言語プログラミングは決定論的でなければならない
- NLPはtransformerモデルの生成能力なしに、文法から意味を解析するために使える
- 解析された文法は、他のプログラミング言語と同様に、プラットフォーム要件に合わせてコンパイルされる中間表現へ直接変換できる
- Informに似ているが、より高度な構文認識と、より広い定義ネットワークにつながった形を想定している
- この決定論的な性質により、プロンプトは信頼性高く一貫してコードへ変換され、これはLLMとは根本的に異なる本当の抽象化レイヤーである
これまでの試み: EveとInform
- この種のアイデアは新しいものではなく、以前にも実装の試みがあった
- Eveは、プログラミングを人間にとってよりアクセスしやすくしようとしたプログラミング言語兼IDEである
- 文芸的プログラミングのアプローチを採用していた
- ドメイン特化のデータ指向プログラミング言語を、ソフトウェアの動作を説明する文書の中に埋め込んでいた
- コードは文書に従属し、プログラミング環境全体もそれを反映していた
- Eveはこのアイデアをさらに進めて、自前の言語をNLPクエリに置き換えようともしていた
- 自然言語処理の複雑さに対処する準備ができていなかった
- 2016年当時は、より進んだNLPを機械学習中心でない企業が容易に利用できる状況ではなかった
- GUI志向のアプローチも実験していた
- 元Eveコントリビューターも、プロジェクトの複雑さとLLMの限界に関する似た懸念を論じている
- Eveは収益化に失敗した野心的なVC投資プロジェクトだったため終了し、アイデアが実を結ぶ様子を見る機会はなかった
- Informはインタラクティブフィクションを作るための宣言的言語であり、こうした概念がより広く適用可能であることを示している
- 自然言語は本質的に漏れやすい抽象化である可能性もあるが、平均的な人が自分のコンピュータを直接制御できるようにする潜在力は、もっと注目に値する
次の段階と提案された取り組み
- 理解可能なソフトウェアを作るためのプロジェクトとしてReTangledが開発中である
- Rustで書かれたEntangled互換の双方向tanglerである
- 文芸的プログラミングを可能な限り拡張し、既存ツールチェーンと妥当な範囲で緊密に統合することが目標である
- 現在は初期開発段階であり、貢献を歓迎している
- 視覚的プログラミング、文芸的プログラミング、自然言語プログラミングそれぞれについて、より完全な文章を書く予定がある
- コミュニティのレベルでは、Eveの足跡を継ぎつつ、少し異なるアプローチを取ることが提案されている
- 目標は、初心者から専門家まで有用に使える、文書化が行き届きアクセシブルな視覚的または自然言語プログラミング環境を作ることにある
- 出発点はソフトウェアをよりよく文書化することであり、最終目標はプログラミングという概念そのものを覆すことである
1件のコメント
Lobste.rsのコメント
コードを捨てたり、自然言語の散文に従属させたりするやり方が、プログラミングのアクセシビリティ問題を解く効果的な解決策なのかは確信が持てない
プログラミング言語は、コンピュータと人間の要求のあいだでバランスを取るユーザーインターフェースである。よく作られた明瞭な形式表記は、個人の理解や、人と機械のあいだでのアイデア伝達を助ける思考の道具になり得る
APL系の言語を学んで大きな影響を受けた。習得には時間がかかったが、一度学ぶと、より大きな問題を頭の中に保持し、より精密に考えられるようになった。Kは、複雑なIDEがなくても、頭の中、紙、単純なREPLだけで問題を解ける
ドキュメントがよく整備されたプロジェクトや文芸的プログラミングには価値があるが、ドキュメントにも読む・書く・直す時間がかかる。テストと同じく、ドキュメントが多ければ無条件によいわけではなく、簡潔で構造化された説明と、説明しやすい簡潔なプログラムを好む。コードは詩になり得るが、ほとんどの詩はプログラムではない
ほとんどの人はこうした内部の仕組みを学ばないだろうから、より多くの人が参加できるよう参入障壁を下げたい
だからLLMが人気なのだと思う。非プログラマーが作業を片付けるためにLLMでコードを書く姿をよく見るが、記事で述べられているように、LLMには避けたい大きな欠陥がある。人々は自然言語や使いやすいユーザーインターフェースで、ゲームを改造し、スクリプトを作り、プログラムを拡張できるべきだ
「コードを廃止しよう」という表現は少し行き過ぎだったかもしれないが、多くの人はコードについて考えたくないし、考える必要もないはずだ
プログラマーたちは非プログラマーを置き去りにしてきたようなものだ
Visual Basicは死に、フレームワークなしのPHPも活発には見えず、Accessも事実上死んだ。NotionやAirtableのようなデータベース風のツールは残っている
プログラマーたちはコードを書くことを愛しすぎて、単純な問題に対する単純な解決策から遠ざかった人が多い
Pythonが一時、非プログラマーの世界を席巻したのは、単純に見え、Pandasのようなツールも使いやすそうに見えたからだ。興味深いことに、多くのプログラマーはPythonやPandasをあまりよいものだと思っていない。たとえば標準ライブラリで簡単にできることをPandasで処理したコードを見ると、かなりうんざりする
昔は非プログラマーでもHTMLページを作り、色や画像を入れていた。今のプログラマーに静的Webサイトを作ってくれと頼むと、とんでもない複雑さが付いてくる。一部は必要だが、大半はまったく不要だ。プログラマーが単純なWebサイトを作るときに使う手順を非プログラマーに渡したら、20年前ならHTML編集を楽しんでいたであろう人たちも悲鳴を上げて逃げ出すだろう
最近むしろずっと難しくなったものがあるという点は、深く皮肉で不安になる
CSSは強力になり、ブラウザは壊れにくくなり、何でも手伝ってくれる個人用コーディングアシスタントもある。素のPythonも同じで、そのまま使えばよい。プログラミングはこれまでになく簡単になった
現代の技術スタックの複雑さにはたいてい理由があるが、理由が生じてから使うべきものであり、初心者が使う必要はまったくない
人々がHTMLのWebサイトや基本的なプログラムを作らないのだとしたら、それはやりたくないからだ。将来は誰もが基本的なプログラミングを知るようになると思っていたが、実際には人々が単にやりたがらないのだと分かった。自動車や自転車も基本的な整備くらいはできるべきだと主張することはできるが、人々は拒む。それは作業が難しい、あるいは不可能だという意味ではなく、やる意志がないという意味に近い
一般大衆のコンピュータ活用能力はほとんど向上していないと思うし、プログラミングの複雑さとは関係がない。教育現場ではむしろコンピュータ活用能力が後退しているようだとも言われるが、それが複雑なフロントエンドフレームワークのせいだとは考えにくい
記事の多くの部分には同意する。たとえば文芸的プログラミングは好きだが、プログラミングそのものがよくないとは思わない
一部のプログラミングはよくないし、BigTech企業で行われるプログラミングは概してよくないことが多い。だが自分自身や愛する人たちのためにプログラムを書くことは今でも楽しい
Entangledは知らなかったが、よいアイデアに見えるし、文芸的プログラミングで最大の苦痛であるLSPと既存ツールから認識されない問題を扱っている。だから今までは主にNixOS設定のような宣言型言語で文芸的プログラミングを使っていた
双方向の文芸的プログラミングなら、非宣言型言語を使うときに生活がもっと楽になるかもしれない。ReTangledを一度試してみるつもりだ
GUIは主に、役員クラス以上の人々が、自分たちにも理解でき、できることを社員がやっているのだと信じられるようにするために存在しているように見える
視覚的なドラッグ＆ドロップ式ETLツールの講習を受けたが、最初のシステムとほぼ同じものを作り直すのは難しく、全体をバージョン管理するのも難しそうだという印象だけが残った。2010年に当時の会社が使っていた視覚的なドラッグ＆ドロップ式cron代替システムも同じだった
役員はドラッグ＆ドロップしやすいが、現場の人間にとってはエラー探し、バージョンやバックアップの維持、再利用が難しくなる
面白いプロトタイプを本番に載せられるものにするには、エラー処理、シリアライズ、デシリアライズ、型の投影などが多く必要になる。優れたユーザー体験には、ほとんど常に汚い内部構造が伴う、というのが私の経験則の一つだ
個人的にはその大半を楽しめず、以前は近道を選んだり、そもそもその作業をしなかったりしたこともある
かなり強く同意します。WYSIWYGエディタを見ると、Web開発を完全に置き換えたわけではありませんが、基本的なWebサイトや単純な商品販売だけを望む人たちのかなりのニッチを減らしました
まだ優れたGUIインターフェースでもっと単純にできるソフトウェア領域は大きいです
今コードを単に継ぎはぎしたり、LLMをやみくもに回したりしているなら、実際にはGUIプログラミングのほうが向いているかもしれません。私がよく使うコードもRESTサーバーであることが多いのですが、こうしたもののための何かを作れない理由はありません
同じ目標を共有しており、自分が使いたいまさにその解決策を提供する技術スタックを何年も考えてきました
Curvというプロジェクトを1つ公開はしましたが、頭の中にだけある、はるかに美しいシステムの小さな一部にすぎません
何千人ものほかの人たちもこの問題に取り組んできました。問題の大きさからするとチーム作業が必要に見えますが、実際には小さな1人プロジェクトがほとんどです。最も強いビジョンを持つ人ほど、チームの目標のために自分のビジョンを妥協したがらないことが多いです。これをどう解決すべきかは分かりません
インスピレーションを与えてくれるプロジェクトとしては、Alan KayのDynabook構想、そこから続いたSmalltalk、Alan Kayの後続プロジェクトであるSTEPS Toward the Reinvention of Programming、Bret Victorの仕事、特に彼の驚くべき成果であるDynamiclandがあります
このテーマに関心のあるコミュニティとしては、以前Future of Codingと呼ばれていたFeeling of Computingがあります。ほかに追加するものがあれば教えてほしいです
「LLMのプロンプトに入れるように指示を入力して完全なプログラムを作り、しかも毎回予測可能で堅牢に動作させよう」という発想は、自然言語から決定的で一貫した意味論をパースできるという巨大な前提に立っています
しかしそもそも、それが真だとは思いません。まだきちんと動作させられたことがないという問題を脇に置いても、可能なことなのか疑わしいです
言語には文脈が多すぎます。同じ文を12回言っても、イントネーション、聴衆、物理的な場所、発話媒体、時間帯によって、毎回微妙に異なる意味が生まれます。従来の自然言語処理手法は、この柔軟性を根本的に扱えません
まさにそのためにLLMが存在します。おそらく存在しない厳密な文脈ルールを定めようとするのではなく、文脈検知を重みにエンコードできるモデルを学習させる方式です。これが驚くほど効果的だと分かりました
人々がLLMを使う理由もここにあります。これまでに作られたどんな自然言語インターフェースよりも、文脈をはるかによく考慮して期待した応答を作れるからです。その観点では、本当に機能しています。LLM以外の自然言語処理は、同じレベルの成功を示せていません
豊かなビジュアルプログラミング環境に関心があるなら、Glamorous Toolkitはあり得る方向性を示す良い例です https://gtoolkit.com/
まだ完成形だとは見ていませんが、既存のものをさらに先へ押し進めたツールです。LLM生成コードの時代には、イメージベースの環境についても語る余地があります
足りないのは、今プログラマーがよく使っているプリミティブ、つまり関数とモジュールで整理されたコード行を超える予測可能な抽象化です
特に単純なデータ変換ではなく複雑な外部システムをモデル化する要件を、そのような要素だけで表そうとすると、人間のプログラマーが作っても、ますます大きくなる泥団子になります。LLMもその姿をまねています