基本情報

Leonard H.Weiner, The Roots of Structured Programming,の全訳。
おかしなところがあればご指摘ください。ところどころ意味わからない部分があります。後半に行くに従いやっつけになってます。

構造化プログラミングのルーツ

導入

　構造化プログラミングという言葉は、コンピュータ業界の人ならばほとんど誰でも知っている言葉である。しかし、長年にわたり、この用語が計算機科学のいくつかの一見多様な分野と関連付けられているということから、多数の人間（特にこの分野の新規参入者）が、混乱をするか、このテーマを非常に狭く捉えているか、という状況となっている。

　構造化プログラミングの全体像を把握するためには、膨大な量の出版物を要約し、背景となる情報を断片的に抽出し、それらを互いに関連付けなければならない。この試みの何らかの指針や整理された計画がなければ、これは無駄な運動となりかねない。そこで、我々はこの論文を書くにあたって、次の2つの目標を掲げることにした。すなわち、
(1) 構造化プログラミングの歴史的経緯を簡単に紹介すること、そして
(2) 構造化プログラミングをより深く知りたい読者のために、整理されたガイドを提供すること
である。

　この論文の前半の部分では、構造化プログラミングの発展に貢献した考え方（と人々）を紹介し、彼らが開発した基本的な概念を提示した上で、計算機科学のいくつかの分野においてそれらが影響を与えたことを示す。後半では、これらの分野の成長をたどり、多数の参考文献と107項目の書誌情報を提供する。

　本論文の形式は、本質的には、時系列に整理し、分類し、拡張し、注釈を加えた書誌情報からなるものである。この論文で議論される資料は、我々の目標にいかに合致しているかという基準で選ばれたものである。

構造化プログラミングの先駆者たち（1965-1967）

『単刀直入に言えば、マシンがない時代には、プログラミングは全く問題とはならなかった。少数の貧弱な計算機を得たときから、プログラミングは中程度の問題となった。そして今となっては、我々は巨大な計算機を手に入れたことから、プログラミングは同じくらい巨大な問題になった。』
エドガー W．ダイクストラ [DIJK72B]。

『1968年10月、NATOのソフトウェア工学会議は、ソフトウェア危機（software crisis）を公然と認めることで、センセーションを巻き起こした。』
E. ダイクストラ[DIJK75]

しかし、1968年以前でさえも、多様な分野で働き、構造化プログラミングを組み立てるブロックの一部として認められるものを開発している人々がいた。そして、他の「ルーツ（roots）」と同様に、これら構造化プログラミングの先駆者、E.ダイクストラ、G.ヤコピーニそしてP.ナウアーのいくつかの仕事を調べるために、大西洋を横断することから我々の調査を開始する。

　オランダでは、エドガー W. ダイクストラは、プログラムの明快さ（clarity）、正当性（correctness）そして構造（structure）についてかねてより関心を持っていた。1965年、彼は論文"Programming Considered as a Human Activity"[DIJK65]（訳注：EWD117 ）を発表した。この論文における彼の趣旨は、プログラマーと彼の精神は計算プロセスの重要な一部であり、人間の目標とマシンの特性を対立するものとする必要は無い、というものであった。彼は、モジュール化された、gotoの少ない（goto-less）プログラムは、作ることも理解することも人間にはより容易になるので、計算機の使用においてより効率的になると主張した。彼は、プログラムのエレガントさを論じ、証明を構成する方法とプログラムを構築する方法との間のアナロジーを引き出した。この論文の中で、ダイクストラは冒頭、「プログラマーの質は、プログラム中のgoto文の密度に反比例する」と述べた。この考えは３年後に改めて述べられることになる[DIJK68A]。

　1966年、代数的言語学とオートマトン理論の分野で研究している数学者であるC.ベームとG.ヤコピーニは、特に重要な論文を発表した[BOHM66]。この論文は２つの部分からなるが、（ヤコピーニが書いた）最初の部分の結果のうち１つだけが我々の今回の議論に関係する。特に、彼は、どんなプログラムも、次の３つの基本ダイアグラム（制御構造）だけ
(a) Π （順次（sequential）または連結（concatenation））,
(b) Δ （交代（alternation）または選択（selection））、および
(c) Ω （繰返し（iteration）または反復（repetition））
を使って等価なプログラムに変換できるということを主張した。これらダイアグラム（後にダイクストラに敬意を表してD-charts または D-structure と命名された[BRUN72, KOSA74, LFDG75]）は、Figure１で示されている。ヤコピーニは論文の中でこの結果を証明しなかったものの、彼は証明方法の概要を示した。その後、H.ミルズは、固有プログラム（proper program）のクラスに限定した上で、ヤコピーニの結果を形式的に厳密に証明した[MILL72]。

　1966年の2番目に重要な論文は、P.ナウアによって書かれた[NAUR66]。この論文において、ナウアはアルゴリズムを証明することの重要性を強調し、一般的なスナップショットを使用する非形式的な手法について議論した。これはまず、動的プロセスの実行中にプログラムテキストの決定的場面を元にスナップショットが取得され、次に、各点におけるプログラムの状態について条件が仮定され、そして、そのポイントに到達するたびにその条件が真であるとき、アルゴリズムが証明される。この手法は、後に不変量の方法（the method of invariants）へと発展した。

　翌年には、アメリカ人のR.W.フロイドは、プログラム証明の確立にあたっての問題点を議論した論文を発表した[FLOY67]。ここでのプログラム証明は、特定の計算をするプログラムでありかつ終了するプログラムに対してのものである。彼はこれらの証明の例を、注釈付きフローチャートによって提示しており、そこではプログラム変数の値に関する命題（主張）が注記（タグ）として記述されていた。期待される結果についての命題は、終了時点のプログラム正当性を証明するにあたっての役割を果たす。

　ナウアとフロイドの手法は、それぞれ独立に発展したものであるが、概念的には類似しており、どちらも後の多くのプログラム正当性の証明の研究の基礎となった。

概念（1968）

1968年のE.ダイクストラとN.ヴィルトの著作を調べると、前節で述べた一見無関係に見える考え方が統合されていることがわかる。この統合は、ダイクストラによって表現された概念の基礎を成している。つまり、のちに構造化プログラミングへと発展するものとしてまかれた種となる概念である。これはまた後にプログラミング言語の開発においてヴィルトによって用いられた革新的アプローチにおいても明白に表れている[WIRT6B, WIRT71A]。

　ダイクストラは、1968年の論文[DIJK68R]において、プログラムの証明はプログラム設計目標の一つであるべきであると主張した。つまり、プログラムとその証明は同時に開発されかつ並行に構築されるべきであるとした。かれはプログラムが構築された後に証明を検討することは困難でありまた賢明でもないと述べた。彼は、マルチプロセッシング・システムの同期問題を用いて、この彼の提案した概念を実証した。

　ダイクストラはプログラム正当性の望ましさと”goto"制御構造の不要さについて彼の考えを先に発表していたが[DIJK65]、1968年になってやっと、彼の考えについての短い論文が"Communications of the ACM"の編集者への手紙[DIJK68A]として掲載されることになってから、一般の計算機コミュニティが注目するようになった。「Go To Statement Considered Harmful」と題されたこの「手紙」の中で、ダイクストラは、高級言語における"goto"文の見境の無い使用（ここでの事実としては、すべての使用）を糾弾した。その代わりに、プログラム制御のために、手続き呼び出しの使用と条件文と繰り返し文の使用を推奨した。プログラマの質に関して彼が1965年に述べたこと、プログラマの質は彼らのgoto文の密度に反比例する、の反復は大きく[RICE68]も小さく（big[RICE68] and small）も計算機科学者の注目を呼び起こし、「GOTO論争（GOTO Controversy）」[LEAV72A]を生み出すこととなった。ダイクストラは、1959年の早い時期に、他の人々（Landin, Strachey, ZemanekそしてHoare）がgoto文の使用に制限を加えるよう呼び掛けていたことを認めている。彼はまたヤコピーニのgoto文の除去を可能にする結果[BOHM66]も認めていたが、任意のフロー図をジャンプなしのものに機械的に変換することに価値を感じなかったようである。

　1960年代半ば、スタンフォード大学に勤務していたスイスの計算機科学者のN.ヴィルトは、アセンブリ言語の構築において新しい概念を開発した。その結果がIBM360用に特別に設計されたPL360[WIRT68]である。この言語は、高級な、Algolライクな言語の特徴を多く示す一方で、「本質的にアセンブリ言語の面倒くささをいくつか背負っている...」という。これは、「言語において提供される構造、・・・ブロック、手続き、そして、if、for、while文・・・」そして、ヴィルトが1966年にAlgolの構造化された拡張として発明したcase文[WIRT66]で有名である。この論文には、ヴィルトの「「プログラマが規律正しく、明晰で読みやすいスタイルでプログラムを書くことを奨励するツールを提供し、その結果、信頼性を高める...」という関心が示されている。同様の関心は、ヴィルトが後に開発した言語であるPascal[WIRT71A]にも表れている。

　当時を振り返ると、1968年末までには、新しい（構造化）プログラミング言語の開発、検討、テストを行う人々が出てきていた。また、プログラム正当性の証明と証明に適合するアルゴリズムを構築する方法を研究しているほかの人も出てきている。そして最後に、主としてGOTO論争によって、プログラミングの構造、テクニック、そして言語に対する一般的な関心が呼び起こされたことがわかる。

誕生（1969-1970）

1969年と1970年には重要な論文はほとんど発表されなかったが、この数年間は革新と発展に満ち溢れていた。構造化プログラミングの最も基本的な概念のいくつかが定式化され、テストされ、1971年までには報告された。そして、ヤコピーニの構造が構造化されたプログラムの基本的な制御構造として採用されたのもこの時期だった。

1969年には、P.ナウアとC.A.R.ホーアによる2つの重要な論文が発表された。しかしそれ以上に重要だったのは、E.ダイクストラが書き、主にヨーロッパの限られた数の計算機科学者に私的に配布された一連のノートであった。これら「構造化プログラミング論（Notes on Structured Programming）」は、この分野の発展に大きな影響を与え、この分野の名前にもなった。

P. ナウアの論文[NAUR69]の抄録において、「この論文では、与えられた大域的な要求からシステマテックにプログラムを構築することを目的とするプログラミングの規律を記述している。このアプローチにおける重要なステップは大域的な要求を動作のまとまり（プログラム文の列）の集まりに変換することであり、これは最終的なプログラムを組み立てるためのブロックとして用いられることになる。・・・」と述べられている。このアプローチは、段階的詳細化法（stepwise refinement）[DIJK69,WIRT71B]による開発やトップダウン設計（top-down design）[MILL71]の技法につながった。

C.A.R.ホーアは、1969年の論文[HOAR69]で、数学の公理的方法、すなわちプログラムの性質を証明するための公理と推論の規則の集合を明らかにすることによって、プログラミングの論理的基礎を探った。プログラムの実行後、プログラムの最も重要な性質とは、意図した機能を実行したかどうかであり、これは、プログラム終了時点の変数の値についての一般的な表明（assertion）を作成することによって特徴づけることができる。ホーアはプログラムの正当性を証明するために用いる表明（assertion）を表現するために数理論理学の標準的な記法で表現した。当然のことながら、これはプログラミング言語の実装が証明において用いられる公理と推論規則の集まりに適合する場合にのみ有効である。のちに、ホーア[HOARE73B]は、この方法を拡張し構造化されたプログラミング言語のPascalの公理的定義を提供した。

E.ダイクストラは、自分自身への手紙という形で一連のエッセイを書き、「構造化プログラミング論（Notes on Structured Programming）」[DIJK69]という題名で配布した。その後、これらノートは、いくつか加筆された上で、「構造化プログラミング（Structured Programming）」[DAHL72]という本の３つのモノグラフのうちの最初のものとして出版された。これらノートにおいて、ダイクストラの主眼は、管理可能（manageable）、適応可能（adaptable）かつ証明可能（provable）なプログラムを書くことに置かれている。さらに、効率性はプログラムの正しさが証明されてから考えるべきであり、その上で、プログラムが管理可能なままである場合にのみ考えるべきであると主張している。

ダイクストラは、「プログラムのテストはバグがあることを示すのに使えるが、バグが無いことを示すことには使えない」ということから、「プログラマの義務は、自身のプログラムを、...プログラムの正当性の納得させられる証明を伴う『有用な構造』にすること」であると述べている。「プログラム（もしくはその正当性の証明）を理解する」ために、ダイクストラは、数え上げ（enumeration）、数学的帰納法（mathematical induction）、そして抽象（abstraction）という３つの知性の道具を推奨した。短い例を示した後で、ダイクストラは「抽象化を主な知性の道具として評価する」べきと結論付けた。プロセスの抽象化とは、「どのように動くか」ということを無視して、「何をするか」ということに着目した使用を意味する。

ダイクストラは、「プログラムの理解について（On Understanding Programs）」というエッセイにおいて、それぞれが部分動作（プログラム文）の列に分解できる動作の集まりの順次実行（sequential execution）について検討した。彼は、順次（連接;concatenation）、if-then-else（交代;alternationまたは選択）そしてその縮退形であるif-then；case-of（一般化交代）、さらにwhile-doとrepeat-until（反復;repeatitionと繰り返し;iterationの2形式）といった基本制御構造を説明しフローチャートを作成した。彼は、プログラムテキストの構造と計算（プロセス）の構造を関連付け、プログラム文の動的実行を表現しているプログラムのフローチャートはまたプログラムテキストの静的構造（ロジック）も表現していると主張した。プログラムの動的な表現と静的な表現が近ければ近いほど、そのプログラムの理解はよ明確になる。ダイクストラの三つの基本構造、順次、選択（if-then-else）そして反復（while-do）、のフローチャートは、ヤコピーニのΠ、Δ、そしてΩの基本図式と同一である[BOHM66]。

次にダイクストラは「段階的詳細化法（Stepwise Refinement）」について論じた。この技法を用いることによって、一つのアルゴリズムは次の一連の段階で開発されることになる。最初の段階は、たとえば、PRINT THE SOLUTION TO THIS PROBLEMというように、問題を完全に解決する１つないし２つの文が、非常に高級（very high-level）な、仮想言語（virtual language）で作成される。次の段階では、最初の段階における文を、例えば、

READ DATA;
CALCULATE SOLUTION;
PRINT RESULTS.

というような形で、やや低級（slightly lower-level）な、仮想言語で、それぞれ２つないしより多数の文に分解することによって詳細化する。このプロセスは、アルゴリズムがコンパイル（またはアセンブル）され、コンピューター上で実行できる言語に改良されるまで、各ステップで続けられる。ダイクストラは、第一段階のプログラムが正しく、その後に続く詳細化で誤りが入り込まなければ、各下位段階のプログラムもまた正しくなり、すなわち、最終的なプログラムは正しくなると主張している。

ダイクストラは、「構造化プログラミング論（Notes on Structured Programming）」において、ここでは説明しきれないいくつかの重要かつ興味深いトピックを開拓している。興味のある者は、ぜひ構造化プログラミングの父の考えを個人的に体験することを勧める。

1970年には、構造化プログラミングの新しい分野が始まったことを示す証拠が得られることとなった。大規模なプログラミングシステムを扱う商業分野のコンピュータ業界は、以前からソフトウェア危機（software crisis）と戦っていた。この時期、IBMのハーラン・D.ミルズは、構造化プログラミングの大規模システムへの適用に着目していた。彼は、正当性を確立するために、大規模プログラムをブロック構造に従って定式化し「トップダウン」設計することを提案した。彼は、プログラム詳細化のレベルと、望んだどのレベルでもプログラムをより読みやすくするインデントなどの手法を用いることを提唱した。そして、これらルーツから、彼は、ニューヨークタイムズ情報銀行の契約においてはじめてテストされたチーフプログラマーチームの概念を提唱し発展させた。しかしながら、ミルズの革新についての情報が大量に流通するようになったのは1971年以降である[BAKE71, IBMl71, MILL71]。

一方で、R.ジャッドの1970年の論文[JUDD70]は、大規模プロジェクトのプログラミングチームに関する当時のアイディアと懸念のいくつかについて洞察を与えている。彼は、モジュール化したプログラミングの主な利点として、（１）複数のプログラマが同時にプロジェクトに取り組むことができる、（２）プログラムのテストと検証（validation）を強化することができる、と考えていた。同時に、「上司は部下の作ったコードを読むことができるのか」、「プロジェクトのマスタープランはチームリーダーのみが知るべきものなのか」、「プロジェクトの設計には若手も参加すべきなのか」といった非常に基本的な問題にも触れていた。

ここまでの構造化プログラミングのレビューにおいては、6年間の歳月をカバーし、8人だけの仕事を取り上げてきた。この先、構造化プログラミングの分野の数も、それに携わる人々の数も、飛躍的な成長を遂げることになるであろう。しかし、ダイクストラ、フロイド、ホーア、ミルズそしてヴィルトの名前は、これからも拡大する分野の中心に登場し続けることになるであろう。

発展（1971-1975）

1971年までには、構造化プログラミングの主要な根（roots）が確立され、枝葉が芽吹くこととなった。その後数年間にこの分野で発表された文献のほとんどは多様な枝の発展について説明するものだった。この論文の残りは、選りすぐりの論文を簡単にレビューし、それらを以下のカテゴリに分類することによって、これらの発展を反映させることにする。

段階的詳細化法とトップダウン設計
Harlan D. Millsの他の業績
構造化プログラミングのための制御構造
構造化プログラミングのためのプログラミング言語
プログラム正当性の証明
プログラミングスタイルと心理的要因

1 段階的詳細化法とトップダウン設計

1971年4月号のCommunications of the ACMの表紙を飾ったのは、N.ヴィルト [WIRT71B] による「段階的詳細化法によるプログラム開発（Program Development by Stepwise Refinement）」という記事である。この記事でヴィルトは、8-クイーン問題というエレガントな例を用いて、段階的詳細化法（stepwise refinement）のプロセスを説明している。ヴィルトによって説明されたプロセスは、本質的にはダイクストラが[DIJK69]で論じたものと本質的に同一であるが、その例のエレガントさと、広く配布された定期刊行物におけるその目立つ位置のため、この記事は多くの好意的な注目を集めた。それ以来、段階的詳細化法は「構造化プログラマー」の標準的な道具の一つとなった。

「段階的詳細化法によるプログラム開発」が登場したころ、H.ミルズは「大規模システムにおけるトップダウン・プログラミング（Top Down Programming in Large Systems）」[MILL71]という論文を書いた。この論文の中でミルズは、プログラムを開発するための「トップダウン設計（top down design）」と呼ばれる技法について説明した。これは、構造化プログラミングの基本的な制御構造（順次、if-then-else、do-while、場合によってはcase）のみを強制的に使用し、コードを段階的に開発することを主張するものである。「初期システムはプログラムの機能仕様であり、各中間システムはその前身のコードを含み、そして最終システムはプログラムのコードである。」したがって、「プログラムのコードは、この一連の中間システムの中で『トップダウン』で生成される。」そして、各段階でシステムが正しいことを検証（verified）することができる。段階的詳細化法におけるものと同じように、このプロセスは「コードしかないセグメントに到達し検証（verified）されるまで」続けられる。これら２つの技法の類似性を見るのは簡単である。

同じ論文の中で、ミルズは構造化されたプログラムを書くための４つのルールを次のように定めている。

goto文を使うな。その代わりに if-then-else、do-whileなどの構文を使え。
プログラムをトップダウンで開発せよ（伝統的な「ボトムアップ」方式とは対照的）、さらに各ステップを検証（verify）せよ。
do-end構造の本体およびif-then-elseのthen節とelse節には一貫したインデント規則を用いよ。これら構造自体がネストされている場合、キーワードであるDO-ENDとIF-ELSEはさらに１レベル分インデントされ、それぞれの文はさらにインデントされる。
例えば、PL/Iプログラムは次のようにインデントされる：
ネスト無し

DO WHILE ...;
    statement 1;
    statement 2;
END;
IF ... THEN
    statement 3;
ELSE
    statement 4;

ネストあり

DO WHILE ...;
    statement 1;
    IF ... THEN
        statement 2;
    ELSE
        statement 3;
    statement 4;
END;

プログラムをモジュール化せよ。つまり、コードをそれぞれが１ページに収まるような断片に構造化しつつ、プログラムの機能仕様（もしくは部分仕様）を実装せよ。

これら４つの常識的なルールは、単純であるがゆえに、構造化プログラミングの核心として置かれている。

2 ハーラン・D.ミルズの他の業績

1971年に始まり、H.ミルズとF.T.ベーカーは、超大規模プログラミング・システムで使用するためにミルズが提案・開発したチーフ・プログラマ・チーム（Chief Programmer Team;CPT）に関する一連の報告書[IBM71,BAKE71,BAKE72,BAKE75]を作成した。CPTの目的は、プログラマの生産性を最大化し、正しいプログラム（デバッグの時間が最小化されたものであろう）を生産することである。その主な特徴は以下の通りである。

チームの核となるのは３人の常設メンバーのみである。すなわち、チーフ・プログラマー、そのバックアップ・プログラマー、そしてプログラマー司書である。最初の２人は、構造化プログラミングの手法を使ってトップダウンでシステムを設計する上級プログラマーである。司書は、プログラマー技術者もしくは追加的な技術的スキルを持つ秘書であり、仕事を通してすべての記録、文書そして通信を管理する責任を持つ。彼女（または彼）はまたすべてのキー入力、データ入力に責任を持ち、すべてのコンピュータ実行を行い、すべての出力をファイリングする。こうして司書は、プログラマーからすべての事務作業を解放するのである。（E.ヨードンの記事[YOUR74]、「プログラマーはプログラミングをするために給料をもらっている：司書を導入せよ（Programmers are Paid to Program: Enter Program Librarian）」は司書の機能を適切に描写している。）
プログラム設計が十分に進んだら、若手プログラマ、分析者そして技術者をチームに加える。彼らはプロジェクトの全体設計には一切参加しない。プログラマーは、（構造化プログラミングの技法を使って）コーディングする機能的モジュールの設計に参加しないこともある。これらはすべてチームの一時的なメンバーであり、彼らの特定の任務が終了するまで滞在するだけである。
チーフ・プログラマとそのバックアップ・プログラマーは、若手プログラマがコーディングしたプログラムの全ての行を読み、そしてチーフ・プログラマはプロジェクト全体について責任を持つ（彼が「スーパー・プログラマ（superprogrammer）」[OGDI72]と呼ばれるのも無理はない）。

ニューヨーク・タイムズの実験[BAKE72]は、プログラマーの生産性とプログラムの正当性を向上させるという点で大成功を収めた。P.ウェグナー[WEGP76]によれば、このプロジェクトは「・・・1人・年当たり10,000命令の生産性を達成し、１人・年あたりただ一つのエラーしか発生しなかった」と主張している。しかし、彼はまた次のように述べている。「報告された成功は・・・完成されたプログラムのメンテナンス性と変更可能性が不十分であるという理由で、のちに異議を申し立てられた。」

その１年後の1972年、ミルズはもう一つの重要な論文「構造化プログラミングの数学的基礎（Mathematical Foundations for Structured Programming）」[MILL72]を提出した。この論文において、３つの定理と一つの系について述べ、その数学的証明を与えた。

構造化定理（Structure Theorem）－「どのようなフローチャート化可能なプログラム論理も、・・・わずか３種類の構造［D-構造］によって表現できることを保証する。」（これはヤコピーニの仕事[BOHM66]の証明である。）
トップダウンの系（The Top Down Corollary）－「構造化されたプログラムが『トップダウン』で書いたり読んだりできること、つまり、プログラムの各セグメントの正当性がすでに書かれたセグメントのみに依存するようになることを保証する。」
正当性定理（The Correctness Theorem）－「構造化されたプログラムの正当性の問題が標準的な数学的手法が適用できる関数論的な問題にどのように還元できるか示している。」
拡張定理（The Expansion Theorem）－「任意の機能的仕様を次の［より低い］レベルの構造に拡張する際に利用可能な自由度を定義している。」

ミルズの論文、「どのように正しいプログラムを書きかつそれを知るか（How to Write Correct Programs and Know it）」[MILL73]は1973年に書かれ、2年後に同じタイトルで改訂され出版された[MILL75]。この論文の中で、ミルズは、エラーのないコードを最初から書くために構造化プログラミングの減速を使用することを提唱している。以来彼は、「プログラム中の全てのエラーを発見したを確信する」絶対確実な方法はなく、プログラマーは自身のプログラムの正当性について自信を持たなくてはならない、と述べるようになった。この自信は経験、形式的証明の使用、テストそして実践の組み合わせによって得られる。そして最初のエラーが見つからない限り、その自信は正当化される。この論文の大部分は、構造化プログラミングの歴史と技法、そしてプログラムの正しさについての議論に費やされている。

3 構造化プログラミングのための制御構造

1968年のダイクストラのgotoに対する攻撃[DIJK68A]は、その4年後にピークに達する広範な論争を引き起こした。1972年のACMの年次総会では、B.リーベンワースが「GOTO論争」に関するセッションの座長を務め、その中で、対立する見解が議論された。このセッションの記録[LEAV72A]には、３つの準備された論文[LEAV72B,HOPK72,WULF72]と、反論と討論時間の内容が収録されている。リーベンワースはこのセッションの冒頭で双方の主張を紹介した。「goto文を除去する（と同時にほかの制御構造で置き換える）ことに関する議論としては、・・・（１）goto-lessプログラムは理解しやすく、デバッグと修正がしやすい・・・（２）プログラマーが［「良い」制御構造］を合成するためにgoto文を誤って用いやすい、そして（３）goto-lessプログラムについて表明（assertion）を証明することは容易である、というものある。」加えて、goto文を含むプログラムは次のようなもので置き換えてもよい、「（１）再帰手続き［しかしこれは実用的なものではない］、・・・（２）while文・・・［ただし、補助変数を導入する必要になる可能性がある］そして（３）ノード分割［これは冗長なコードや手続きの呼び出しを必要とする］。」

「goto文の除去に反対する議論としては、（１）goto文は異常終了のために必要、（２）goto文の方が効率的であることが多い、（３）［言語の欠けている構造を］合成するためにgotoは有用である、というものがある」

他の参加者はそれぞれ、goto文の使用について賛成か反対かの意見を述べた。そして議論の時間の最後には、goto文を完全に除去する必要はないが、（１）その使用は前方参照（決して後方参照ではない）に限るべきであり、（２）goto文を用いないプログラムを書くようにすべきであるといった意見で一致したようであった。

２年後、D.クヌースは、「goto文による構造化プログラミング（Structured Programming with goto Statements）」[KNUT74]において、ダイクストラの言葉を引用し、「私が（goto文について）恐ろしく教義的であると信じる罠に嵌らないで欲しい。私には、他の人たちがそれをまるでプログラミングの概念的な問題がたった一つのトリックで解決できるというように宗教化しているような気がしてならない。」そしてミルズはこの問題の全体を見通した上で次のように述べた[MILL72]。「構造化されたプログラムは単にgoto文が不使用であることではなく構造が存在することによって特徴づけるべきである。」

「GOTO論争」が1972年以降急速に衰退した一方で、この論争は、多くのプログラマーと構造化プログラミングに適した制御構造の開発に決定的な影響を与えた。

この論文の前の節で、この分野のいくつかの仕事について議論したが、以下では1971年から1975年にかけて行われた仕事のいくつかを紹介する。

[ASHC71, BOCH73, PETE73, URSC75] (これら仕事の主たる目的はgoto-lessプログラムである。)
[MART73, NASS73, FRID74, KNUT74, KOSA74, ZAHN74, WEIN75] (これら仕事はより一般的なものである。)

H.リガードとM.マルコッティによって書かれた「制御構造の遺伝学（A Geneology of Control Structures）」[LEDG75]は傑出した論文である。この論文の中で、著者たちはベームとヤコピーニの研究[BOHM66]に始まる制御構文に関する２６の論文の結果をレビューしている。

4 構造化プログラミングのためのプログラミング言語

N.ヴィルトは、1969年にプログラミング言語Pascalを定義し、1970年にCDC-6400用に実装を行い、1971年初めにPascalについて報告した[WIRT71A]。PascalはAlgol60から派生した汎用言語である。実際、PascalはAlgol W[SITE72]（ヴィルトがAlgolの後継言語の見込みの一つとして提案した言語）で提案された機能の多くを備えている。Pascalのそれまでにない特徴は、主に次の２つのカテゴリに分類される。すなわち、（１）データの定義と操作（入出力を含む）、（２）制御構造。

よく構造化されたデータとよく構造化されたプログラムは密接に関係しているが、この論文では、言語の論理的・動的特性、特に制御構造にのみ関心を持つことにする。Pascalは構造化プログラミングに必要な「よい」制御構造がすべて含まれている。すなわち、if-then-else（そしてif-then）、while-do、repeat-untilそしてcaseである。より伝統的な構造としては、連接（concatenation）、for-loopそしてgotoでさえも含んでいるのである！そして、PascalはAlgolの派生言語であることから、再帰（recursion）をサポートするブロック（block）構造化言語である。

ヴィルトは２年間Pascalを使用した後に、言語にいくつかの修正を加えた上で改訂報告書[WIRT73B]（これはイェンセンとヴィルトのPascalユーザー・マニュアル・レポート第二版[JENS75]にも掲載されている）を発表した。同年、ヴィルトとC.A.Rホーアはまた、ホーアの公理的手法[HOAR69]の拡張版に基づくPascalの厳密な意味定義[HOAR73B]を作成した（実数演算とgoto文を除く）。

ヴィルトの報告は、時とともに増大する多くの関心を呼び起こした。Pascalは今や、大規模にも、ミニにも、そしてマイクロ・コンピュータシステム上で広く実装されている[PUG77]。Pascalの人気の理由は次のようなものであると思われる。すなわち、（１）構造化（および非構造化）されたプログラムを書くのに非常に適している、（２）非常に読みやすい言語である（プログラムを理解するためにPascalプログラムを書くことができる必要はない）、ということである。Pascalについて書かれたテキスト[JENS75, CONW76A, BOWL77]、もしくはアルゴリズムを構築するためにPascal（またはPascalライクな言語）を使用したテキスト[DAHL72, WIRT73A, HANS73, DIJK76, WIRT76]が増えていることは、Pascalの人気が続くことを示している。

W.A.ウルフは、goto-lessプログラミング[WULF71A, WULF72]の提唱者であり、彼の２人の仲間、D.ラッセルとA.N.ハーバーマンと共に、カーネギーメロン大学のPDP-10コンピュータようにシステム実装言語Bliss[WULF71B]を設計実装した。Blissは、Pascalの議論で述べた「よい」制御構造をすべて含んでいるが、gotoは含んでいない。しかしながら、Blissは、無条件に制御を移すことを許すエスケープ・メカニズムであるleave構文を持っている。leave構文を使うと、プログラマは制御環境の実行を、その環境の終わりにジャンプさせることで、早期に終了させることができる。1971年までに、Blissは、コンパイラとシステム・プログラムを記述するためにカーネギーメロン大学で使われ、成功を収めたと報告されている[WULF71C]。

1973年、E.C.ハイネスは、IBM360用のもう一つの構造化アセンブリ言語であるALについての報告書[HAIN73]を発表した。ALは、「PL360と多くの特徴を共有している」[WIRT68]が、「ALとBALは、アセンブリないで共存でき、・・・マクロが、・・・サポートされている」という点でBAL（IBM 360アセンブリ言語）に近い。

Jossle[WHIT75]は、コンパイラ構築のために設計された構造化言語である。Jossleの主な目的は「プログラミング言語翻訳の意味論的段階を指定するための柔軟なツールを提供すること」にある。ホワイトによれば、Jossleの設計目標の一つは、「この言語が、正当性の表明（assertion）や命令を作ることができるように、構造が明示的な［翻訳者］の開発を促進させること」であると述べている。

ある言語研究者が新しい言語を定義し開発する一方で、他の研究者は既存の言語を構造化プログラミングに適合するように修正（または拡張）しようとしていた[SULL75, LIM75, MCCL75]。そして、Fortranは非常に広く使われており、特に「非構造化」であるため、大きな注目を集めた。E.ホロウィッツ[HORO75]とL.マイスナー[MEIS75]は、Fortranの修正版と拡張版について調査した論文をそれぞれ書いた。マイスナーは、２０の異なる構造化プログラミングの方言を挙げ、それら共通の特徴と「将来広く受け入れられる可能性のある構造化Fortran言語」との関係について結論を出そうとしている。これらFortranの方言は、Iftran[MILR73A]と呼ばれる初期のプロプライエタリなプリプロセッサから、広く使われている学生向けのWatfiv-Sコンパイラ（F.フリードマンとE.コフマンによって見事な文章で新たに文書化された[FRIE77]）に及んでいる。最もよく見られる拡張は、if-then-else, do-while, repeat-untilそしてcaseといったものの変形や、DO-loopの最初の実行前のループ制御変数のテストなどである。

「標準」言語を使って「構造化プログラミング」を教えようとするプログラミング・テキストの割合が増えている[WEIN73, KIEB75, CONW76B, GELL76, MCCR76, FRIE77, PHIL77, SHEL77]。よく構造化されたプログラムがどんな言語でも書くことができるようになって以来、これらテキストのいくつかは見事にその目標を達成している。残念なことに、他のもの（ここで言及されていない多くのものを含む）は、明らかな理由（caveat emptor;買い主の危険負担）のためにバズワードを使いながら、単にその言語に「リップサービス」をしているだけである。

5 プログラム正当性の証明

1971年に発表された論文「プログラムの証明：FINDプログラム（Proof of a Program : FIND）」において、C.A.R.ホーアは、彼がその10年前に開発した部分ソート・アルゴリズム[HOAR61]の形式的証明を行った。ホーアはこの証明で全く異なるアプローチを用いたが、その詳細は、彼の以前の論文[HOAR69]とほとんど同じく、「伝統的な論理的記法で形式化された」ものであった。FINDの証明において、不変条件の使用と段階的詳細化法の方法を組み合わせ、「プロセスを・・・段階に分割するために、『トップダウン』的な解析方法を使用したと述べている。正当性は、一連の段階を通して各段階で証明される。すなわち、不変条件はデータに対して定式化され、補題は証明される（ホーアもこれが面倒であったことを認めている）、そして決定事項はそのデータとコードに対して作られる、というものである。ホーアは、彼の方法がナウア[NAUR69]とダイクストラ[DIJK69]の手法に似ていることは認めたが、彼の手法は「論理的エラーやコーディング・エラー［を避けるため］の補助として、・・・より一層の形式化を重視している」ものだと表明した。ホーアは、彼の手法がより実用的になるために、将来機械化されることを望んでいた。

ホーアはその２年後に別の「証明」論文を書いた[HOAR73A]が、その中では「エラトステネスの篩」のプログラムを証明した。この証明のために彼が用いた手法は、ホーアがFINDプログラムを証明[HOAR71]するときに用いた手法に、それよりは形式的ではないものの、類似したものだった。今回、彼はまず該当プログラムの抽象版を証明し、その次に「具体的表現」を証明した。そして、この証明のための補題を定式化する際に、大部分について「直観に頼っていた」という事実にも関わらず、ホーアはこの方法も機械化可能であろうという希望を表明した。

構造化プログラミングのこの分野には、正当性証明のための多くの技術を網羅した幅広い論文がある。1972年の最先端の状況をかなりよく定義した重要な出版物としては以下の２つがある。

1972年6月、エルスパス、レヴィット、ワルディンガーとワクスマンは「プログラム正当性を証明するための技術の評価（An Assessment of Techniques for Proving Program Correctness）」[ELSP72]というサーベイ記事を書いた。この記事の中で、彼らは「プログラマが自身のプログラム正当性を証明することができるようにする技術について、現在進行中の研究の質の高さを指摘している。」この記事の51ページには86項目の参考文献がある。
その年の初め、プログラミング言語に関するACM特別関心班（ACM Special Interest Groups on Programming Languages（Sigplan））とオートマタと計算可能性理論（Automata and Computability Theory（Sigact））が、共同でプログラムに関する表明の証明（Proving Assertions About Programs）という会議を主催した。この会議の議事録[ACM72]には２２の論文が含まれており、その多くは現在進行中だった重要な研究を報告している。

1975年には、信頼できるソフトウェアに関する国際会議（International Conference on Reliable Software）[ACM75]が開催された。この会議の議事録には、プログラム検証（verification）とプログラム証明に関する非常に興味深い論文がいくつか含まれている。

プログラム正当性に関する他の重要な論文は、R.フロイド、Z.マンナとJ.ヴィレミン、R.スノーデン、そしてJ.スレ―グルとL.ノートンによって書かれたものがある[FLOY71, MANN72, SNOW72, SLAG73]。

6 プログラミングスタイルと心理的要因

構造化されたプログラムの特徴の一つは、そのスタイルである。例えば、コードの一部分をインデントすることは、構造の存在を強調し、そして、コードのセグメントの長さを１ページに制限することで、プログラムのモジュール性を強調する[MILL71]。次にプログラミング・スタイルについて書かれた２つの仕事について述べるが、これらは両方ともW.ストランクの人気の小本「The Elements of Style」（1919年）の形式とアプローチを踏襲したものである。

C.クライツバーグとB.シュナイダーマンの1972年の著書「The Element of Fortran Style」[KREI72]の目的は、Fortranプログラマの初心者に「Fortranスタイルのテクニックを用いることで、効率的で、高速で、文書化されており、エレガントで、・・・正しいプログラム」を書く方法を示すことである。

1974年、B.カーニハンとP.プラウジャーは「The Elements of Programming Style」[KERN74B]を書き、その中で他の教科書から抜粋した多くのサンプルプログラムを紹介した。彼らは、これらサンプルを議論し、改善することによって優れたプログラミング・スタイルであることを実証した。この本は、構造化プログラミングの技法を明確に認めている。この著作の非常に優れた概要は「Programming Style: Examples and Counterexample」[KERN74A]に掲載されている。

1971年、G.ワインバーグは「プログラミングの心理学（Psychology of Computer Programming）」[WEIN71]という本を書き、その本の中でプロセスにおける人間の要素に注目した。ワインバーグは、この本の主な目的は「人間活動としてのコンピュータ・プログラミング、つまりプログラミングの心理学という新しい研究分野を始めるきっかけを作ることである」と述べている。この非常に読みやすい本は、（１）プログラマと（２）その管理者に向けて、ほとんど語りかけるようなスタイルで書かれている。この本は４つの章からなる。ワインバーグの最も興味深く、革新的な議論のいくつかを以下に挙げる。

第一章：人間のパフォーマンスとしてのプログラミング: 経験豊かなプログラマが書いたプログラムを読ませることによって、プログラマに学習させたり、スキルを向上させることの望ましさ。
第二章：社会活動としてのプログラミング: 「個人のエゴの少ないプログラミング」は、プログラミング・グループ内の各プログラマが、自分のコードを仲間に読んでもらい、批評してもらうことで、より明確で優れたコードを促進する状況からなる。したがって、コードの責任と信用はグループ全体で共有される。
第三章：個人の活動としてのプログラミング: アマチュアのプログラマとプロのプログラマーの共通点と相違点、プログラミング的成功と知能、動機、特定の性格要因の関係。
第四章：プログラミング・ツール: プログラミング言語、ユーティリティ・プログラム、オペレーティング・システムの特性などがプログラマの作業に及ぼす影響。

このカテゴリで最後に取り上げるのは、L.ミラーによるH.D.ミルズへの詳細なインタビューである。ミラーの論文、「ハーラン・ミルズ：品質の心理学（Harlan Mills on the Psychology of Quality）」[MILA73]、はミラーがあらかじめ用意した「プログラムの品質と、プログラマおよびプログラミングに関連した行動的・心理的な要因との関係について」の７２個の質問に対するミルズの回答を逐語的に記録したものである。ミラーは「これら回答は、チーフ・プログラマー・チーム、トップダウン、ブロック構造化プログラミング（block-structured programming）、同僚によるコード・チェックなどの概念についてのミルズ博士の立場を表明するものである。」と述べている。質問と回答は３つの主要なカテゴリに分類されている。I. 個々のプログラマ、その性格的特徴と精神的プロセス。II. プログラミング・グループとプロジェクトの管理と組織。III.プログラマの仕事道具と一般的な仕事環境。ミルズの回答の主なポイントは以下のとおりである。

優れたプログラマの最も重要な特徴は、アルゴリズム的論理思考への適正と持続的な集中力の能力である。
トップダウン、構造化プログラミングそしてプログラムと証明の共同開発の実践は、質の高いコードを作成するために不可欠である。
チーフ・プログラマ・チームは、ほとんどすべてのプログラミング・プロジェクトで使用されるべきである。そして、チーフ・プログラマは自分のチームのプログラマが作成したコードのすべての行を読むべきである。
すべてのプログラマは、自分が書き、テストし、正しいと保証したすべてのコードに（たとえ何年後であっても）発見されたエラーについて責任を負うべきである。
対話型端末システムは、プログラミング能力よりも事務処理（テキスト編集など）能力に基づいてコストを正当化できる。さらに秘書はプログラマよりも対話型端末を操作する能力が高い。
構造化プログラミングの使用により、コードにバグが少なくなるため、デバッグツールの重要性が低くなる。
プログラマは、エラーの無いコードを開発できる静かな個人作業エリアを持つべきであるが、プロジェクトの設計段階ではグループで作業できるスペースも持つべきである。
「スーパープログラマ」は会社の副社長と同じように（給料も）扱われるべきである。

7 反対派

構造化プログラミングには反対者がいなかったという考えを持つ人が出てくるかもしれないので、以下の論文を引用する。

1972年12月、R.ドゥワークスとS.スモリアー（彼ら自身も学者である）は、「傲慢なプログラマー：ダイクストラとウェグナーは有害と考えられる」[DUWO72]と題する短いノートを書き、その中で、プログラミングのトピック（すなわち、オペレーティング・システム、コンパイラの記述など）を実用的なテーマというようりはむしろ理論的なテーマとして扱う学界を非難した。彼らはまた、「GOTO論争」やプログラム正当性手法は第三世代（現在の）プログラミング・システムとは無関係であるとして攻撃した。それから２年後、スモリアーはACM Communicationの会議で再び発言した[SMOL74]。この時は、構造化プログラミング（とその技法）を正面から攻撃し、「とんでもない流行かぶれ」と呼んだ。

この２回目の攻撃は、D.グリースの反論[GRIE74B]を呼び、彼はスモーリンの批判に答え、さらに構造化プログラミングの定義に取り掛かった。彼の定義は、以前にP.デンニングによって与えられた定義[DENN73]を拡張したものである。残念ながら、彼の定義はここに書くには長すぎるが、構造化プログラミングは「常識への回帰である」と述べて始まっている。全体として、この２ページ半のノートは、構造化プログラミングの意味について簡潔であるが優れた記述である。

翌年には、P.アブラハムス[ABRA75]とS.メッツ[METZ75]が、構造化プログラミングの欠陥、例えば、goto文の排除に対する教義的なアプローチ、Fortranに対する批判、CPT概念の盲目的な受け入れなどに対する建設的な批判を行った。これらの感情的ではない論文は、構造化プログラミングを提唱する一部の人々の教条主義的な態度に対する妥当な懸念を表明した。

興味ある読者に対する書籍詳細

構造化プログラミングの分野は、そのすべての枝分かれ分野を含めて、ここで取り上げることができるよりもはるかに多くの文研を生み出してきた。そのため、ここでは、その発展の２つの時期、すなわち、ルーツ（1965-1970）と発展（1971-1975）に焦点をあて、これらの時期において、既存の文献の本の一部のみを取り上げた。

興味ある読者が詳細を埋めるのに役立ついくつかの出版物を紹介することでこの論文を終える。そして最後に、興味のあるなしにかかわらず、これからプログラマになろうとするすべての人に、1972年のチューリング賞受賞講演『謙虚なるプログラマ（The Humble Programmer）』[DIJK72A]（Information Cassettes, Inc.,Chicago,IL 60611からオーディオ・テープでも入手可能）を読むこと（または聞くことを勧める）。

1973年12月、『プログラミングにおける革命（Revolution in Programming）』[DATA73]に関する雑誌Datamationの特集号（ゲスト編集者はD.D.マククラッケン）を出版した。この特集号には、構造化プログラミングとチーフ・プログラマ・チームを主題に概要を示す４つの非常に短い記事が含まれている。これらの記事は、計算機の活動に携わる多くの人々にとって、構造化プログラミングに初めて触れたものであり、間違いなく、この分野への関心の高まりに大きく貢献した。

1974年12月に発行されたComputing Surveysのプログラミング特集号[ACM74]（P.デンニングがゲスト編集している）には、５つの論文が含まれている。特に興味深いのは、ヴィルト[WIRT75]とクヌース[KNUT74]による構造化プログラミングの一面に関する論文である。

IEEE Computer Societyの出版物『Computer』の次の２つの特集号は、我々にとって興味深いものである。（１）ソフトウェア工学に関する1975年5月号（ゲスト編集者R.イエ）[COMP75A]と（２）構造化プログラミングに関する1975年6月号（ゲスト編集者W.ロス）[COMP75B]。これらの各号には、優れた紹介記事が掲載されている。

もう一つの特集、IEEE Transactions on Computersの２５周年記念号には、特に興味深い２つの論文が掲載されている。一つ目はP.ウェグナーによるプログラミング言語に関するもの[WEGP76]、そして２つめがB.ベームによる「ソフトウェア工学（Software Engineering）」[BOEH76]である。

1975年3月、IEEE Computer SocietyはR.イエ編集による新しい季刊誌『IEEE Transactions on Software Engineering』[IEEE75]を出版し始めた。この出版物（1977年に月刊化）に掲載された論文のほとんどは、構造化プログラミングに密接に関連したものである。

そして最後に、読者もおそらくお気づきのように、ACMの２つの月刊誌、『Communications』と『Sigplan Notices』には、このテーマに関する論文が豊富に掲載されている。

参考文献

ABRA75: Abrahams, P., "Structured Programming Considered Harmful", Sigplan Notices, (10, 4), 1975, pp. 13--24.
ACM72: Proceedings of an ACM Conference on Proving Assertions About Programs, Sigplan Notices, (7, 1) and Sigact News, (14), Jan. 1972, 211 pp. + iv.
ACM74: ACM Computing Surveys, Special Issue on Programming, P. Denning (ed), (6, 4), Dec. 1974, 113 pages.
ACM75: Proceedings of International Conference on Reliable Software, Sigplan Notices, (10, 6), June, 1975, 567 pp. + vii.
ASHC71: Ashcroft, E. and Manna, Z., "The Translation of goto Programs to While Programs", Proc. of IFIP Cong. 71, Vol. 1, 1971, pp. 250--255.
BAKE71: Baker, F. T., "The Chief Programmer Team Experiment", IBM Technical Information Exchange Forum, Spring 1971.
BAKE72: Baker, F. T., "Chief Programmer Team Management of Production Programming", IBM Systems Journal, (11, 1), 1972, pp. 56--71.
BAKE75: Baker, F. T., "Structured Programming in a Production Environment", Sigplan Notices, (10, 6), 1975, pp. 172--185.
BOCH73: Bochmann, G. V., "Multiple Exits Froma Loop Without the Goto", CAM, (16, 7), 1973, pp. 443--444.
BOEH76: Boehm, B. W., "Software Engineering", IEEETC, (C-25, 12), Dec. 1976, pp. 1226--1241.
BOHM66: Bohm, C. and Jacopini, G., "Flow Diagrams, Turing Machines, and Languages With Only Two Formation Rules", CACM, (9, 5), 1966, pp. 366--371.
BOWL77: Bowles, K. L., Microcomputer Problem Solving Using Pascal, Springer-Verlag, 1977.
BRUN72: Bruno, J. and Steiglitz, K., "The Expression of Algorithms By Charts", JACM, (19, 3), July 1972, pp. 517--525.
COMP75A: Computer-Special Issue on Software Engineering, R. Yeh (ed), (8, 5), May 1975.
COMP75B: Computer-Special Issue on Structured Programming, W. Ross (ed), (8, 6), June 1975.
CONW76A: Conway, R., Gries, D. and Zimmerman, E. C., A Primer on Pascal, Winthrop, 1976.
CONW76B: Conway, R. and Gries, D., Primer on Structured Programming, Winthrop, 1976.
DAHL72: Dahl, O. J., Dijkstra, E. W. and Hoare, C. A. R., Structured Programming, Academic Press, 1972.
DATA73: Special Issue on Structured Programming. Datamation, (19, 12), 1973.
DENN73: Denning, P., "Is it Not Time to Define Structured Programming?" Sigplan Notices, Oct. 1973.
DIJK65: Dijkstra, E. W., "Programming Considered as a Human Activity", Proc. of IFIP Cong., May 1965, pp. 213--217.
DIJK68A: Dijkstra, E. W., "Go To Statement Considered Harmful", Letters to the Editor, CACM, (11, 3), 1968, pp. 147--148.
DIJK68B: Dijkstra, E. W., "A Constructive Approach to the Problem of Program Correctness", BIT, (8), 1963, pp. 174--186.
DIJK69: Dijkstra, E. W., Notes on Structured Programming, T. H. E. EWD249, August 1969.
DIJK72A: Dijkstra, E. W., "The Humble Programmer", CACM, (15, 10), 1972, pp. 859--865.
DIJK72B: Dijkstra, E. W., "Notes on Structured Programming", Structured Programming, Academic Press, New York, 1972, pp. 1--82.
DIJK75: Dijkstra, E. W., "Correctness Concerns and Among Other Things Why They Are Resented", Sigplan Notices, (10, 6), 1975, pp. 546--551.
DIJK76: Dijkstra, E. W., A Discipline of Programming, Prentice-Hall, 1976.
DUWO72: DuWorks, R. J. and Smoliar, S. W., "The Arrogant Programmer: Dijkstra and Wegner Considered Harmful", SIGCSE Bulletin, (4, 4), Dec. 1972, pp. 19--21.
ELSP72: Elspas, B., Levitt, K. N., Waldinger, R. J., and Waksman, A., "An Assessment of Techniques for Proving Program Correctness", Computing Surveys, (4, 2), 1972, pp. 97--147.
FLOY67: Floyd, R. W., "Assigning Meanings to Programs", Proc., Symp. in Appl. Math., Vol. 19, AMS, 1967, pp. 19--32.
FLOY71: Floyd, R. W., "Toward Interactive Design of Correct Programs", Proceedings of IFIP Cong. 71, Vol. 1, pp. 7--10.
FRIE77: Friedman, F. L. and Koffman, E. B., Problem Solving and Structured Programming in Fortran, Addison-Wesley, 1977.
FRID74: Friedman, D. and Shapiro, S., "A Case for While-Until", Sigplan Notices, (9, 7), July 1974, pp. 7--14.
GELL76: Geller, D. P. and Freedman, D. P., Structured Programming in APL, Winthrop, 1976.
GRIE74A: Gries, D., "What Should We Teach in an Introductory Programming Course", ACMSIGCSE Bulletin, Feb. 1974, pp. 81--89.
GRIE74B: Gries, D., "On Structured Programming - A Reply to Smoliar", CACM, (17, 11), 1974, pp. 655--657.
HAIN73: Haines, E. C., "AL: A Structured Assembly Language", Sigplan Notices, (8, 1), 1973, pp. 15--20; (8, 4), 1973, pp. 16--21.
HANS73: Hansen, P. B., Operating System Principles, Prentice-Hall, 1973.
HOAR61: Hoare, C. A. R., "Algorithm 65, FIND", CACM, (4, 7), July 1961, p. 321.
HOAR69: Hoare, C. A. R., "An Axiomatic Basis for Computer Programming", CACM, (12, 10), 1969, pp. 576--583.
HOAR71: Hoare, C. A. R., "Proof of a Program: FIND", CACM, (14, 1), 1971, pp. 39--45.
HOAR73B: Hoare, C. A. R. and Wirth, N., "An Axiomatic Definition of the Programming Language, Pascal", Acta Informatica, (2), 1973, pp. 335--355.
HORO75: Horowitz, E., "Fortran: Can It Be Structured - Should it Be", Computer, (8, 6), 1975, pp. 30--37.
HOPK72: Hopkins, M., "A Case for the Goto", Sigplan Notices, (7, 11), 1972, pp. 59--62.
IBM71: IBM, Chief Programmer Teams, Principles and Procedures, Report FSC 71--5108, June 1971.
IEEE75: IEEE Transactions on Software Engineering (SE-1, 1) March 1975.
JENS75: Jensen, K. and Wirth, N., Pascal User Manual and Report, 2nd Ed., Springer-Verlag, 1975.
JUDD70: Judd. R., "Practical Modular Programming", Computer Bulletin, (14, 1), 1970, pp. 4--7.
KERN74A: Kernighan, B. W. and Plauger, P. J., "Programming Style: Examples and Counterexamples", Computing Surveys, (6, 4), 1974), pp. 309--319.
KERN74B: Kernighan, B. W. and Plauger, P. J., The Elements of Programming Style, McGraw-Hill, New York, 1974.
KIEB75: Kieburtz, R. B., Structured Programming and Problem Solving with Algol W, Prentice-Hall, 1975.
KNUT74: Knuth, D. E., "Structured Programming with Gotos", Computing Surveys, (6, 4), Dec. 1974.
KOSA74: Kosaraju, S. A., "Analysis of Structured Programs", Journal of Computer and System Sciences, (9, 3), Dec. 1974.
KRE172: Kreitzberg, C. B. and Shneiderman, B., The Elements of Fortran Style, Harcourt Brace Jovanovich, 1972.
LEAV72A: Leavenworth, B. M., (Ed.) "The Go To Controversy", Sigplan Notices, (7, 11), Nov. 1972, pp. 53--91.
LEAV72B: Leavenworth, B. M., "Programming With(out) the Goto", Sigplan Notices, (7, 11), 1972, pp. 54--58.
LEDG75: Ledgard, H. F. and Marcotty, M., "A Genealogy of Control Structures", CACM, (18, 11), 1975, pp. 629--639.
LIM75: Lim, A. L. and Lewis, G. R., "Towards Structured Programming in APL," Computer Journal, (18, 2), 1975, pp. 140--143.
MANN72: Manna, Z. and Vuillemin, J., "Fixpoint Approach to Theory of Computation", CACM, (15, 7), July 1972, pp. 528--536.
MART73: Martin, J., "The 'Natural' Set of Basic Control Structures", Sigplan Notices, (8, 12), 1973, pp. 5--14.
MCCL75: McClure, C., "Structured Programming in Cobol", Sigplan Notices, (10, 4), 1975, pp. 25--33.
MCCR76: McCracken, D. D., A Simplified Guide to Structured Cobol Programming, Wiley, 1976.
MEIS75: Meissner, L. P., "On Extending Fortran Control Structures to Facilitate Structured Programming", Sigplan Notices, (10, 9), 1975, pp. 19--29.
METZ75: Metz, S., "More on Structured Programming", CACM, (18, 10), 1975, pp. 600--601.
MILA73: Miller, L. A., Harlan Mills on "The Psychology of Quality';, IBM RC 3779, May 1973.
MILL71: Mills, H. D., "Top Down Programming in Large Systems", Debugging Techniques in Large Systems, B. Rustin (ed), Prentice-Hall, 1971.
MILL72: Mills, H. D., Mathematical Foundations for Structured Programming, IBM Report FSC 72--6013, 1972.
MILL73: Mills, H. D., How to Write Correct Programs and Know It, IBM Report FSC 73--5008, Jan. 1973.
MILL75: Mills, H. D., "How to Write Correct Programs and Know It", Sigplan Notices, (10, 6), 1975, pp. 363--370.
MILR73A: Miller, E. F. Jr., A Compendium of Language Extensions to Support Structured Programming, Program Validation Project Report, RN-42, General Research Corp., Jan. 1973.
NASS73: Nassi, I. and Shneiderman, B., "Flowchart Techniques for Structured Programming", Sigplan Notices, (8, 8), 1973, pp. 12--26.
NAUR66: Naur, P., "Proof of Algorithms by General Snapshots", BIT, (6), 1966, 310--316.
NAUR69: Naur, P., "Programming by Action Clusters", BIT, (9), 1969, pp. 250--258.
OGDI72: Ogdin, J., "The Mongolian Hordes versus Superprogrammer", Infosystems, Dec. 1972, pp. 20--24.
PETE73: Peterson, W. W., Kasami, T., and Tokura, N., "On the Capabilities of While, Repeat, and Exit Statements", CACM, (16, 8), 1973, p. 503--512.
PHIL77: Philippakis, A. and Kazimier, L., Structured Cobol, McGraw-Hill, 1977.
PUG77: Pascal Users Group. Membership Roster. Pascal Newsletter, A. Mickel (Ed.), May 1977.
RICE68: Rice, J. R., "The Goto Statement Reconsidered", Letter to the Editor. CACM, (11, 8), 1968, p. 538.
SHEL77: Shelly, G. and Cashman, T., Introduction to Computer Programming: Structured Cobol, Anaheim Publ. Co., 1977.
SITE72: Sites, R. L., Algol W Reference Nanual, Stanford Univ., Dept. of Comp. Sci. Rept STAN-CS-71--230, Feb. 1972.
SLAG73: Slagle, J. R. and Norton, L. M., "Experiments with an Automatic Theorem Prover. . . .", CACM, (16, 11), 1973, pp. 682--688.
SMOL74: Smoliar, S. W., "On Structured Programming", CACM, (17, 5), 1974, p. 294.
SNOW72: Snowden, R. A., "Pearl: An' Interactive System for the Preparation and Validation of Structured Programs", Sigplan Notices, (7, 3), 1972, pp. 9--26.
SULL75: Sullivan, J. E., "Extending PL/I For Structured Programming", Computer Languages, (1), 1975, pp. 29--43.
URSC75: Urschler, G., "Automatic Structuring of Programs", IBM Jour. of Res. Dev., March 1975, pp. 181--194.
WEGN73: Wegner, E., "Tree-Structured Programs", CACM, (16, 11), 1973, pp. 704--705.
WEGP76: Wegner, P., "Programming Languages - The First 25 Years", IEEE-TC, (C-25, 12), Dec. 1976, pp. 1207--1225.
WEIN71: Weinberg, G., The Psychology of Computer Programming, Van Nostrand Reinhold, 1971.
WEIN73: Weinberg, G., Yasukawa, N. and Marcus, R., Structured Programming in PL/C, Wiley, 1973.
WEIN75: Weinberg, G., et al., "If-Then-Else considered Harmful", Sigplan Notices, (10, 8), 1975, pp. 34--44.
WHIT75: White, J. R. and Presser, L., "A Structured Language for Compiler Construction", Computer Journal, (18, 1), 1975, pp. 34--42.
WIRT66: Wirth, N. and Hoare, C. A. R., "A Contribution to the Development of Algol", CACM, (9, 6), Jun
WIRT66: Wirth, N. and Hoare, C. A. R., "A Contribution to the Development of Algol", CACM, (9, 6), June 1966, pp. 413--432.
WIRT68: Wirth, N., "PL360, A Programming Language for the IBM 360", JACM, (15, 1), 1968, pp. 37--74.
WIRT71A: Wirth, N., "The Programming Language, Pascal", Acta Informatica, (1, 1), 1971, pp. 35--63.
WIRT71B: Wirth, N., "Program Development by Stepwise Refinement", CACM, (14, 4), 1971, pp. 221--227.
WIRT73A: Wirth, N., Systematic Programming, Prentice Hall, 1973.
WIRT73B: Wirth, N., The Programming Language, Pascal (Revised Report), Berichte der Fachgruppe Computer-Wissenschaften, ETH, Zurich (5), 1973.
HOAR73A: Hoare, C. A. R., "Proof of a Structured Program: The Sieve of Eratosthenes", Computer Journal, (15), 1973.
WIRT74: Wirth, N., "On the Composition of Well-Structured Programs", Computing Surveys, Dec. 1974, pp. 247--259.
WIRT76: Wirth, N., Algorithms + Data Structures = Programs, Prentice Hall, 1976.
WULF71A: Wulf, W. A., "Programming Without the Goto", Information Proceeding 71, C. V. Freiman (ed), Proceeding of IFIP 1971 Congress.
WULF71B: Wulf, W. A., Russell, D. B., and Habermann, A. N., "Bliss: A Language for Systems Programming", CACM, (14, 12), 1971, pp. 780--790.
WULF71C: Wulf, W. A., et al., "Reflections on a Systems Programming Language", Proc. of SIGPLAN Symp. on Systems Implementation Languages, Oct. 1971.
WULF72: Wulf, W. A., "A Case Against the Goto", SIGPLAN Notices, (7, 11), 1972, pp. 63--69.
YOUR74: Yourdon, E. and Abbott, R., "Programmers are Paid to Program: Enter Program Librarian", Infosystems, Dec. 1974, pp. 28--32.
ZAHN74: Zahn, C., "A Control Statement for Natural Top-Down Structured Programming", Symposium on Programming Languages, Paris, 1974.