Common LispがAIコード生成の最強ターゲットである理由

私の直感では、この投稿は180度間違っています。LLMは「エリートコーダー」の正反対であり、完璧なStackOverflowユーザーです。

* 彼らは小さな規模のパターンを非常に効率的に記憶し、適応し、書き戻します。

* 広く使われているライブラリを熟知しており、ドキュメントが不十分でも数分で他のライブラリを学べます。

* 彼らはしばしば良い結果を生み出します。なぜなら、私たちが書くコードのほとんどは独創的ではなく、トレーニングコーパスにすでに何十ものバージョンがあるものを言い換えたものだからです。

* しかし、意味のある、自明でない、簡素化する抽象化を見つけるのは苦手で、私たちが本当にスプーンで餌を与えるように教え込む必要があります。

* 彼らは冗長さを好みます。それは文字通り彼らの「思考」方法です。

* 彼らは繰り返しも好みます。「繰り返し」の別の用語は「パターン」であり、彼らは基本的に優れたパターンマッチャーです。

したがって、Lispは典型的なLLM補完的なハッカーにとっては楽しいものですが、LLMにとってはそうではありません。LLMは典型的には、Lispを嫌っていた「非エリート」開発者を置き換えます。その理由は驚くほど似ています。

私が望むのは、「普通の」プログラムをLisp風の疑似コードに忠実に言い換えるように訓練されたLLMです。そうすれば、レビューがより速く、より信頼でき、より楽しくなります。しかし、手書きのコードは手書きの機械語コードと同じ道をたどっています。LLMには最適なものを与え、私たちがまだ関連性を持つより抽象的な仕事には高レベルのツールを与えましょう。それはさまざまな形のコードレビューでしょう。

開発がチームスポーツであり、適切な…

1974年に高校で最初のLispプログラムを書きました。教師のストライキの間、私たちオタクの何人かはバスでトロント大学のコンピューティングセンターに行きました。それはカフェテリア方式のシステムで、パンチカード機が並ぶ部屋がありました。プログラムをタイプし、カードデッキを持って列に並びました。列はジョブカードのサイロから始まりました。FORTRAN、Lisp、PL/1、WATBOL、SNOBOLなどを書いて、IBM 360メインフレームで実行できました。

順番が来たら、デッキをカードホッパーの上に置きました。ほとんどのプログラムはカード0.5インチ分だったので、ホッパーには多くのジョブがあり、2フィートのカードを受け入れることができました。

列は最後にある1442ラインプリンタまで続き、そこでは結果のプリントアウトが驚くべき速度で繰り出されました。オペレーターがプリントアウトを渡し、パンチカード室に戻って結果を確認し、カードデッキに必要な変更を加えました。

すごいのは、私たちは明らかに15歳で、トロント大学には通っていなかったことです。そして、私たちのジョブは明らかに授業のためではなく、カードデッキは1.5インチの厚さで、ゲームボードの設定の長いプリントアウトが付いていました。

しかし、誰も目をくれませんでした。私たちは何ヶ月も毎日通いました。

最終的に、Lispマシンの時代に大学に行きました。教授のために働き、彼は私にcpscビルのオフィスをくれました。彼は私に奴隷のような賃金を払いましたが、Lispマシンラボは私のオフィスの向かいにあり、彼らは私に鍵をくれました。鍵を持っていない人を入れるためです。Symbolics 36xxのマシンがChaosnetで動作していました。騒がしいですが、リ…

Common Lispを学ぼうとかなりの時間を費やし、本当に気に入りたかったのですが、お勧めできるかどうかはわかりません。最初の問題は、良い学習教材を見つけることです。ほとんどが絶版です。言語面では、人々は括弧について文句を言いますが、それは大した問題ではないことがわかります。しかし、他にも奇妙で不必要にトリッキーなものがたくさんあります。関数名は複雑です（例えば、map、mapc、mapcan、mapl、maplistがあります）。イメージベースの開発は興味深かったですが、イメージが実際のコードから乖離しているためにデバッグに1時間費やすかもしれません。実行可能ファイルのビルドは予想以上に複雑で、パッケージには多くの魔法があります。目を細めて見ればいくつかの優雅さがありますが、他のLispの方がおそらく優れています。

いや、結構です。Common Lispは、ポストLLMの世界で私に喜びをもたらす唯一の言語であり、そのままでいてほしいです。

一般的なベンチマーク（artificial intelligence、gertlabsなど）の弱点は、私の理解では、各言語の特性に本当に対応していないことだと思います。CLやClojureのような言語が優れたREPL体験を誇るなら、それはベンチマークでは完全に無視されます。なぜなら、それらは単に一般的なプロンプトの結果を見るだけだからです。

だから、あれやこれやの言語の優位性について数え切れないほどのブログ記事を書く代わりに、ベンチマークの方法論を改善することに取り組むべきです。そうすれば、より有用な結果が得られるでしょう。

私のLLMプロジェクトの多くでは、さまざまな目的でDSLを使用してきました。これらのプロジェクトの多くはデータが中心なので、Djangoを使用しています。そのため、これらのDSLにはhy（LispとPythonの組み合わせ）がかなりうまく機能しています。Claude Codeがhyコードを書くのに問題はありませんでした。

最近、あるプロジェクトでCLを使用しています。多くの機能があり、実際に使うのが理にかなっていたからです（馴染みはありませんでしたが、elispと少しのSchemeを使ったことはありました）。いくつかの点は素晴らしい一方で、いくつかの点は依然として問題点であることがわかりました。SBCLは素晴らしいプロジェクトでありコンパイラで、デバッグに慣れればSLIMEでの体験は非常に快適です。柔軟性が素晴らしく、CLOSオブジェクトシステムも慣れれば非常に良いと言えます。AI支援コーディングに関しては、賛否両論で、Claudeは今ではかなり得意ですが、ローカルモデルはかなり貧弱で、多くのことが文書化されておらず、コードも少ないです。ローカルモデル（おそらくフロンティアモデルでも、サイズが大きいため私の使用では問題は完全に解消されますが）で注意すべき点の1つは、'('や')'がトークンの一部である可能性があり、'))'が個別のトークンであり、'(*'も同様である可能性があることです。つまり、コードを書くときにブロックの終了と開始が問題になる可能性があり、括弧がずれることがあります。これはomnicoder 9Bを使用していたときで、それが主な問題でした。最近のローカルモデルがどう機能するかはわかりません。一部をClaudeに切り替え、時間をかけて自分でコードを書くことを好みました。