構造化プログラミング
IBM社が1974年頃から発表するようになった所属研究員たちによるプログラム開発方法論の数々にも構造化(Structured)の接頭辞が付けられていたが、それらは抽象化を重視するダイクストラの構造化とは異なり、サブルーチン複合体とデータ構造を適切に連携させるための構造化であった。その違いを指摘して本来のダイクストラ方式を改めて紹介する動きもあったが、抽象化指向のダイクストラ理論は産業界ではむしろ不人気でさえあった。クヌースの言葉を借りれば、構造化文の第三幕はIBM社とハーラン・ミルズがプロモートした制御構造の舞台になり、構造化プログラミングに対する世間一般の認識はこちらの方で定着するようになった。
終幕
後年、ダイクストラは自身が作った構造化プログラミングという言葉に不快感を示して避けるようになった。この言葉を作った時、彼はプログラミングが手工芸から科学へ発展することを期待していた。しかし構造化プログラミングという言葉は実利を求めるために使われるようになった。次のような逸話がある。構造化開発の第一人者エドワード・ヨードンの事務所にセミナー依頼の電話がかかってきた。プロジェクトメンバー全員に構造化プログラミングを1日で叩きこんで欲しいという内容である。それが終わったらプロジェクト期間を半分にするという。その理由は「構造化プログラミングは生産性を2倍にするという話ですから」であった。
1968年のACM機関紙への投書「Go To Statement Considered Harmful」は、そのセンセーショナルなタイトルで当時のプログラマの間に大きな論争を巻き起こした。その要約は次の通りである。
プログラマの仕事は正しいプログラムを作り上げた時に終結し、コンピュータにそのプログラム実行が委託されるとプログラマの手を離れて、コンピュータ内の動作形態であるプロセスに作り替えられることになる。
私たち人間の能力は、静的なプログラムの内容を把握するのには向いているが、コンピュータ内で逐一変化していく動的なプロセスの状態を把握することには向いていない。従って私たちは静的なプログラムと動的なプロセスの間にあるギャップを埋めなければならない。
そのためには、動的なプロセスの動態指標(dynamic index)と正確に対応できる静的なプログラムの文体指標(textual index)の表現が必要になる。goto先ラベルはその要求を満たしていない。「if B then A」「if B then A1 else A2」の選択節や「while B repeat A」「repeat A until B」の反復節の方が適している。
gotoとラベルを用いた選択文と反復文の記述では、状態判定とジャンプが個々に並べられるので、これはプログラムの混乱の原因になる。特にラベルの多用は取り除かれるべきであり、それに伴ってgotoの使用数も削減される。