システム設計における2つの抽象化：隠蔽か削減か

システム設計における2つの抽象化：隠蔽か削減か リンクを取得 Facebook X Pinterest Email その他のアプリ - 2026年5月8日 TLA+について話すとき、私は「抽象化」を学ぶべき最も重要なこととして繰り返し言及しています。そして、それは学ぶのが最も難しいことでもあります。しかし、私を悩ませている矛盾があります。CS（コンピュータサイエンス）の学生は、すでに抽象化が得意であるはずではありませんか？OS、ネットワーキング、ソフトウェアエンジニアリングの根幹には、抽象化があるはずではありませんか？抽象データ型（ADT）は、すべてのCSカリキュラムの定番です。では、なぜ私（そして他のすべての形式手法/モデリング担当者）は、抽象化に大きなスキルギャップを見出し、それをモデリングにおけるコアで、成功を左右するスキルと見なすのでしょうか？ この認知的不協和の根源に、ついにたどり着いたと思います。同じ傘の下に混同されている「抽象化」には、2種類あります。 モジュラリティ抽象化：これは、ADT、API、レイヤードデザインなどとしてCSカリキュラムで教えられる伝統的な抽象化です。すべてカプセル化、境界線の設定、内部の隠蔽に関するものです。 モデリング抽象化：これは、私がモデリングの文脈で抽象化について話すときに話すものです。これは、数学者や物理学者が思考や推論のためのモデルを構築する際の抽象化と同じ意味合いです。目標は、関心のある特性を保持する最小限で最もエレガントな記述を見つけることです。それは、その特性の本質に直交するすべてを切り捨てることです。 この2つは、その目標において、これ以上ないほどかけ離れています！次の2つのセクションで説明しようと思います。 モジュラリティ抽象化は隠蔽します。モデリング抽象化は削減します。 モジュラリティ抽象化は、内部を隠蔽するインターフェースに関するものです。モデリング抽象化は、振る舞いに関するものであり、関心のある特性のためにシステムを最小限の振る舞いの骨子にまで削減することに関するものです。 モジュラリティ抽象化はカプセル化し、垂直な境界線を引き、下のレイヤーを隠蔽します。モデリング抽象化は横断的です：それは振る舞いの平面に沿ってシステムをスライスし、調査中の特性に絶対に関連するものだけを保持します。そして、それは「どのように」ではなく「何を」の形で保持します。このスライスは通常、システムの組織とは似ても似つかないものになります。 モジュラリティ抽象化は並行性を隠蔽します。モデリング抽象化はそれを露呈します。 モジュラリティ抽象化は、漏れを封じることに関するものです。そのため、Joel Spolskyは「すべての抽象化は漏れる」と嘆く有名な投稿をしました。[彼のリストはすべてモジュラリティ抽象化に関するものです：TCP（IPを隠蔽）、文字列ライブラリ（文字配列を隠蔽）、ファイルシステム（回転ディスクを隠蔽）、仮想メモリ/フラットアドレス空間（MMUとページングを隠蔽）、SQL（クエリプランを隠蔽）、NFS/SMB（ネットワークを隠蔽）、C++文字列クラス（char*を隠蔽）。] モジュラリティ抽象化は、インターリーブを隠蔽し、操作をアトミックであるかのように提示することを目指します。その目標はモジュールを使いやすくすることですが、その過程で並行性や効率の機会を露呈することを断念します。 これとは対照的に、モデリング抽象化は、何が漏れるべきかを特定し、それを活用することに関するものです！それは、細かいレベルのアクションと順序を露呈し、インターリーブにもかかわらず不変条件が成り立つことを証明します。この作業の報酬は、システムから最大限の安全な並行性を収穫することです。 モデリング抽象化の例 分散システム分野には、モデリング抽象化が豊富にあります。ほとんどすべてのプロトコルがこのように設計されているように感じられます。 Lamportの論理時計：ウォールクロック時間を捨て、happens-beforeを保持する ハイブリッド論理時計：ウォールクロックと因果関係を保持し、残りを捨てる TrueTime：時間を受付可能な不確実性間隔として扱う 合意：単一の決定に同意する。LamportがPaxosを設計した方法は、抽象化の傑作です。合意、投票、そして最終的なプロトコルまで。 線形化可能性（そして実際、すべての整合性モデル）：レプリケーション、キャッシング、リトライを捨てる データベースのアイデアとしてのログ：具現化された状態を真実の源として捨てる。順序付けられた、追記のみのイベントシーケンスのみを保持する。 MapReduce/Spark：オーケストレーション、並列処理、スケジューリング、耐障害性を捨てる。パーティション化されたデータに対する決定的な変換のDAGを保持し、フレームワークがその骨子から残りを再構築できるようにする。 時には、2つの定義が重複しているように見えるかもしれません（例：線形化可能性、合意、データベースとしてのログ、Map-reduce）。しかし、これは実際には重複ではなく再利用です。非常にうまく設計された成果物は、仕様として（モジュラリティ）、推論のための骨子として（モデリング）同時に機能することができます。これは、2つが1つの成果物に偶然一致したことを意味しますが、抽象化の役割は依然として明確に区別されます。 抽象化 tla リンクを取得 Facebook X Pinterest Email その他のアプリ コメント コメントを投稿する AIから最も安全な仕事は執筆かもしれない - 2026年8月31日 今日、テクノロジー界の人々は、新たに膨れ上がった5倍の生産性目標を満たすためにワークフローを変更しようと躍起になっていますが、エージェント生成コードの認知的負債に打ちのめされています。新しいモデルがリリースされるたびに、ギャップは広がり、人間はループ内のボトルネックに近づき、「コーダー」としての陳腐化に近づいています。プログラマーの職務記述書が完全に再構築されている一方で、執筆は驚くほど影響を受けていません。LLMはコード生成に非常に長けていますが、彼らが生成する散文の絶対的なひどさに愕然としています。彼らは常に同じロボットのようなリズムと決まり文句に従い、同じ使い古された語彙を散りばめています。彼らは私の壊れてはいるが魂のこもった文章を、散文を改善するという名目で、プラスチックのように魂のない言葉の泥に変えます。彼らの文章は、実際の理解や洞察を何も伝えていません。私は、私たち全員がAIの執筆に対して、本能的な嫌悪感を感じ始めていると思います。それは不気味の谷に閉じ込められており、そこに留まるかもしれません... 続きを読む >> エージェント的な自己：AIと自己改善の間の類似性 - 2026年1月2日 2025年はエージェントの年でした。AGIの目標はシフトし、私たちはAIに単に「話す」ことを求めるのではなく、「行動する」ことを要求しました。これらの新しいエージェントとエージェントシステムのアーキテクチャを外部から見ていると、奇妙なことに気づきました。AIを賢くするためのエンジニアリングのトリックは、奇妙に馴染みのあるものでした。それらはコンピュータサイエンスというよりは…自己啓発のアドバイスのように読めました。エージェント知性の秘密は、3つの非常に人間的な習慣にあるようです：物事を書き留めること、自分自身に話しかけること、そして誰か他の人のふりをすること。それらはほとんど単純すぎます。 執筆の不合理な有効性 私が博士課程の学生だった頃に受けた最も深遠なアドバイスの1つは、チューリング賞受賞者であるManuel Blum教授からでした。彼の論文「Beginning Graduate Studentへのアドバイス」の中で、彼はこう書いています：「書くことなしには、あなたは有限オートマトンに還元されます。書くことによって、あなたはチューリングマシンの驚異的な力を得ます。」複雑な議論を保持しようとすると... 続きを読む >> 分散システムについて学ぶ：どこから始めるか？ - 2020年6月10日 これは間違いなく「21日で分散システムを学ぶ」投稿ではありません。私は、原則に基づいた、基礎からの分散システムの学習を推奨します。これは最初のパスで3ヶ月近くかかり、その後、能力を構築するにはさらに数ヶ月かかります。あなたが実践的でコーディング志向であれば、私の助言はあまり好きではないかもしれません。「コーディングと実践で分散システムを学ぶべきではないか？Hadoopクラスターをデプロイしたり、Raftのコードを調べたりすることから始められないのか？」と異議を唱えるかもしれません。私はそれが分散システムを学ぶための間違った方法だと思います。なぜなら、似たようなコードやプログラミング言語の構造を見ると、それが馴染みのある領域だと考え、誤った安心感を得てしまうからです。しかし、それ以上に真実から遠いものはありません。分散システムは、中央集権型システムとは根本的に異なるソフトウェアを必要とします。—A. Tannenbaumこの引用は、私の分散システムシラバスの文字通りの最初の文です。学習... 続きを読む >> 分散システム設計のヒント - 2023年10月2日 これは、40年前にSOSP'83で「コンピュータシステム設計のヒント」という論文を発表したButler Lampson氏に敬意を表して書かれています。私はそれに匹敵すると主張するつもりはありません。