ハクソク

世界を動かす技術を、日本語で。

なぜCommon Lispが今最も優れたプログラミング言語なのか

2026年10月6日原文(vivienhenz.com)

概要

  • プログラミング言語の優劣についての考察
  • Common Lispの特徴とLLM時代における強み
  • フィードバックループの短縮による開発効率の向上
  • マクロやドメイン言語による柔軟性と拡張性
  • Common Lispの現実的な課題とその克服方法

プログラミング言語の優劣とCommon Lispの位置づけ

  • 一部の プログラミング言語 は他よりも優れているという主張
  • Common Lisp が現代において最適な選択肢であるという立場
  • LLM（大規模言語モデル） によるコード生成の高速化が状況を変化させた現状

フィードバックループの重要性とCommon Lispの強み

  • コードの フィードバックループ が開発速度を決定する要因
  • Common Lispでは read-time, compile-time, runtimeの区別がほぼ存在しない 特徴
  • イメージベース で動作し、関数の差し替えが即時反映される仕組み
  • エラー発生時も プログラムがクラッシュせず、デバッガが起動 し、LLMがそのまま修正・再開可能

Lispの構造とマクロによる拡張性

  • Lispは "List Processing" の略称で、コードもデータもリストとして扱う

  • コードのリスト構造 により、プログラムがプログラム自身を柔軟に書き換え可能

  • マクロ の存在により、独自の言語構造やドメイン言語の構築が容易

  • ドメイン言語により、 企業の意図や方針を反映したプロダクト開発 が可能

    • 例：ERPシステムを自社ドメイン言語で構築し、LLMでのカスタマイズが容易

コードの簡潔さとLLM活用の強み

  • マクロによる抽象化 でコード量が大幅に短縮
  • Common Lispのアプリは Pythonの6～7分の1の行数 で実現可能な経験則
  • コード量の削減により LLMのトークン消費が減少 し、コスト削減
  • LLMの コンテキストウィンドウ 内により多くのコードが収まり、意図の伝達が容易

Common Lispの標準化と安定性

  • ANSI規格 で1994年以降アップデートされていない安定性
  • 製品のユーザーが自らカスタマイズする場合、 基盤が変化しないメリット

ライブラリ不足とその解決策

  • Quicklisp の登録パッケージ数はnpm等に比べて少数
  • 依存パッケージのセキュリティリスク回避の観点からも ライブラリの少なさはデメリットではない
  • LLMを活用し、 必要な部分を自作・移植 することが容易

エンジニア採用の現実的な課題と対応

  • Common Lispの 習得者が少ない 現状
  • 優秀な技術者は 新しい技術の習得が早い ため、採用時に学習を課せば問題解決
  • 学習意欲や適応力の高い人材の見極めが可能

結論

  • 次にプログラムを書く際は Common Lispの利用を推奨
  • 参考文献： Paul Graham, "What Made Lisp Different."

Hackerたちの意見

同じようなアイデアを持ってたことがあるんだけど、依存型言語での完全なマクロシステムがあったらいいなと思ってる。1月にやってみたけど、ちょっと違ったみたい。でも、これが正しい方向だと思う。なんか、LLMの文脈では、普通の人間の文脈よりも簡潔さがもっと重要だよね。

└

ツリー計算について調べたことある？

└

驚いたのは、LLMがLispマクロを書くのがすごく上手だってこと。これまでイライラさせられた面倒なボイラープレートやバックティック・カンマの計算（カンマいる？）を、彼らは楽しそうに正しく出力してくれる。必要以上に複雑な方法でやってないか確認するけど、もしかしたらそれは俺が迷信にとらわれてるだけかも。驚くべきことじゃなかったんだよね、マクロを書く部分は純粋に機械的な構文変換だから。要するに「これらのトークンを取って、あれらのトークンを返す」関数だから、LLMが得意なのは当然だと思う。でも、俺にとってはそれがいつも難しい部分だったから驚いた。だから、今はコードのパターンを抽象化する新しいマクロを考えられるようになった—マクロを書くのが楽しい部分ね。そして、魔法の「これを実装して」ボタンを押せば動く。まだ確信が持てないのは、これが進化の行き止まりなのかどうかってこと。「もうコードを見ることはないから、どのプログラミング言語を使ってたかなんて関係ない」っていう道の途中の駅なのかも。うん、まだ自分のコードを見るし、どこに線路が続いても、これはかなりいい駅だよ。

└

Leanに興味があるかもしれないね。俺のお気に入りのリスプだけど、実際にはリスプじゃないんだ。いいプログラミング言語で、コマンドやマクロ、構文、詳細化を本当にハックできるんだよ。

└

Leanは依存型言語で、最先端のメタプログラミングシステムを持っているんだ。Lean自体もこのシステムを使って書かれた言語だよ。

記事の半分は、CLが例外から再開できるから良いって話で、もう半分はDSLが良い理由について語ってると思う。他の人たちも指摘してるけど、ほとんどの現代のスクリプト言語は、スタックを展開せずに例外で停止できるんだ。PythonとNodeは、コアツールでこれをサポートしてる。DSLについては、LLMを制約することで一般的にコードの質が向上する。でも、なんで制約のないCLの混沌の中でDSLを実装するの？RustでDSLを書くことができるし、静的型付けや借用チェッカー、クリッピーもあるよ。

└

Common Lispは、開発ツールなしでこれらの機能を持ってるんだ。- 条件[0] - 評価とコンパイル[1] 開発やデバッグ、分析の際に両方を広く使ってる。SLIME（これは標準的で、すごくスリムな開発支援ツール）を使うと、再起動や戻る、上下移動などができるデバッガーフックを追加できるよ。 [0] https://www.lispworks.com/documentation/HyperSpec/Body/09_.h... [1] https://www.lispworks.com/documentation/HyperSpec/Body/03_.h...

└

ほとんどの言語に欠けているのは、本当にネイティブなホットリロードだよ。Pythonは、すごくダイナミックで辞書のためのリスプなのに、意外とそれができない。Nodeはできるかもしれないけど、少なくともTypeScriptはできないし、俺はショゴスにプレーンなJSを触らせたくない。

└

RustではDSLを書くことができて、静的型付け、借用チェッカー、クライピーも使える。コンパイラが終わるのを待たせることにもなるけどね。

LLMにとって、コードが少ないほどトークンも少なくなるし、トークンはお金がかかるから、開発にかかるコストが減るんだ。でも、それが厳密に正しいとは思わない。必要なのは、LLMができるだけ少ないトークンで変更を加えられるように、十分なコンテキストを理解できることだから。もしコードが表現力不足だったり、いろんな関数やメソッドを呼び出しているなら、他の部分に依存しないきれいにカプセル化されたモジュールがある場合よりも、もっと多くのコード（コンテキスト）を与えなきゃいけない。アーキテクチャの設計（おそらく？）は、大規模アプリにおけるトークン使用に対して、書かれている言語よりも大きな影響を与えると思う。ただ、もちろん、言語は特定のアーキテクチャに向いているから、相関関係はあるよね。

└

その点ではAPLが勝つね。

└

昔、Clojureプログラマーと強い型付けの言語で働いてる人との議論を思い出すな。議論の内容は「型があると、コードを変更したときに無関係だけど影響を受ける部分もフラグが立つから、見逃すことがない」ってことだった。Clojureの人は「なんで一箇所の変更が他に影響を与えるようなプログラムを設計するの？」って返してた。これは、まだ「発見」されていない機能型言語の無関係な利点だと思う。FPの根本的な考えは、コードが依存するものを減らすことで「頭の中に収めて推論できるようにする」ってことだから、エージェント的な観点からも完璧なバランスだよね。まだその点を本気で活用しているツールは見かけないけど。

Hacker Newsで議論の続きを見る