コンピューターサイエンスとソフトウェア開発の歴史的逸話

コンピューターサイエンスやソフトウェア開発の歴史には、数え切れないほどの逸話が散在しています。大規模言語モデル（LLM） を用いてリスト化し、リンクの精査と不正確な情報の修正を行いました。多くの話は昔から知っていましたが、初めて知ったものも含まれています。

注意点: リンクの大半はウィキペディア等へのものです。「低品質コンテンツ」のようなサイトは含めません。

使用プロンプトの意図:

• トニー・ホイヤー氏の「null 参照は『10 億ドルの過ち』である」という発言を起点に。
• プログラミングやソフトウェア設計に関する魅力的な逸話（ポジティブ・ネガティブ双方）を収集。

※リストの前半は**「コンピュータの不具合・バグ」が中心ですが、後半ほど概念への言及が減る傾向があります。 マイクロソフトのレイモンド・チェン氏による『The Old New Thing』** や書籍、そしてジョエル・スポルスキー氏の**『Joel on Software』** も、逸話と指針が満載した古典的な情報源です。

---

インシデントとバグ

致命的な事故と損失

• トニー・ホイヤー氏の「10 億ドルの過ち」：null 参照の考案による影響。
• アリアン5号ロケット（フライト 501）：再利用された整数変換オーバーフローが原因で発射直後に爆発。
• マーズ・クライメート・オービタ：メートルとフィートの単位混同により宇宙船を失い、3 機も破壊された悲劇。
• セラック 25（Therac-25）：競合条件と安全設計の不備から、致死量の放射線被曝を引き起こした事故。
• ナイトキャピタルのデプロイ失敗：不良なデプロイにより、45 分間で約4.4 億ドルの損失。
• パトリオットミサイル：蓄積した浮動小数点数誤差によるタイミングエラー。28 人の死者を出した。
  • ※関連：ウィキペディアの「致死性自律兵器」ページも参照。
• ペンティアム FDIV バグ：極めて小さなルックアップテーブルエラーで除算結果が不正確に計算され、史上初のフルリコール。損失は4.75 億ドル。
• ハートビッド（Heartbleed）：ボーダーチェックの欠如により、サーバーの任意のメモリ領域が暴露された脆弱性。
• AT&T 1990 年の大停電：一部の復旧経路での障害により、電話交換機ネットワーク全体が大混乱を招いた。
  • ※関連：Software bugs のウィキペディア記事も興味深い。
• GitLab 2017 年データベース消去事件：管理者がリカバリー中に誤って本番環境データを削除した事故。

大規模なシステム障害

• モーリスワーム：自己複製ソフトウェアの実験が、意図せず初期インターネットの多くを停止させる悲劇に終わった。
• クラウドフラアの 2019 年 regex 停止事故：カタストロフィック・バックトラックによりネットワーク全体の CPU が消費され、サービス停止。
• left-pad：npm パッケージ（11 行）の削除により、一時的に JavaScript エコシステムの多くが機能停止した。
• Log4Shell：便利なログ記録機能が、遠隔コード実行（RCE）の脆弱性へと転化した。
• The DAO ハック：ソフトウェアの振る舞いが人間の意図を上回り、イーサリアムを争议的なフォークに追い込んだ事件。

奇妙な挙動と互換性問題

• Excel の 1900 年リープ年バグ：Lotus 1-2-3 との互換性を保つため、意図的に保存された不正確な挙動。
• Excel の遺伝子名改ざん：自動的な日付変換処理が、科学的データの整合性を長年崩壊させた事例。

---

デザインパターンと概念

言語とアーキテクチャの影響

• UNIX パイプ：ダグ・マキロイ氏の**「組み合わせ可能性（composability）」**の着想は、コンピューティング史上最も持続的なデザインパターン。「UNIX 哲学」として知られる。
  • 関連：すべてはファイルであるという簡潔な抽象化が、ツール間の連携土台となった。
• C 言語の gets()：本質的に不安全と見なされ、やがて言語標準から削除された API。
• Java の Checked Exceptions：意図的な安全機能だが、長年にわたり議論が続いてきたデザイントピック。
• JavaScript の 10 日間の開発：ブレンドン・アイヒ氏の急ピッチ実装により、数十年間にわたるウェブの挙動（クイアーク）に影響を残した。
  • 関連：**ブラウザの「クイアークズ モード」**は、過去のバグを維持することで互換性を確保している例。

プログラミング言語の歴史

• C++ の「ゼロオーバーヘッド原理」：抽象化を適用しても、手書きの下位コードのコストと同等のコストしか発生させない原則。
• Rust の所有権チェッカー：メモリ安全性の制約を型システムに組み込み、システムプログラミングの前提を挑戦。
• Lisp ゴバルジコレクション：一度は革新的だった自動メモリ管理技術が、数十年を経て主流になった。
• Algol 60 リポート：異常に詳細な言語仕様が、後のプログラミング言語設計に影響を与えた。

哲学的概念

• Smalltalk の「メッセージ送付」：オブジェクト指向はクラスや継承という概念より、深い思想から生まれたものである。
• アポロ宇宙シャトルのソフトウェア：極めて保守的・堅牢な工法により、異常に低い欠陥率を実現（83 ページのドキュメント『The Legacy of Space Shuttle Flight Software』存在）。

---

原則とルール

開発哲学

• 「GOTO は有害である」：デイキストラ氏の短い手紙が、構造化プログラミング革命の火付け役。
• Erlang の「let it crash」：全ての故障を防ぐのではなく、設計自体に**「失敗を前提とした回復力（フォルトトレラント）」**を組み込むアプローチ。
• 「悪い方がマシ」：リチャード・ギャビエル氏が提唱。「実装の簡潔さ」が「理論的な完璧さ」よりも優れるとする議論。（※『UNIX-HATERS Handbook』へのリンクあり）
• セカンド・システム・エフェクト：成功したエンジニアほど、次のプロジェクトを過剰に設計する傾向がある。
• 神話的なマン・モンチ（The Mythical Man-Month）：遅れているプロジェクトに人を増やすと、より遅れるというパラドックス。

組織と法則

• SQLite のテスト文化：異常に徹底的なテストシステムが、信頼性の評判の中心。
• ネットスケープの書き換え：ブラウザのコードをすべて書き換えた事例は、大規模リファクタリングの警告である。
• ハイラムズ法則（Hyrum's Law）：ユーザー数が増えるほど、全ての観測可能な振る舞いが誰かの依存関係になる（XKCD コミックスでも扱われる）。
• コンウェイズ法則（Conway's Law）：ソフトウェアアーキテクチャは、組織内のコミュニケーション構造を反映する傾向がある。
• ガールの法則（Gall's Law）：複雑なシステムは、単純で動作するシステムから進化するもの。
• グリーンスプンの第 10 の法則：複雑なプログラムは、しばしば Common Lisp を再発明してしまう。

ネットワークとシステム設計

• ポストルズ法則（Postel's Law）：「受け入れる側は寛容に、送るのは厳格に」という考え方は相互運用性を促進したが、後にセキュリティ懸念から批判されるようになった。（※著者はこれに絶対反対）
• TCP コンゲスチョン・コラプス：Van Jacobson 氏によるアルゴリズム登場前、インターネットは崩壊寸前だった。
• DNS（ドメインネームシステム）：中央管理型 hosts ファイルを置き換えた分散階層型システム。

分散システムの基礎理論

• Amazon の Dynamo：「最終一貫性」を受け入れる考え方が、現代の分散データベース設計の人気向上に寄与。
• Google の MapReduce：シンプルなモデルが、膨大な規模の分散計算を扱いやすくした。
• Leslie Lamport 氏の Paxos：合意形成アルゴリズムだが、読解が極めて困難なことで知られる。
• Raft：Paxos よりも合意形成を理解しやすくするために明示的に設計されたアルゴリズム。
• バイザンチンの将軍問題：思考実験から派生した概念が、フォルトトレラント分散システムの基礎。
• CAP 定理：多くのデータベース設計で扱われていたトレードオフを、形式的に定式化した。

エンジニアリングのケーススタディ

• DOOM のソースコード：緊密で実用的なエンジニアリングが、ゲームシステムアーキテクチャの古典的教材。（※CoRecursive ポッドキャスト「DOOMed to Fail」参照）
• Quake の高速逆平方根：神秘な魔法定数を用いたビットレベル最適化で、伝説的なコードとなった。

ツールの創成と進化

• Git の誕生：Linus Torvalds 氏が BitKeeper にアクセスできなくなった後、迅速に最初のバージョンを開発。
• Git の内容アドレス指定設計：オブジェクトをハッシュ値で扱うことで、分散型バージョン管理システムとして異常なほど堅牢性を実現。

代替 OS コンセプト

• Plan 9：UNIX の多くのエレガントなアイデアが再考されクリーンに整理されたが、商業的採用は限定的。

セーフティクリティカルなソフトウェア

• NASA の「パワー・テン」ルール：安全性が重要なシステムに対する極端なコーディング制限の提案。

---

歴史的課題と教訓

• Y2K プロブレム：2 桁の年号表記による簡略化が、数十年後の大規模で高価な保守作業を招いた。
  • （※「今日で 30 歳の人々は Y2K を覚えていないのか？」という感慨。）
• Y2K38 プロブレム：UNIX の 32 ビット時間表現が、別の整数を用いて同じ教訓を繰り返す問題。
• リープセカンドバグ：一見無害な時間の仮定が、何度も大規模システムを停止させる原因となった。
• Debian の OpenSSL バグ：**「未初期化」**に見えるコードを削除した結果、疑似乱数生成機能が著しく弱体化。
• Apple の goto fail バグ：重複された一行のコードが、TLS 証明書検証をバイパスする重大な脆弱性を生んだ。

補足: 「Software bugs」のウィキペディア記事や**『The Old New Thing』、『Joel on Software』** も深く掘り下げるのに価値があります。