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

 (lbstanza.org)
1 ポイント 投稿者 GN⁺ 2026-01-09 | 1件のコメント | WhatsAppで共有
  • プログラミング生産性の核心は、言語そのものよりも豊かなライブラリエコシステムにある
  • Ruby on Rails のように、言語の高度な機能を活用したフレームワークは非専門家にも高い生産性を提供する
  • しかし、言語の構造的な限界のため、Rails レベルのフレームワークを Java や C で実装するのは難しい
  • 言語設計は、書けるライブラリの形と複雑さを直接決定し、これこそが言語発展の本質的な目的である
  • Stanza 言語はこの観点から、強力で使いやすいライブラリ生成を可能にする言語設計の重要性を示している

プログラミング言語とライブラリの関係

  • ほとんどのプログラミング言語は、変数、配列、ループ、関数など似た基本要素を持つ
    • 一部の言語は第一級関数やコルーチンのような高度な機能を提供するが、非専門家はそれらをうまく使いこなさない
  • 多くの開発者にとって生産性を高める要因は、言語よりもライブラリである
    • たとえば Ruby on Rails は、データベースベースの Web アプリケーションを容易に構築できるようにする
    • Rails のおかげで、Ruby 言語自体よりもフレームワークへの選好が強くなる

Ruby on Rails と言語機能の相互作用

  • Rails は Ruby のメタプログラミング、実行時評価、第一級関数、ガベージコレクションなど多様な機能を活用している
    • 例: ActiveRecords はメタプログラミングを、テンプレートシステムは実行時評価を使う
    • イベント処理は、第一級関数をコールバックとして渡す方式で実装される
  • Java や C ではこうした機能が不足しており、Rails レベルのフレームワーク実装は不可能である
    • Java のメタプログラミングは、ActiveRecords を実装できるほど強力ではない
  • したがって Rails は Ruby 言語の構造のおかげで可能であり、言語設計がライブラリの可能性を決める

言語設計がライブラリの形を決める

  • C 言語は関数宣言と呼び出しだけで再利用を支援するため、ほとんどの C ライブラリは関数群の形をとる
  • Ruby は第一級関数をサポートしており、「ボタンがクリックされたときに実行する動作」を簡潔に表現できる
    • 一方 Java ではハンドラクラスを定義しなければならず、コードが複雑になる
  • 言語の表現力は、ライブラリの構造と使いやすさを直接規定する

対話型ソフトウェアと拡張可能なフレームワークの登場

  • 1970年代のバッチ型コンピューティングでは、関数中心のライブラリで十分だった
  • 現代の対話型ソフトウェアでは、拡張可能なライブラリが必要になる
    • GUI やイベントベースのシステムでは、「ユーザーがクリックしたときに自分のコードを実行する」という構造が求められる
  • Java と C++ は継承とメソッドオーバーライドによって拡張を支援し、こうした構造がフレームワークへと発展した

Stanza 設計の背景と言語の限界

  • Stanza の設計動機は、Java で使いやすいゲームプログラミングライブラリを書く難しさから出発している
    • Java では並行性を状態機械（state machine）として表現しなければならなかった
    • Scheme はcontinuationをサポートしており、より直感的な実装が可能である
  • しかし Scheme は静的型検査をサポートしていないため、デバッグ効率が低い
    • 現在ほとんどの言語では、型システムをライブラリとして拡張できない
  • Stanza は選択的型システム、ガベージコレクション、マルチメソッドベースのオブジェクトシステムを提供する
    • ただし、ユーザー定義のオブジェクトシステムを新たに書くことはできない

言語の目的と研究の方向性

  • 汎用プログラミング言語の目的は、強力で使いやすいライブラリ生成を支援することである
    • 言語が強力であるほど、ライブラリの利用は簡潔になる
  • コードは、よく設計されたライブラリを使っているとき、同僚に指示する文章のように読める自然さを持つ
  • Racket、Shen、メタオブジェクトプロトコル研究などは、拡張可能な型・オブジェクトシステムを探究している
  • 究極的には言語は、「どのライブラリを使えて、どのライブラリを使えないか」によって区別される
  • 洗練されたライブラリの背後には、数十年にわたる言語研究と設計の努力が存在する

関連記事

1件のコメント

 
GN⁺ 2026-01-09
Hacker Newsの意見

  • 最も良い例は Prolog だと思う。一般には論理プログラミングの代表的な言語と呼ばれるが、実際には複数の アルゴリズムの集合 にすぎず、各言語のライブラリとして実装できる。Prolog の構文的表現だけを各言語の文法に合わせて提供すれば十分だと思う

    • Prolog の核心はアルゴリズムではなく、論理規則を宣言的に表現 する方法にある。たとえば「祖父母は親の親である」という規則を定義すれば、それによって祖父母を見つけたり、逆に親子関係を推論したりもできる。こうした 双方向推論 が Prolog の魅力だ。もちろん一般的な言語でこうした機能を真似しようとするなら、副作用のないコードと制限された DSL が必要になる。PyTorch や TensorFlow で Python から CUDA を動かすように、言語間呼び出しも可能なので、言語に依存しない構造も十分に可能だと思う
    • Prolog の構文は 一階述語論理 (First Order Logic) の部分集合で、変数には値が代入されず、可能な値の集合の上で条件を満たすまで探索する。Prolog エンジンは単なるライブラリ呼び出し以上のことを行う。たとえば 探索空間の圧縮表現、並列実行、自動枝刈りなどがある。だから通常は Prolog をバックエンドサービスとして置くか、コード生成方式で統合する。Prolog は 計画立案、制約解決、定理証明、組合せテスト、価格モデリング などで特に強力だ。だから Prolog を単に「ライブラリで十分な言語」と見るのは無理があると思う
    • 同じ理屈で言えば、オブジェクト指向機能もクロージャで真似できるので、言語にわざわざ必要ないと言うこともできる。だが 明確な構文がもたらす表現力 には利点がある
    • Prolog のような関係プログラミングをライブラリとして実装するには、言語が シンボルと変数操作を第一級オブジェクトとしてサポート している必要がある。Lisp 系言語ならまだ可能だが、一般的な言語では使い勝手が大きく落ちる。Bob Harper と話したとき、彼は「そのまま新しい言語を作れ」と言っていたが、その言葉にはかなり説得力があった
    • Prolog を学びたいのだが、入門チュートリアルと高度な例の間にある 中級レベルの資料 を見つけるのが難しい。Sudoku の変形パズルを Prolog で解いてみようとしているが、既存の例は最適化されすぎていて、一般化された関係定義を学びにくい。特に、一部の規則が間違っている可能性がある状況をどうモデル化するかが気になっている。参考までに SWI-Prolog の Sudoku 例 を見ている

  • 10年前は Scala のファンだった。型システムの中で DSL を作れるという「Scalable Language」の概念が魅力的だった。だがコミュニティが JVM 上の Haskell のように使い始めてから興味を失った。最近は WASM や Graal のような技術が言語選択の柔軟性を高めてくれそうで期待している。多くの場合は JS で十分だが、必要なときに Rust のような低水準言語を使える選択肢ができたのは良いことだ

    • 自分も Scala の最大の問題は DSL の乱用 だと思う。言語そのものだけでなく、テストフレームワークなどでも別の言語をまた学ばなければならない感じだ。もちろん Hadoop MapReduce を1行で表現できるのは印象的だったが、ほとんどの業務にはやりすぎだ。しかも Scala 開発者は「退屈なコード」を書きたがらない。格好をつけた結果、保守地獄だけを残して去っていくケースを何度も見た
    • Scala コミュニティ全体が Haskell 志向というわけではない。そういう傾向を見せるのは一部の 型魔術師 だけだ。Scala は単に「より良い Java」として使っても十分に優れている。関数型の利点を大きな負担なく享受できる
    • Haskell はもともと DSL 制作用の言語 としてよく使われる。Meta の Haxl や音楽用 DSL である TidalCycles が良い例だ。ただし高階型ベースのライブラリは性能低下が大きく、不必要に複雑だ
    • Clojure(Script) を使ったことはあるだろうか。Lisp 系らしく、問題に合わせて言語を拡張する bottom-up プログラミング が可能だ。Paul Graham の On Lisp でもこうしたアプローチが強調されている。関連講演の Bottom Up vs Top Down Design in Clojure もおすすめだ
    • 自分は最近 Scala を学び始めたが、関数型プログラミング の面でも本当に気に入っている。DSL 作成以外にも多様な使い方ができるほど汎用的だと思う。Scala に何か不足を感じる点があるのか気になる

  • 型付きスクリプト言語 で bash を置き換えられたらいいと思う。Elixir で簡単な JSON パーサースクリプトを作ってみたが、かなり良かった

    • Nushell を使ったことはあるだろうか。以前なら「本物の言語」を使う必要があった作業を1行で処理できる。たとえばファイル一覧を並べ替えて JSON で出力するパイプラインを簡単に書ける
    • 実際、shebang を使えば複数の言語でスクリプトを書ける。たとえば C#、Java、Go でも可能だ。Scriptisto を使えば、ほぼすべての言語で shebang スクリプトを作れる
    • OCaml もスクリプトのように使える。#!/usr/bin/env ocaml でそのまま実行できる。ただし単一ファイルで外部依存関係を自動インストールする機能はない
    • Go にも shebang を真似る トリック がある。関連する議論は こちら を参照
    • 日常的なスクリプティングなら Python や PowerShell も良い選択肢だ

  • 言語とライブラリは 互いに排他的ではない。あるライブラリは事実上言語のように機能し、逆に言語が特定のライブラリのために設計されることもある。たとえば Julia は性能と使いやすさのバランスをうまく取った例だ。高性能コードを Julia で直接書けて、JIT レベルの型特化コンパイル によって最適化された実行を得られる。関数呼び出しモデル自体は単純だが、内部では非常に精巧に動作している

    • その通りで、結局のところ 言語とライブラリの両方が必要 だというのが核心だった

  • Raku は複数のサブ言語 (slang) を束ねた構造として設計されている。たとえば正規表現、PEG、quoting などをそれぞれのミニ言語として扱い、Slangify を使って独自の DSL を簡単に追加できる

    • ただ個人的には 型が変数名の後ろに来る文法 が好きではないので、Raku は好みではない

  • 以前、あるシニア開発者が「履歴書に Rails が見えたら即捨てる」と言っていた。言語で人を評価するのが どれほど愚かなことか を改めて感じた

    • Rails の台頭と J2EE の衰退 が同時に起きたのは偶然ではない。Rails はシンプルで意見の明確なバックエンドコードを示し、その影響で DropWizard、Javalin、Spring Boot のような Java フレームワークが登場した
    • そのシニアの技術スタックが気になる
    • そんな同僚のゴミ箱なら自分が回収したいくらいだ。優秀な Rails 開発者は見つけにくい。自分も RoR の経験 があり、今でも好きだ
    • もちろん Java 開発者を探す立場なら、Rails の履歴書をふるい落とすのが効率的かもしれない
    • 人を評価する基準は結局、組織とのカルチャーフィット と 協業スタイル に左右される。完璧なフィルタリング方法はない

  • 言語やライブラリは結局、機械と人の両方とのコミュニケーション手段 だ。機械とはビットと電圧で、人とは 意図と概念 でコミュニケーションする。したがって言語やライブラリが人にとって明確で素早い表現手段を提供するなら、それが言語かライブラリかは重要ではない。Rails であれ Stanza であれ、目的に合っていてチームが理解しやすければそれが正解だ

  • 自分は「ライブラリこそが最終言語」だと思う。たとえば Ruby on Rails は Ruby を基盤にした優れた Web サービス言語だ。Ruby と Rails は互いのために進化してきた。結局 プログラミングは言語の連続的な翻訳過程 なのだと思う

    • C# と ASP.NET Core も同じように共に発展してきた。ユーザーフレンドリーな構文とシステムレベルの最適化が同時に進んだ

  • 「言語が強力であるほどライブラリを使いやすくなる」というのはその通りだ。昔の Java では Express のようなフレームワークを作るのは難しかった

    • Express が何かは知らないが、Java は ライブラリの活用しやすさ のおかげでエンタープライズ言語として定着したのだと思う
    • C# の ASP.NET Core minimal API は Express をほぼそのまま実現した例だ。言語とフレームワークが一緒に進化してこそ可能になる
    • Java にも Javalin のような Express 類似フレームワークがある。問題は コミュニティが単純さを求めていない ことだ

  • C 言語向けの Web フレームワークなら PHP があるじゃないか？ ;)

    • それは ライブラリという概念を広げすぎた冗談 のようだ