# Edsger W. Dijkstra ## このソースでの役割 Mahoney が [[@1990__CWIQuarterly__The Roots of Software Engineering]] で、Ford 流の「試して壊れたら直す(test-and-debug)」モデルとは対照的な立場の代表として引用する。NATO Rome 会議(1969)への寄稿「Structured Programming」で「プログラムテストはバグの存在を明らかにするために使えるが、その不在を示すためには決して使えない("Program testing can be used to reveal the presence of errors, but never to show their absence!")」と主張した。 Dijkstra にとってプログラミングは数学を志向すべきものであり、バグの不可避性を受け入れて入念なテストでそれを発見するのではなく、プログラムが正しく動作することを数学的に証明する手段を追求すべきだとした。この証明手段を「構造化プログラミング(structured programming)」と呼び、その構造をプログラミング言語とコンパイラ自体に組み込もうとした。Mahoney は、Ford の生産性モデルに(意識的にせよ無意識的にせよ)応答していたのが数学志向の計算機科学者たちだったと位置づけ、Dijkstra をその代表格とする。(Source: [[@1990__CWIQuarterly__The Roots of Software Engineering]] §6) ## 『ネットワークシステムについて語るときに我々の語ること』における役割 第4章§4.4は、OSPF/ISISなどのルーティングプロトコルで使われている最短経路アルゴリズムを見出したオランダの計算機科学者・構造化プログラミングの提唱者として脚注でDijkstraを紹介した上で、シンプルさの重要性に関する発言の一節を引く。「シンプルさは偉大な美徳だが、その達成には多大な努力を要し、その真価を理解するには教育を必要とする。さらに始末が悪いことに、複雑なものほどよく売れるのだ。」Larry Petersonはこの一節を、17世紀の数学者パスカルの「この手紙がいつもより長くなってしまったのは、単に、それを短くする時間がなかったからだ」という言い訳と比較し、Dijkstra・Wirth・パスカルをはじめとする「シンプルさの擁護者」の多くが、エレガンスの実現には多大な労力と優れた判断力の双方が不可欠だと説いていると位置づける。この真理は個々のプログラムや数学の証明、エッセイと同様に、インターネットのような大規模システムにもそのまま当てはまるとされ、インターネットの砂時計モデルの議論(IPを細いくびれとする設計)へとつながる。第4章の章末まとめでも、Wirth、Dijkstra、Clark、Cerf、Kahnと並べて、優れた判断をしその経験を他者に伝えようと努めた人物として挙げられる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 4 システム設計における判断]] §4.4, §4.5) ## 関連 - source: [[@1990__CWIQuarterly__The Roots of Software Engineering]] / [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 4 システム設計における判断]] - concept: [[構造化プログラミング]] / [[ソフトウェア工学の起源]] / [[エレガンス(システム設計)]] ## 出典 - Edsger W. Dijkstra, "Structured Programming", NATO Rome 会議(1969)寄稿。Peter Naur, Brian Randell, J.N. Buxton (eds.), *Software Engineering: Concepts and Techniques* (NY: Petrocelli/Charter, 1976), 223. - 上記は Michael S. Mahoney, "The Roots of Software Engineering", *CWI Quarterly* 3, 4 (1990), 325–334 経由での孫引き。 - Edsger Dijkstra, "On the nature of Computing Science", October 1986(『ネットワークシステムについて語るときに我々の語ること』第4章参考文献[10]経由)。