ハクソク

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

言語設計をやめて、ライブラリを書くべきだ

2026年1月7日原文(lbstanza.org)

概要

  • プログラミング言語の違い よりも、 ライブラリの充実度 が生産性に直結
  • Ruby on Rails のようなフレームワークは、言語特有の機能を活用している
  • 言語設計 は、どんなライブラリが書けるかを決定
  • ライブラリの限界 は言語の限界でもある
  • 理想の言語 は、ライブラリ作者が必要な拡張を簡単に実現できるもの

言語設計をやめて、ライブラリを書こう

  • 多くのプログラミング言語は 基本構文や機能が似通う 傾向
  • 一般的なプログラマにとって、生産性を高めるのは 使いやすいライブラリの存在
  • 例： Ruby on Rails によって、非専門家でも本格的なWebアプリ開発が可能に
  • 言語自体へのこだわりよりも、 Railsのようなフレームワーク に魅力を感じる意見が多い
  • 専門的な言語機能（例：ファーストクラス関数やコルーチン）は、 多くのユーザーが意識せずに恩恵を受けている

なぜRailsのようなフレームワークは他言語で再現できないのか

  • Ruby on Rails は、Ruby特有の メタプログラミングやランタイム評価機能 を多用
  • JavaやCなど、 他言語のメタプログラミング機能の制限 により、同様のフレームワーク構築が困難
  • 言語の設計が ライブラリの表現力や使いやすさ を直接左右
  • 例：C言語のライブラリは関数群中心、JavaのGUIライブラリはハンドラークラスの作成が必須

インタラクティブなソフトウェアとライブラリ設計

  • 初期のソフトウェアは バッチ処理が主流 で、関数の再利用で十分
  • 近年は インタラクティブなアプリケーション が主流となり、 拡張性の高いライブラリ が求められる
  • JavaやC++は サブクラス化 による拡張を提供、これが「フレームワーク」という新しい概念を生んだ

言語設計の動機とライブラリの限界

  • 新しい言語開発の動機は、 既存言語で望むライブラリが作れないこと への不満が多い
  • 例：Javaでゲームライブラリを作ろうとしたが、 コルーチンや継続の欠如 で限界を感じた経験
  • Schemeのような言語は 継続をサポート し、より直感的なゲームロジック記述が可能
  • しかし、 型システムの拡張などはライブラリでは実現困難。主流言語で型システム自体をライブラリで拡張できるものはない

言語の本質的な役割

  • 汎用プログラミング言語の目的 は、強力で使いやすいライブラリの実現を可能にすること
  • 言語が強力であればあるほど、 ライブラリの表現力・使い勝手が向上
  • どんなライブラリが書けて、どんなライブラリが書けないかが 言語の個性や限界 を決定
  • 例：Stanzaはオプション型システムやマルチメソッド型オブジェクトシステムなどを提供
    • しかし、オブジェクトシステム自体をライブラリで差し替えることはできない

これからの言語設計とライブラリ

  • 未来の理想的な言語は、 ライブラリ作者が型システムやオブジェクトシステムを自由に拡張可能 なもの
  • RacketやShenは型システム拡張をサポート、メタオブジェクトプロトコルの研究も進行中
  • ライブラリの可能性と限界 が、言語設計の主戦場となる

結論

  • 強力なライブラリ は、多くの言語設計上の工夫や研究の成果
  • 使いやすいライブラリの背後には、 言語機能の選択と設計思想 が存在
  • もしライブラリの優雅さに感銘を受けたら、 どの言語機能が使われているか を調べてみる価値
  • サブtleな言語仕様に興味がなければ、 そのままライブラリの便利さを享受 しても問題なし

Hackerたちの意見

: https://hackage.haskell.org/package/shh

└

: https://docs.haskellstack.org/en/v3.9.1/topics/scripts/

└

: https://wiki.nixos.org/wiki/Nix-shell_shebang ちなみに、依存関係のあるHaskellスクリプトにnixのシェバンを使うなら、impure inputsの代わりにhttps://github.com/tomberek/-を使った方がいいよ。キャッシュ評価ができるからね。俺はこのリポジトリを自分のGitLabアカウントにクローンしたんだけど、小さいし、絶対に変わらないはずだから。

└

強い（でも徐々に）型付けされたスクリプト言語を探してるなら、https://raku.orgをチェックしてみて。

└

nushell見たことある？これを使うと、以前は「本物」の言語を使わなきゃできなかったことが、ワンライナーでできちゃうんだ。 ちょっとした例を挙げると：

ls | where type == 'file' | sort-by size | take 4 | each {|f| {n: $f.name, s: ($f.size | format filesize MB) }} | to json

出力はこんな感じ：

{ "n": "clippy.toml", "s": "0.000001 MB" },
{ "n": "README.md", "s": "0.000009 MB" },
{ "n": "rustfmt.toml", "s": "0.000052 MB" },
{ "n": "typos.toml", "s": "0.00009 MB" }
└

ここ数日前にGoにシェバンのようなものを追加するトリックが共有されてたよ。興味があるかもね： https://lorentz.app/blog-item.html?id=go-shebang ディスカッションはこちら： https://news.ycombinator.com/item?id=46431028

└

数ヶ月待ってれば、そのプログラムは型付き言語で書かれるようになるよ。Elixirの型チェッカーは順調に進んでるし、リリースのたびにチェックが増えてるからね。

└

OCamlはこの意味ではスクリプト言語だね。実行可能ファイルを事前にコンパイルする必要はなくて、ソースファイルの先頭に#!/usr/bin/env ocamlって書けばいいんだ。（もっと現実的には、#!/usr/bin/env -S ocaml -I +unix unix.cma）ただ、1ファイルのスクリプトが自動的にインストールされる3rdパーティの依存関係を宣言する機能はないと思う。

└

Babashka（https://babashka.org/）はスクリプト用の面白いツールだよ。Clojureだから動的型付けだけど、データ指向のおかげで君の例みたいなものにぴったりだと思う。

└

@dev_l1x_be: 答えは新しい型付きスクリプト言語じゃないよ。インタープリターが何であるかを認識することだ。LLMはeval()だ。スキルはプログラム。YAMLはマザーボード。@unkulunkuluが言ってる通り、「ライブラリは最終的な言語」、言語は全ての基盤だ。まさにその通り。スキルは言語そのもの。インタープリターに何を理解させるかを教えるんだ。インタープリターが意図を理解すると、その区別は消える。@conartist6: 「DSLは曖昧... 言語とライブラリは対立する必要はない」って言うのも正しい。伝統的なDSL: パース -> AST -> 評価。LLMの「DSL」: 意図を読み取る -> 理解する -> 行動する。全て一つのステップ。文の途中でコードスイッチしても気にしない。RORのような意見が強いフレームワークやDHHのようなBDFLの問題は、一つの意見が間違った数になることだ！ 誰も言ってない重要な洞察: 光の速さ vs キャリアピジョン。キャリアピジョン: LLMに呼びかけて、応答を得て、解析して、再度LLMを呼び出し、繰り返す。遅いし、ノイズが多い。往復するたびにトークン化で精度が失われる。光の速さ: 一回の呼び出し。俺は33ターンのStoner Fluxxを実行した -- 10キャラクター、たくさんの意見、ゲーム状態、手札、ルール、対話、ジョーク -- を一回のLLM呼び出しで。LLMは思考の速さで内部的にシミュレートする。シリアライズのオーバーヘッドなし。文脈を壊す往復なし。@jakkos、@PaulHoule: nushellとPythonはいいけど、まだパーサーのための構文を書いてるよね。もし理解者のために意図を書いたらどうなる？ Bashは悲劇だ -- フットガンの引用、jqの体操、書き込み専用の構文。俺たちのパターン: YAMLで意図を書いて、必要なときにLLMが「クリーンなPython」に引き上げる。Postelの法則を型システムとして: 受け入れるものに対して寛容であること。意味的理解はナンセンスをキャッチする。なぜなら、あなたが「意味した」ことを知っているからであって、ただ「タイプした」ことだけではないから。証明と哲学: https://github.com/SimHacker/moollm/blob/main/designs/stanza...

└

PowerShellを考えたことある？オープンソースで、型付きだし、コマンドラインからも使えるし、リソースもたくさんあるよ。 https://github.com/PowerShell/PowerShell

うーん、そうかもね。成熟した言語やエコシステムは成熟してるから、新しい機能を無理やり入れなきゃいけないんだよね。一方でRaku（https://raku.org）は、引用、正規表現、PEGなどのサブ言語（スラング）の編み込みとして意図的に設計されてるから、自分のスラングを簡単に作れるんだ。例えば、https://raku.land/zef:lizmat/Slangifyを使えば、一般的なプログラミング言語の中でDSLをドロップダウン言語として使えるようになるよ。

Hacker Newsで議論の続きを見る