Common Lispは最強か LLM時代のマクロ論争で海外エンジニアが激論

姉妹サイトの新着

Hacker Newsで「Common Lispこそ今の最高のプログラミング言語だ」と主張する記事が話題になり、賛否両論のコメントが集まった。きっかけは、LLMによるコード生成時代において、マクロで作れるドメイン特化言語(DSL)や、エラーが起きてもスタックを巻き戻さずその場で値を直して処理を再開できるCommon Lisp特有のデバッグ機能が、AIとの協業に向いているという主張だった。これに対し「半順序には最大元があるとは限らない」という数学的な反論や、Smalltalk・Erlang・Juliaなど他言語でも似たことができるという指摘が相次ぎ、議論はLLM時代の開発スタイルそのものを問う方向に広がった。

Common Lispが今こそ最高のプログラミング言語である理由

出典: vivienhenz.com / 元記事はこちら

3 海外の名無しさん 2026-10-06 04:56
CかRustでコアを書いて、その上を全部Janetで書くという案をずっと考えている。Lispの読みやすさが好きで、マクロを使えば抽象化のレベルを一気に上げられる。ライブイメージ上で作業できれば、LLMを使った開発の反復もすごく楽になるはずだ。
4 海外の名無しさん 2026-10-06 04:28
自分も似たようなことを考えていた。依存型言語にフルのマクロシステムが載ったら最高だと思う。1月に試しに作ってみたけど、あれはちょっと違った。でも方向性自体は間違っていないと思う。不思議なことに、簡潔さは人間相手よりLLM相手のときのほうがむしろ重要になる。
18 海外の名無しさん 2026-10-06 04:42
>>4 Leanが気に入るかもしれない。自分のお気に入りの『Lisp』なんだけど、実際には全然Lispじゃない。いい言語で、コマンドやマクロ、構文、エラボレーションまでいじり倒せる。
20 海外の名無しさん 2026-10-06 04:29
>>4 tree calculus(木計算)って見たことある?
5 海外の名無しさん 2026-10-06 04:19
関連リンク: AIとLispを繋ぐ話を書いたブログ記事(opusmodus.comのフォーラム)。
6 海外の名無しさん 2026-10-06 04:38
『プログラミング言語に優劣があることに同意するなら、その中に最高のものが1つあるはずだ』という理屈は誤り。半順序には必ずしも最大元があるとは限らない。
21 海外の名無しさん 2026-10-06 04:45
>>6 たしかに、それは言われてみれば納得(笑)参った。
7 海外の名無しさん 2026-10-06 04:50
Common Lispは既存のライブラリや実例が少ないから、スタック全体をゼロから書くことになるんじゃないか?
8 海外の名無しさん 2026-10-06 04:16
それってSmalltalkやErlangでも大体できるんじゃないか?あと、LLMがある時代にマクロが何の役に立つのか分からない。LLMは仕事をこなすのにDSLを作る必要なんてないと思うんだけど。
22 海外の名無しさん 2026-10-06 04:22
>>8 言いたいのは、CLなら領域に特化したDSLを作れて、それでトークン使用量が減るということだと思う。でもその主張を裏付けるデータが見てみたい。それに、そのDSL用の『マニュアル』をLLMに渡す必要があるんじゃないか?それだってトークンを消費するはずだ。
23 海外の名無しさん 2026-10-06 04:26
>>8 Smalltalkなら、イメージベースのシステムとしてはまさにその通り。Erlangはそこまでではなくて、『アクターをクラッシュさせて再試行』という思想で、『巻き戻して一時停止し、システム内でエラー処理する』という感じではない。
24 海外の名無しさん 2026-10-06 04:20
>>8 LLMが仕事をするのにDSLが必要ないという点には同意する。言いたいのは、DSLには作った側の『考え方』が反映されるということだ。
9 海外の名無しさん 2026-10-06 04:48
いや、LLM時代なら一番使われている言語が一番いい出力を出すはずだ。
25 海外の名無しさん 2026-10-06 04:56
>>9 そうとも言い切れない。ただ、人気言語に一定の優位性はあるらしい。Dan Luuがこのテーマを検証している。
27 海外の名無しさん 2026-10-06 04:49
>>9 自分の経験では全然そんなことはない。Claude 3.7以降、LLMはJuliaでもかなりうまくやってくれている。
10 海外の名無しさん 2026-10-06 04:46
ソフトウェア企業が、ユーザー都合でソフトを変えるとは思えない。
11 海外の名無しさん 2026-10-06 04:50
自分の経験では、LLMはクラッシュの原因を即座に見つけて修正してくれる。もうデバッグの工程を踏む必要すらない。生成しているのがC++でもLispでもCOBOLでも関係ない。
12 海外の名無しさん 2026-10-06 04:49
ただベンチマークを見ると遅いしメモリも食いすぎている。とはいえCarpみたいな発想はすごく魅力的だと思う。それでもCommon Lispの設計自体はとても良い。
13 海外の名無しさん 2026-10-06 04:17
面白いとは思うけど、その言語のサポートが手薄な分、自分で書かなきゃいけない追加のインフラはどうなる?結局メンテする自分のコードが増えるだけじゃないか。
28 海外の名無しさん 2026-10-06 04:26
>>13 コード生成がどんどん安く、どんどん高品質になっていく未来に向かっているなら、欲しいライブラリを自分でポーティングするのを止めるものは何もないんじゃないか?
15 海外の名無しさん 2026-10-06 02:59
その話、ぜひしたい。
33 海外の名無しさん 2026-10-06 04:16
>>15 まさにこの話、数日前に誰かに説明してたところだ。例にERPを使ったりして。まったくその通り。
42 海外の名無しさん 2026-10-06 04:56
>>33 …それなら、業界をまたいだり事業が変化したりする中で共通のDSLがほぼ不可能になる、ERPシステムの背後にある複雑さを掘ってみるのも知的に面白いと思う。DSLは意味論についての合意を前提にしているけど、そこが大抵一番難しい部分だ。
16 海外の名無しさん 2026-10-06 04:49
今も昔も『最高のプログラミング言語』なんて存在しない。仕事に合った道具があり、要件への適合があり、個人の好みがある。誰かに『お前のプログラミングは間違っている』なんて言わせるな。
29 海外の名無しさん 2026-10-06 04:39
>>14 ここで言われているのは、例外が発生してもスタックが巻き戻されないということだと思う。例外が捕捉されなくても、該当の行や値を直して、スタックがあった場所から処理を再開できる。
30 海外の名無しさん 2026-10-06 04:24
>>14 それはデバッグビルドで動かしている場合の話だよね。Common Lispは本番環境でもそれができるということ?
35 海外の名無しさん 2026-10-06 04:27
>>22 自分が言いたいのはその逆。『CLがAI向けに最高の言語だ』という主張の根拠として、マクロは決め手になる機能だとは思わない。あなたの言っていることには同意する。

他サイトの新着

36 海外の名無しさん 2026-10-06 04:42
>>28 一番大きいのは、連携しようとしている相手のドキュメント化されていない癖や仕様を、自分で全部発見し直す必要があること。あと、すでに誰かがペンテストしたものを使うのではなく、自分でペンテストやレッドチーム作業をやらなきゃいけなくなることも地味に痛い。
43 海外の名無しさん 2026-10-06 04:48
>>36 そうだね、アプリケーションコードは全部LLMに書かせるけど、ライブラリ、特に基盤になるようなものは任せるのはまだ怖い。
37 海外の名無しさん 2026-10-06 04:26
>>30 それってJavaScriptでもできるんじゃないか?そもそも本番環境で顧客の画面にデバッグウィンドウが開いてほしいか?Windowsが昔、プログラムがクラッシュしたときにデバッガを開こうとしてきたのを覚えてるけど、あれの意味なんて自分にはまったく分からなかった。
44 海外の名無しさん 2026-10-06 04:39
>>37 バックエンドの話だと思ってた。それでもメリットがよく分からない。具体例があると助かる。
49 海外の名無しさん 2026-10-06 04:45
>>44 ちょうど今、具体例を書き終えたところ。二重に書くのも何だから、リンク先を見てほしい。
50 海外の名無しさん 2026-10-06 04:46
>>44 想像では、本番バックエンドにLLMをデバッグインターフェース経由でつないでおいて、例外が起きるたびにコードを継続的にパッチしていく、という感じだと思う(自分はCLの専門家ではないけど)。
41 海外の名無しさん 2026-10-06 04:25
>>32 これは他の多くのインタプリタ言語でもできる。例えばPythonなら専用フラグを付けて実行すれば同じことができる。CLの場合はインタプリタモードで実行しているときはデフォルトでこの挙動になって、コンパイル済み(本番用)バイナリではその挙動が省かれているんじゃないかと思う。
46 海外の名無しさん 2026-10-06 04:27
>>41 それはいいけど、そのときサーバー自体はどうなる?処理していた接続はタイムアウトするだろうけど、残りの部分は止まったままになるのか?
47 海外の名無しさん 2026-10-06 04:33
>>41 CLではこれ、コンパイル済みコードでも動く。
45 海外の名無しさん 2026-10-06 04:44
>>40 いいデバッガには見えるけど、他の言語で使ったことのあるものと似ている。これの何が特別なんだろう?本番環境でデバッガを使うという話だと思っていたけど、どうも記事が言いたいのはそういうことじゃない気がしてきた。

この話題の背景と論点

今回の論争の核心は、Common Lispの「条件システム」にある。例外が発生してもスタックを巻き戻さずその場で値や処理内容を修正し、処理を再開できる仕組みで、1980年代のLispマシン以来の伝統機能だ。スレ内では複数の参加者が「他言語のデバッガと何が違うのか」と聞き返しており、一般的なtry-catch型の例外処理とは設計思想が異なる点が伝わりにくかった様子がうかがえる。また「DSLを作ればLLMのトークン消費を抑えられる」という主張についても、具体的な裏付けデータは示されなかった。LLMの出力品質と言語の人気度の関係を調べたDan Luuの分析(danluu.com/pl-tokens)が引用され、単に使用者の多い言語ほど出力が安定するという見方も紹介されている。「最高の言語は存在しない、半順序に最大元は無い」という数学的な指摘は、議論の過熱を一歩引いて見る視点として機能していた。

※本記事は海外掲示板 Hacker News のスレッド「Why Common Lisp is now the best programming language」から抜粋し、編集部で日本語に意訳したものです。訳文の責任は当サイトにあります。

この記事のリアクション

他サイトの新着

まだコメントはありません。

コメントする

誹謗中傷・個人を特定する書き込みは削除対象です。投稿は承認後に表示されます。

相互リンクサイト新着記事