- Leslie LamportはLaTeXの初期開発者であり、分散システム分野の先駆者。2013年にチューリング賞を受賞
- 彼はSCaLE 22xのキーノートで抽象化の重要性を強調し、多くのプログラマーがコーディングと言語に没頭している一方で、コーディング前の抽象的思考と設計こそが核心だと指摘した
発表要約
- 皆さんは私が並行性（Concurrency）について話すことを期待するかもしれないが、これについて新しく言うことはない
- しかし「並行なプログラムを書くこと」への洞察は、一般的なあらゆるプログラミングにも適用される
- この発表はプログラミング全般についての話である
アルゴリズム vs. プログラム
- アルゴリズム: 言語に依存しない抽象的なアイデア。プログラムよりさらに抽象的で高水準の概念
- プログラム: アルゴリズムを特定の言語で実装した具体的な形。プログラミング言語はアルゴリズムを表現するには複雑すぎる
- アルゴリズムは実行されず、一般に短くて簡潔である
- 特に並行性に関するコードでは、まず正確なアルゴリズムを定義して実装すべき
配列の最大値の例で見る抽象化
- 単純な問題でも**「何をするのか（What）」を明確に定義**しなければならない
- 例: 「整数配列の最大値を返す」→「すべての要素以上である最小の数を返す」
- 空配列の扱いも事前に定義が必要（例:
-∞ を使う）
- このような明確な定義によって、**より単純で堅牢なアルゴリズム（How）**を導ける
プログラム実行は状態の流れ
- プログラム実行は単なる命令の並びではなく、状態（state）の連続である
- 各状態遷移はコードの一部の実行を意味する
- この視点はアルゴリズムの正しさを証明するときに重要である（不変条件の利用など）
複雑なシステムのためのツール: TLA+
- 抽象化を精密に表現するには正確な言語が必要
- TLA+はそのために設計されたツール
- Amazon Web ServicesはTLA+によって深刻な設計欠陥を事前に発見した
- Rosetta探査機のOSであるVirtuosoもTLA+ベースで設計され、コードは簡潔で安定していた
不完全な仕様における抽象化の役割
- 例: プリティプリンターでは整列基準が主観的になりうる
- それでも抽象化されたルールセットを定めておくことが、デバッグと保守に重要である
書くことと思考の関係
- 考えを文章に書き出すことが思考を明確にする
- 抽象化は単に頭の中だけで行うのではなく、文章として表現してこそ効果的
- Lamportは、自身の数学的訓練が抽象化能力を育ててくれたと述べた
- 数学者はプログラマーに抽象化を教えられる
ライブラリとバグに対する視点
- 発表第2部「なぜプログラムにはバグがあるべきなのか」では複雑性の問題を扱う
- 現代のソフトウェアは多くのライブラリに依存しているが、これらには正確で言語非依存な説明が不足している
- そのため統合の過程で予期しないバグが発生する
- 例: 自身のTLA+講座サイトでのJavaScriptデバッグ経験
- 状態ベースの視点はこうした複雑性を理解するのに有用
質疑応答で扱われたテーマ
- AIが抽象化に与える影響
- オープンソースと学術界の断絶
- 開発者が形式的定義（formal definition）を軽視しがちな現実
- 依然として最も重要なのは**「コーディング前に考えること」**
結論: プログラミングの本質は思考
- Lamportは単なるコーディングより抽象的思考と形式仕様を優先すべきだと主張する
- upfrontの努力は大きいが、結果としてより堅牢で保守しやすいソフトウェアにつながる
- コーディングはプログラミングの一部にすぎず、真のプログラミングは正確なアルゴリズムと抽象化から始まる
- システムの複雑性と並行性が増す現代では、抽象化は必須の能力であり、考え、抽象化する訓練がプログラマーには必要である
5件のコメント
私もこの記事に共感します。
抽象化された状態値で問題を定義することが、問題発見に有用だと考えていますし、ダイアグラムなどによる状態の可視化や、Unreal Blueprint やワークフローのように、視覚的かつ明示的で明確な状態管理ツールを作ろうとしているのですが、
まずは言語を先に見るべきですね
計算理論の専攻授業を思い出す文章です！プログラミングをする方には勉強してみることをおすすめします。
TLA が何なのか気になりますね。
調べてみます
私も気になって調べてみました。
TLA+ - プログラムおよび並行/分散システムをモデリングするための高度な言語
Hacker Newsの意見
デモシーンの「コーダー」たちは自らをそう呼び、それに誇りを持っている。そして彼らはしばしば優れた「プログラマー」や「ソフトウェアエンジニア」でもある。コーダー、プログラマー、ソフトウェアエンジニアなど、どんな呼び方をするにせよ、大事なのはコンピュータを意図したとおりに動かすこと
来年のキーノートは「バイブィングはコーディングではなく、プログラミングでもなく…たまに少し動くゴミのピラミッド」といった内容になりそう。Dijkstraがこれを見ずに済んでよかった。彼は80年代には両親の居間で怒っていた。「バイブコーディング」を見たらどんな反応をしたか想像もつかない
Leslie LamportのSCaLE 22xキーノート: 考え、抽象化し、そのあとでコーディングすること。Lamportは、コーディングの前に思考と抽象化を重視する、プログラミングへの根本的なアプローチの転換を唱えており、これはあらゆる自明でないコードに当てはまる
プログラミングは、慎重な設計（抽象化）のあとに実装（コーディング）が続く意図的なプロセスであるべきであり、明確な仕様と、状態の連続および不変条件を通じたプログラムの振る舞いの理解に重点を置くべきだ。考えることは常により良い
数学の教授は、概念をより正確で機械可読な形に変換するあらゆる行為をコーディングと呼ぶ。これは、プログラミング言語でコンピュータにしてほしいことを書くことだけでなく、データをエンコードすることも含む。「encode」という単語がそれを明確にしている。二分木を自然数に変換するコーディング方式を定義する課題が出された。コーディングという言葉は曖昧すぎるので、あまり使わない
Lamportは「何を」と「どのように」を分離すべきだと主張する。しかし、たいていの問題ではプログラムの「何を」と「どのように」はある程度結びついているのではないかとも思う。たとえば性能上の考慮は「何を」の一部なのか、それとも「どのように」の一部なのか?
興味深い要約: アルゴリズムはプログラムではなく、プログラミング言語で書かれるべきでもなく、単純であるべきだ。一方でプログラムは、潜在的に大規模なデータセット上で高速に動作しなければならないため、複雑にならざるを得ない。特に、複数CPU上で動作する並行プログラムでは実行順序が異なるため、この点が議論される
コーディング前に思考を要するコード、そしてコードを読みたくない人が使うコードとしてプログラムを定義している。この講演はずっと以前から行われてきた。最小の項目を見つけることを単純化する例は、John Ousterhoutの本にある「Define Errors Out of Existence」とまったく同じである
コメント欄がメッセージを理解していない人たちで主に埋まっているという皮肉を楽しんでいる。Leslie Lamportの要点は、抽象的に考える能力を育てることがより良いプログラムにつながるということだ。数学的・論理的な意味での抽象化は、関係のない細部をすべて取り除けるようにしてくれる。AIが導くソフトウェア開発でも同じことが言える
厳密さが関わるあらゆることと同様に、多くの人はタイトルだけ読んで否定的な反応を示している。Hacker Newsにおけるハッカーとは、問題を解決できる熟練したプログラマーを指すこともある。今では「You're a Hack」という意味で、無能で低品質な結果を生み出す人を指すこともある
この講演と議論は細かすぎる
ACMに現在良い記事があり、抽象化とは何かについては同意しないが、それでも非常に有用だという内容になっている。重要な点がどこにあるかについては概ね同意する。正確に何なのか、なぜ重要なのかについては同意しない。多くの刺激を受けられ、それ自体に価値がある
ハッキングはコーディングではなく、プログラミングでもなく、ソフトウェア開発でもなく、ソフトウェアエンジニアリングでもない。しかし最終的には、多くの人がこれらの用語をほぼ交換可能なものとして使っており、個人的な定義の違いを強調することは、ほとんど生産的な時間の使い方ではない