言語の設計哲学 — 何を最適化し、何を捨てたか

「どの言語が一番いいか」という問いには答えがありません。もっと正確に言えば、問いの立て方が間違っています。言語は機能の寄せ集めではなく、互いに反する要求の中で「何を優先するか」を決めた設計判断の束だからです。

その判断さえ掴めば、文法の細部も、標準ライブラリの品揃えも、コミュニティが何を美徳とするかも、一本の筋で説明がつきます。逆にそこを見ずに機能表だけ比べると、「なぜこの言語はこんな面倒な書き方を強いるのか」がいつまでも腑に落ちません。

対立する5つの軸

言語設計が引き裂かれるのは、望ましい性質どうしがしばしば両立しないからです。

横にスクロール

この表の左列は全部欲しいものです。しかし右列を見ると、あるものを最大化すると別のものが削れるのが分かります。速さと安全を同時に、記述の自由と読みやすさを同時に、というのは原理的に難しい。だから言語は「どれを上に置くか」を決めるしかなく、その順位付けこそが設計哲学です。

主要言語は何を選んだか

同じ「プログラミング言語」でも、優先順位はここまで違います。

表は要約です。以下、特に対照的な判断を掘り下げます。

CとGo — 「小さい言語」の正反対の理由

CもGoも「小さくて覚えることが少ない」と言われます。しかし小ささの目的が正反対です。

Cが小さいのは、ハードウェアの薄い覆いでありたいからです。書いたコードがどの機械語になるか概ね予想でき、余計な仕組みが裏で動かない。その代償として、メモリの確保と解放、境界の管理、初期化——安全に関わる一切を人間が背負います。バッファオーバーフローも解放後利用も、言語は止めてくれません。これは欠陥ではなく、「制御を渡す代わりに責任も渡す」という一貫した判断です。

Goが小さいのは、大人数が長期間、同じコードを読み書きするためです。設計者は「賢く短く書ける機能」の多くを意図的に入れませんでした。書き方の選択肢が少ないほど、他人の（そして半年後の自分の）コードが読める。エラーは例外で飛ばさず if err != nil で愚直に扱い、ジェネリクスは登場から10年以上あえて見送られました。冗長さは払うべき対価であって、避けるべき欠点ではない、というのがGoの美学です。

Rust — 「両立できない」を崩しにいった言語

先の5軸で言えば、実行速度と安全性は伝統的にトレードオフでした。速いC/C++は安全網が無く、安全なJava/C#はGC（ガベージコレクション）という実行時コストを払う。Rustはこの二択を、所有権と借用という仕組みでコンパイル時に解くという賭けに出ました。

誰がメモリを所有し、いつ解放され、どの参照がいつまで有効か——これを型システムが追跡し、データ競合や解放後利用をコンパイルの時点で弾きます。GCは要らず、実行時の速度はC++並み。その代わり、プログラマは所有権のルールに付き合い、借用検査器（borrow checker）に何度も叱られながら書きます。学習コストと記述の窮屈さが、安全と速度の両立に対して支払う値段です。何を最適化すると何を払うか、が非常に見えやすい言語です。

Python — 機械の時間より人間の時間

Pythonの一貫した優先順位は「人間が読み書きする時間 > 機械が実行する時間」です。インデントで構造を強制し、記法を一意に寄せ、標準ライブラリを厚くする。結果として、少ないコードで速く書け、他人のコードも読めます。

対価は実行速度です。基準実装のCPythonは動的な性質のため遅く、GIL（グローバルインタプリタロック）が同時に1スレッドしかバイトコードを実行させないため、素朴なマルチスレッドではCPUを使い切れません。しかしPythonが選んだ土俵——書き捨てのスクリプト、データ分析、既存のC実装への糊——では、遅さはめったに問題になりません。重い処理は結局CやRustで書かれた拡張に投げるので、Python自身の速度は律速になりにくい。「遅い」という批判は、多くの場合この言語が最適化していない軸を責めているだけです。

Haskell — 正しさを型で買う

Haskellは「プログラムが正しいことを、型と純粋さで担保する」に全振りした言語です。関数は原則として副作用を持たず（参照透過）、同じ入力なら常に同じ出力を返す。副作用すら IO という型に閉じ込めて、「この関数は外界に触る」という事実をシグネチャに明示させます。強力な型システムが、値が無いかもしれない状況を Maybe で、失敗を Either で型に載せて表現し、握りつぶしを許しません。

代わりに、とっつきにくさと性能の読みにくさを払います。遅延評価は美しい反面、いつ計算が起きるかが直感に反し、メモリの挙動を予測しづらい。学習曲線も急です。「実行時になってから初めて発覚するバグ」を、コンパイル時の制約に前倒しで潰す——その安心と引き換えに、最初の一歩の重さと実行時の予測しにくさを受け入れる、という判断です。

同じ機能への態度に、哲学は最も出る

抽象的な話は、同じ問題への対応を並べると一気に具体化します。「関数が失敗しうるとき、どう扱わせるか」を各言語がどう決めたか——ここに設計思想が凝縮されています。

同じ「失敗」に対して、Cは人を信じて任せ、Goは何も隠さず目の前に置き、例外系は正常系の流れを守るために異常系をよそへ飛ばし、Rustは型システムに見張らせて無視を許さない。どれも一貫した価値観の表れで、優劣ではありません。null（値が無いこと）の扱いも同じで、多くの言語がnullを許す一方、Haskellや近年の言語はMaybe型でそれを排除しにいきました（この判断の重さはnullは10億ドルの誤りで詳しく扱っています）。

だから、何が言えるか

設計哲学というレンズを持つと、実務の判断が変わります。

• 言語選定は「機能の多さ」ではなく「優先順位の相性」で決める。 解く問題がどの軸を要求するか（速度か、開発速度か、安全か、運用の単純さか）を先に決め、そこに順位を合わせた言語を選ぶ。万能の言語を探すのをやめると、選定は驚くほど素直になります。
• “不便”を設計判断として読む。 新しい言語で面倒に感じた点は、たいてい別の何かを守るための代償です。そこを理解すると、抗うのではなく乗りこなせるようになります。
• 同じ処理を並べて確かめる。 哲学は、実際のコードに必ず表れます。同じ処理を10言語ででは、ここで述べた資源管理や並行の思想の違いが、実際のコードとしてどう書き分けられるかを並べて見られます。この記事が“なぜ”なら、あちらは“どう”です。

まとめ

• 言語は機能の寄せ集めではなく、互いに反する要求の中で優先順位を決めた設計判断の束。実行速度・安全性・開発速度・単純さ・表現力は同時には最大化できない。
• Cは制御、Goは運用の単純さ、Rustは安全と速度の両立、Pythonは人間の時間、Haskellは型による正しさ——各言語は何かを最優先し、その裏で何かを払っている。
• 同じ機能への態度（エラーやnullの扱い）に哲学は最も濃く出る。Cは人任せ、Goは明示、例外系は分離、Rustは型で強制、Haskellは純粋に型で表現。
• 「良い言語」は無く「この問題に向く言語」があるだけ。ある言語の不便は、別の価値を守るための意図的な代償だと読むと、選定も学習も筋が通る。
• 哲学は必ずコードに表れる。“なぜ”を掴んだら、10言語の同じ処理で“どう”を確かめると、理解が定着する。