ハクソク

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

アダ、デザイン、そして言語を築いた言語

10時間前原文(www.iqiipi.com)

概要

  • Adaは、DoD（アメリカ国防総省）が設計し、現代の多くの言語が追随した特徴を持つシステム言語。
  • パッケージ構造や型安全性、並行処理など、後発言語が模倣する設計を先取り。
  • 業界からは冗長・時代遅れと評されるが、その安全性や堅牢性が今再評価されている。
  • DoDの調達危機を背景に、400以上のバラバラな言語運用を統合するために誕生。
  • インターフェースと実装の分離、厳密な型検査などを仕様レベルで強制。

Ada：静かな巨人 ― DoDが生んだ言語、その真価と現代への影響

  • Adaは、ジェネリクスを標準機能として搭載した初の広範囲システム言語。
  • パッケージ（仕様と本体の分離）、並行処理、厳密な型安全性を言語仕様で義務付け。
  • インターフェースと実装の強制的な分離により、設計の明確化と保守性向上を実現。
  • 範囲制約型、判別共用体、タスク通信モデルなど、現代言語が後追いする機能を数十年前に実装。
  • Rust、Python、C#などの進化は、Adaの設計思想に収束している現象。
  • 業界からは冗長・難解・時代遅れと評されがちだが、実は現代言語が求める安全性・堅牢性を最初から実現。
  • 航空機やアビオニクスの主要ソフトウェアで今も現役、1983年以来4回の標準改訂。
  • コンパイラが厳密な合法性・可視性・型・安全性検査を強制、曖昧さを許さない設計。
  • **「ノーと言う言語」**としての評判、しかし今やその設計思想が再評価。

Ada誕生の背景 ― DoDの調達危機と要件定義

  • 1970年代初頭、DoDは武器・物流・指揮系統で450以上の異なる言語・方言を運用。
  • 各言語は特定のベンダーや時代に紐付き、相互運用性・保守性が壊滅的。
  • 既存言語（COBOL、Fortran、PL/1）は要件を満たせず、新言語策定へ。
  • 5年かけて要求仕様文書（Strawman～Steelman）を段階的に精緻化。
  • Steelman（1978年）は、現場の失敗を踏まえた必須要件を列挙。
    • 明示的なインターフェース・実装分離
    • 強力な静的型付け
    • 組み込みの並行タスク管理
    • 一貫した例外処理
    • マシン非依存性
    • 他者が読める可読性
    • プログラム検証容易性
  • 要件は理想論でなく、実際の失敗事例から導出された現実的要求。

Adaの設計とパッケージシステム ― 他言語との違い

  • Adaの中心は「パッケージ」：仕様（インターフェース）と本体（実装）の物理的分離。
  • 仕様は契約であり、公開する型・手続き・定数などを宣言。
  • 本体は実装であり、仕様に基づきコードを提供。
  • クライアントコードは仕様のみ参照可能、本体は不可視。
  • この分離はスタイル推奨でなく、言語仕様で強制される構造的特性。
  • JavaのパッケージやPythonのモジュール、Cのヘッダファイル、GoやRustの可視性修飾子もAdaの完全な分離には及ばない。
  • Adaの「private型」：名前だけ可視で、実装は完全に不透明。
    • クライアントは型名で変数宣言や関数呼び出し可能だが、内部構造は一切見えない。
    • 実装の詳細（レコードか配列か整数か等）は全く分からない。
    • パッケージ設計者のみが操作メソッドを仕様に公開できる。
  • JavaやC#のアクセス修飾子との違い：実装の「存在」自体がクライアントから見えない。
  • C#やJavaも長い年月をかけて真のカプセル化（record型など）へ進化中。
  • オブジェクト指向言語の進化は、Adaのパッケージシステムへの回帰の歴史。

Adaの型システム ― 意味を型で表現する設計

  • Adaの型システムは、型（Type）とサブ型（Subtype）の数学的概念を採用。
    • オブジェクト指向の継承型でなく、値集合の制約としてのサブ型。
  • 例：「type Age is range 0 .. 150」――年齢型を範囲指定で定義。
    • この型は0～150の値のみ許容し、他の整数型とは別物。
    • 計算時は範囲外を自動でランタイムチェック（明示的に外せる）。
    • 意味の異なる整数型（年齢と西暦など）を型で区別、誤用をコンパイル時に防止。
  • CやFortran、Pascalなど従来言語では意味を型で表現できず、コメントや運用頼み。
  • Adaの範囲型、列挙型、固定小数点型は、意味を型システムに直接埋め込める。
  • Rustのu8やi32なども型安全性を高めるが、Adaの意味的制約には及ばない。

Adaの現代的意義 ― 静かに進化し続ける安全性

  • Adaは業界の流行やコミュニティ文化とは無縁だが、航空宇宙・防衛分野で今も現役。
  • 設計思想や安全性は、現代のプログラミング言語設計の「静かな基準」。
  • 「安全性」「明確な契約」「厳密な型」「実装の隠蔽」――これらを最初から持つ言語。
  • 現代の多くの言語が、Adaが示した道を数十年遅れて追いかけている現状。

Hackerたちの意見

このウェブサイトのメインページから: 「これはポジションではなく、提案です。主題を評価するための構造であり、それについての判決ではありません。」サイト全体がAIによって書かれています。
└
それがそのサイトがAIによって書かれた証拠になるの？
Twitterアカウントは2026年4月のものです: https://xcancel.com/Iqiipi_Essays 公に名前のある著者はいません。こんな短期間での生産性は本当に驚異的で、著者はクレジットを一切取らないというのも素晴らしいですね。
└
著者がいないのは、ボットだからです。
これがAIの文章であってほしくないな、だって楽しんだから。でも他のコメントでも指摘されてるように、（リンクされたTwitterアカウントによると）出版のペースがすごく早いんだよね。判断できないのが心配。
└
>そのリンクされたTwitterアカウントによると、発表のペースがすごく早いね。俺はこの3年間でほぼ50本のブログ記事を書いたけど、全部ドラフトのまま。主に、自己不信と批判への恐れが原因で公開できなかったんだ。でも時々、自信満々で目が覚めて「今日は公開するぞ、気にしない！」って思うんだけど、結局実現しないんだよね。もしかしたら、この著者も1ヶ月前までは同じような感じだったのかも。高確率でボットかもしれないけど、もしそうじゃなかったら、自分の考えを世の中に見せることへの恐れを克服するのがどれだけ大変か、理解できるよ。英語が第一言語じゃないのも明らかだし、文法チェックやスタイル改善のためにLLMを使ってる。もしかしたら、俺の投稿は今やチャットGPT臭がするかもしれなくて、それがまた無視される恐れを増してるんだ。
└
それって本当に重要なの？AIがこんなクオリティのエッセイを作れるなら、もう尊敬するし、時間を奪ってくれてもいいよ。
└
判断を保とうとしてるけど、110個のエムダッシュは…多すぎるよね。エッセイ自体はすごく楽しめたけど、コメントを読み始めてからチェックしたんだ。ブログ記事に対してメディアリテラシーの免疫ができつつあるのが嫌だな。
└
一番気になったのは、実際にはあまり簡潔じゃなくて、ちょっと愚痴っぽかったこと。でも、ぱっと見ではAIかどうかわからなかったな。
└
ちょっと怪しい感じがするね。今は他人のブログを別の言葉で書き換えるAIツールが存在するからね。そういうのは、広告収入のためのブログに関するRedditのサブで大人気だよ…
Adaは無視されてたのも、典型的なコンパイラが数万ドルもかかってたからだよ。人気のある言語が無料で手に入る時代に、オープンソースや無料のコンパイラは存在しなかった。これが一番大きな要因だと思う。
└
Adaがニッチから抜け出せなかったのは過剰に決定づけられている。言語の洗練さや当時のコンパイラ技術を考えると、1980年代のマイクロコンピュータでAdaがうまく動くわけがなかった。Intelはi432という「チップ上のメインフレーム」を作り、パフォーマンスのためにいくつかのAdaの概念をハードウェアに組み込んだが、それでも遅かった。そして今わかっているように、マイクロコンピュータは後に世界を飲み込み、Cやアセンブリの遺産を20年近く引きずって、ようやく十分な速さになり、コンパイラ技術が良くなったことで、よりリッチな言語が現実的になった。
└
これだ。無料には敵わないよ。
└
それは大きな要因だね。俺は何年もADAを使ってたけど、周りの人たちが他の言語で趣味のプロジェクトをやってるのを見て、余計に辛かった。みんなADAが好きだったけど、文字列処理がイマイチで、それが大きな問題だった。しかも、その頃は遅かったし（コードベースにはCとADAがあった）。OSを使わない並行処理があったけど、それを使うところは大変だった。HPUXにはすごい準リアルタイム拡張があったから、たくさんのプロセスを動かしてたよ。
└
GNU ADAコンパイラは1995年に初めてリリースされたよ： https://en.wikipedia.org/wiki/GNAT
└
GNATは少なくとも90年代中頃から存在していて、その時期にはたくさんの企業が非OSSコンパイラを使ってたんだ。その頃、Adaの最大の障害は、一般的に役に立つとは見なされていない（安全性の保証など）ためにオーバーヘッドが多いと見られていたことだった。軍事関連の仕事をしている場合にしか重要じゃないっていう評判があったね。
└
1990年代のOpenVMS用のADAコンパイラは20万ドル以上だったよ。
└
Rustが登場した時、面白いなと思ったんだけど、もしかしたら記憶違いかもしれないけど、最初にAdaを深く掘り下げた時、Adaは私たちの初めての「Rust」みたいな言語だった気がする。DelphiやPascalもRustの前にメインストリームになった唯一の近い存在かもね。
└
そうだね、当時のコンパイラの状態は本当にひどかった。80年代にはGCCが唯一の本格的なフリーコンパイラだったけど、実際に使えるようになったのは80年代後半になってからだった。どの言語を選んでも、コンパイラには（かなりの）お金を払わなきゃいけなかったし、新しい言語をターゲットにすると、コンパイラは確実にひどかった。90年代後半には、ジェイミー・ザウィンスキーがC++に対して文句を言ってたしね。彼がC++を使わない理由は？「コンパイラがひどいから！」C++はAdaの主な「競争相手」だったけど、そのほとんどの期間、Adaに対して10年遅れだった。C++がAdaに対抗する「キラーフィーチャー」は、C++のコードを書いているふりをしながら、実際にはCにクラスを加えたものを書いているだけだったってこと。もしAdaがモジュラやパスカルの互換モードを言語に組み込んで、そういう言語の安定したコンパイラに基づいたリファレンスコンパイラを作っていたら、歴史は違っていたかもしれない。人々はコンパイラが追いつくのを待ちながら「PascAda」を書いていたかもしれないからね。
└
ADAを実装するために設計されたCPUもひどい失敗をしたんだよね：iAPX 432。 https://en.wikipedia.org/wiki/Intel_iAPX_432
└
他の問題も考えると、あまり意味がなかったかもしれないけど、実験すらできなかったのは確かだね。1980年代にあのハードウェアでAdaをコンパイルしたくはなかったな。全てのチェックを考えると、コンパイラはすごく遅かったはずだし（1980年代のハードウェアでRustをコンパイルすることを想像してみて）。
記事全体は好きだけど、「言語Xはそれを持っていなかった」というフレーズが最初の10回くらいでかなりうんざりする。具体的なコード例があればいいのに。どう素晴らしいかを教えるだけじゃなくて、実際に見せてほしい。並べて比較してみてよ！
└
逆に同じこともできるよ。最初の段落に挙げられた機能の多くは、他の言語に以前から存在してたけど、たぶん全部が一つの言語にあったわけじゃない。実際、設計プロセスは（理にかなって）既存の言語のベストプラクティスを重視して、新しくて未検証のメカニズムを完全に取り入れることはなかったと思う。だから、PASCAL、CLU、MODULA(-2)、CSPからかなり借用してるんだ。数値の機械表現を指定するための複雑なシステムは本当に新しかったかもしれないけど、それがどれだけ成功したのかはわからないな。
└
ADAの開発者は、何十年もそのパターンにうんざりしてるだろうから、その経験を表現したように読めるね。
└
Claudeに言語を理解するためのデモコードを頼んだら、いい感じに作ってくれたよ。未実現のFOMOを感じさせるような素敵なものがいくつかあった。もちろん、Adaのことは何十年も知ってたけど、実際に使うことはなかったんだ。
└
これは「Adaが他のすべてより優れている」っていう内容じゃないよ。著者は、Adaが安全性や信頼性の目標をどう達成したかを説明していて、あなたの好きな言語がそれを独自に進化させたのはずっと後のことなんだ。だから、比較のために到着年を何度も持ち出してたんだと思う。例があれば嬉しいけど、著者はチュートリアルを書くつもりはなかったみたい。特定のポイントを伝えたかったから、非常に情報量が多くて簡潔な記事になったんだ。読みやすさも、高い規律を持った著者のおかげだね。
アメリカ空軍はADAを使うつもりだったけど、開発に時間がかかりすぎたからJOVIALを使わざるを得なかったんだ。JOVIALを知ってる人は少ないけど、今でもUSAFにはレガシーとして残ってる。1981年にプログラマーとしての最初のプロジェクトでJOVIALを使ったけど、そこには完全なJOVIALコンパイラがなかったんだ（他の場所にはあったけど）。ADAが未来だって話があったけど、その時点ではまだ不完全な仕様だったんだよね。
└
JOVIALは、独自の軍事プログラミング言語を設計する最初の取り組みが始まる10年以上前から、アメリカ空軍で使われていた。JOVIALはIAL（1958年12月）の派生で、ALGOL 60の前身なんだ。でも、JOVIALはALGOL 60の最終版（1960年5月）より前に定義されていたから、IALとALGOL 60の間で起こった変更の一部を取り入れていなかった。ADAの開発のタイムラインは、国防総省の匿名の職員によって elaboratedされた、競合するプログラミング言語設計が満たさなければならない要件を含む、ますます具体的な文書によって特徴づけられている。1975年4月：STRAWMAN要件 1975年8月：WOODENMAN要件 1976年1月：TINMAN要件 1977年1月：IRONMAN要件 1977年7月：IRONMAN要件（改訂版） 1978年6月：STEELMAN要件 1979年6月：「予備的ADAリファレンスマニュアル」（コンペに勝利した後） 1975年のSTRAWMAN要件には、アメリカ空軍が使っていて気に入っていたJOVIALから取られた機能がいくつか含まれていたから、置き換え言語もそれを引き継ぐべきだと思ってたんだ。でも、IRONMAN要件からは、JOVIALから取られた機能のいくつかが大幅に改善されたオリジナル機能に置き換えられた。たとえば、JOVIALのように指定された関数パラメータは、コンパイラによる実装に関係なくパラメータの動作を指定する要件に置き換えられた。つまり、プログラマーは「in」、「out」、「in/out」のような動作を指定し、コンパイラはどの方法がより効率的かに応じて、パラメータを値渡しや参照渡しで自由に選ぶんだ。これはCやC++、その子孫の言語でのパラメータ指定の方法に比べて大きな改善だよ。C++の最も重要な欠陥は、数十年にわたって低パフォーマンスを引き起こし、現在のC++の複雑さの多くの原因になっているのは、「out」パラメータと「in/out」パラメータを区別できないことなんだ。このミスフィーチャーが、C++に不要なものがたくさん存在する理由で、たとえば、コンストラクタが通常の関数とは異なるものとして存在し、例外以外の方法でエラーを知らせることができないこと、代入とは異なるコピーコンストラクタの存在、C++ 2011で導入された「move」セマンティクスが以前のC++のパフォーマンス問題を解決するために存在することなどがある。
記事にはこう書いてある：「JavaScriptのモジュールシステムは2015年に導入され、Adaの32年後に、インポートとエクスポートを提供するが、型の仕様がインポーターから隠されるメカニズムはない。」そして、「Adaでは、プライベート型の実装は単にアクセスできないだけでなく、クライアントの世界から文法的に存在しない。」って。何か見落としてるのかな？JavaScriptモジュールは、単にエクスポートしなければプライベート要素を宣言できるから、著者がAdaに対して言っている「単にアクセスできないだけでなく、文法的にクライアントの世界から存在しない」ということを達成してると思うんだけど。同じことが、他の言語にも当てはまると思う。記事はすごく良かったし、Adaにもずっと興味があったんだけど、Adaがインターフェースと実装をJavaScriptモジュールとは明確に違う形で分けているとは思えないな。
└
ここでTypeScriptの話をしていると仮定すると、JavaScriptにはエクスポート可能な型がないからね… JavaScriptのインスタンスは、型がエクスポートされているかどうかに関わらず、他のどのオブジェクトと同じように単なるオブジェクトで、他のモジュールはそれを受け取ったら自由に列挙したりいじったりできる。Adaでは、プライベート型のインスタンスに対する操作は、ソースモジュールが提供するものだけだよ。つまり、モジュールXがエクスポートされていない型Tの値xをモジュールYに返すと、モジュールYのコードはx.foo = 42を自由に実行できるってこと。
記事にはいくつか「変な」欠陥があると思う、特にAdaと記事自体をエッセイとして評価する私にとってはね：* 記事は、真の実装と仕様（インターフェース）の分離はAdaだけだと言っているけど、私が考える限り、JavaScriptも「プライベート」要素（ES6モジュールでエクスポートされない）を定義できるし、それを宣言したモジュール内で使えるんだよね。これがAdaに対して言われている「文法的（および意味的）分離」でないなら、記事が指摘しようとしている違いは何なの？* 同様に、Javaについても言及されていて、記事によると`private`は「継承、リフレクション、コンパイラ自身がサブクラスの互換性をチェックするときに可視化される」と書いてあるけど、私のJavaの記憶が正しければ、これは全部間違いだよ。プライベート宣言は継承に対しては見えないし、その結果コンパイラは無視したり、サブクラスで高速化できるから、互換性は同じ結果によって保証されるんだ。記事をまだ読んでいるけど、上記のポイントを発見したことで、最初に考えていたほど真剣に受け止められなくなってしまった。Adaに「見逃していた価値」を見出したいと思っていたのに、記事がそれを前面に出したいのはよくわかるけど。
私のDoD ADAプロジェクトでの仕事は、主にDoD STD 2167（1980年代中頃から後半）に焦点を当てていた。残念ながら、レビュー会議は思慮深いソフトウェア設計や分析よりもドキュメント構造に焦点を当てていた。ADAは役に立たなかったし、うまく動かすのは面倒だったし、契約機関でのADAの経験は少なかった。ウォーターフォールアプローチのせいで、プロジェクトの実装は遅くなった。 https://en.wikipedia.org/wiki/DOD-STD-2167A?wprov=sfti1
個人的には、今のAda/SPARKの本当の価値は、仕様と実装の明確な分離を強制するところだと思う。それがまさに君のLLMに必要なものなんだ。まずは.adsファイルでインターフェースや型、前提条件・後提条件を定義して、その後エージェントに.adb本体ファイルを書かせる。言語が可読性に重点を置いているから、エージェントは仕様を読み取ったり、参照したりするのに全く問題がない。コンパイラと証明ツールが、本体が仕様を実装していることを確認してくれるしね。