「動的言語はLLMに効率的」説を検証――ZstdとPandocで実測した結果
What's the best programming language for coding agents?
「動的型付け言語はコードが簡潔でLLMのトークンコストが低い」という広く引用される主張を、著者が独自の評価で検証。Zstdデコーダの実装とPandocのテストという2つの実タスクで、動的/静的言語のパフォーマンスを比較した結果、中程度の努力では動的言語が有利に見えるが、高度な努力では優位性は消え、言語の人気が正の相関を示すことを発見。また、Jのような難解な高密度言語の優位性も再現せず、主流言語の使用を推奨している。
動的型付け言語は一般的に、明示的な型宣言を省略することでコードがよりコンパクトになるため、LLMのトークンコストが低いという主張は、せいぜい漠然と方向性が正しいだけで、特定のケースには当てはまらず、一般的に意味を持つほど強くはないかもしれない。
HNでの議論
188- michaelteter
「平均わずか70トークンで、Clojure（109トークン）のほぼ半分」と言う情報源は信頼できない気がします。「ほぼ半分」という表現を加える理由はありませんし、実際には半分からかなり離れているのに、特にその表現を加える理由はありません。
しかし、本題に関しては、GoはLLMにとって優れた選択肢だと今でも思います。ほとんどのことを行う方法がほぼ一つしかなく、利用可能なトレーニングデータはかなり一貫しています。これはPythonとは大きく異なります。Pythonのトレーニングデータは（おそらく）ソフトウェアエンジニアではない人々によって書かれたコードで汚染されており、同じことを行うさまざまな方法を示しています。
また、Goの大きな利点はツールです。コンパイルが速く、リンティングも優れているため、イテレーションのサイクルタイムが短縮され、LLMに間違いを修正するよう指示する必要性が減ります。
何らかの理由で、私が使ったほとんどのLLMはデフォルトでPythonを書きたがります。非常に説得力のある理由がない限り、Goを使うように繰り返し教えなければなりません。
個人的にはClojureを見たり使ったりしたいですが、そのエコシステムがGoと同じ利点（明らかに簡単なシングルバイナリ配布を含む）を提供するとは思いません。
- MichaelNolan
LLMがGleam[1]とLustre[2]を書くのがどれほど得意かには驚かされました。主流の言語と比較すると、トレーニングデータにはGleamのコードがほぼ存在しません。
これを裏付ける証拠はありませんが、人間にとって良い言語[3]はLLMにとっても良いだろうと疑っています。コンパイルされ、強い型付けで、静的に型付けされ、不変で、純粋関数で、パターンマッチングされ、メモリ安全であることなどです。
[3] はい、「人間にとって良い」言語機能が何かは激しく議論されるテーマだと認識しています。それは私が言語に求める個人的なリストにすぎません。
- tadamcz
私たちはMirrorCodeの論文[1]でこの問題をかなり体系的に研究しました。Python、C、Rust、Go、OCaml、Adaを、Claude Opus 4.7とGPT-5.5で、19の非常に長期的なタスクにわたって比較しました。
> 私たちの結果では、どのモデルについても、言語間の解決率の違いはほとんど見られませんでした（図5b）。これは、AIモデルが構文のパターンマッチングではなく、一般的なプログラミングスキルを学習していることを示唆しています。これは実装言語が無関係であることを意味するものではありません。ターゲットの解決に条件付けた場合、トークン使用量に小さな影響が見られました。成功したPythonソリューションは平均よりも少ないトークンを使用する傾向があり、成功したAdaソリューションはより多く使用する傾向がありました（付録C）。これらは、これら6つのプログラミング言語が簡潔さと標準ライブラリが提供する機能の量（MirrorCodeではエージェントは依存関係をダウンロードできず、標準ライブラリのみを使用してタスクを解決しなければならないことを思い出してください）が大きく異なることを考えると、小さな違いであると考えています。
付録Cでは、Adaは平均的な言語よりも約25%多いトークンを使用する傾向がありました。Adaは主に安全重視の航空宇宙および防衛システムで使用される言語であり、CやPythonよりも約200倍少ない事前トレーニングデータしかありません。
また、コスト上の理由から、より最近の言語モデル（Go対Adaのみ）をリーダーボード[2]で比較しています。
- Lutger
ほとんどのコメントが示していることとは反対に、私がこれから得た教訓は、エージェントにとって言語の選択はそれほど重要ではないということです。もし人間がまだプロセスに関与するのであれば、その言語が人間に読めることが必須であり、したがって開発者の好みやスキルが第一の関心事であり、エージェントではありません。
- gr_norm
既存のよく知られたソフトウェアを複製することが、この種の評価にとってどれほど有用なシグナルなのかは私には明確ではありません。LLMがトレーニングコーパスからデータを取得し、それを異なる設定（ここではプログラミング言語）にスタイル転送する効果について私たちが知っていることを考えると、です。それが、この投稿のタスクにおける異なる言語間での能力の収束を説明するでしょう。私は人々の実際の経験にもっと興味があります。
- dang
関連：
どのプログラミング言語が最もトークン効率が良いか？ - https://news.ycombinator.com/item?id=46582728 - 2026年1月（91コメント）
- nylonstrung
注目すべき点の1つは、構文の密度が必ずしも安価であることを意味しないということです。なぜなら、記号はプレーンな英語ほどチャンク化/トークン化されないからです。
このような結果から私が見るのは、言語間の差が今では十分に小さく、LLMを使用していてドメインに適合する場合、パフォーマンスと正確性の利点のためにRustのようなものを使用しないことを正当化するのは難しいということです。
- summarybot
興味深い質問ですが、1つの情報が極めて重要であり、まだ含まれていません。それは、各言語での同等の成果です。たとえば、標準的なもの（Webサーバー、メモ化されたフィボナッチ、レシピ検索エンジン）を書きたい場合、各言語での出力の長さと密度はどうなるでしょうか？それが何らかの正規化を加えると思います。