「構造化プログラミング」の版間の差分
削除された内容 追加された内容
m →歴史 |
|||
(同じ利用者による、間の3版が非表示) | |||
2行目:
{{プログラミング・パラダイム}}
'''構造化プログラミング'''(こうぞうかプログラミング、{{lang-en-short|''structured programming''}})とは、[[コンピュータプログラム]]上での処理の流れを明瞭化かつ平易化するための手法である。一般的には順接、分岐、反復の三つの'''制御構造'''(''control structures'')によって処理の流れを記述することであると認識されている<ref>{{Cite web|title=構造化プログラミングとは - IT用語辞典|url=http://e-words.jp/w/%E6%A7%8B%E9%80%A0%E5%8C%96%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0.html|website=IT用語辞典 e-Words|accessdate=2020-06-01|language=ja}}</ref><ref>{{Cite web|title=構造化プログラミング - 意味・説明・解説 : ASCII.jpデジタル用語辞典|url=https://yougo.ascii.jp/caltar/%E6%A7%8B%E9%80%A0%E5%8C%96%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0|website=yougo.ascii.jp|accessdate=2020-06-01}}</ref>。[[ブロック (プログラミング)|コードブロック]]と[[サブルーチン]]の仕組みも加えられることがある。制御構造は'''制御構文'''、構造化文(''structured statement'')または制御フロー文(''control flow statement'')とも呼ばれる。
このプログラミング手法の普及に貢献したのは、計算機科学者[[エドガー・ダイクストラ]]による1968年の[[Association for Computing Machinery|ACM]]機関紙への投書「''Go To Statement Considered Harmful''」と言われている。しかし同じくダイクストラが、1969年の[[NATO]]ソフトウェア工学会議で発表した論文「''Structured Programming''」との混同を招いてこちら側の名称で知られるようになった。国内外の多くの書籍において構造化プログラミングは、制御構
{{main|ミルズの構造化プログラミング}}[[制御構造|制御構文]](''control structures'')とは、[[goto文]]によるフロー分岐やループ表現を、[[if文]]による選択構文や[[while文]]による反復構文に置き換えるためのプログラム記法を意味している。ラベル先にジャンプするというgoto文の機能を、if文やwhile文は「特定の
▲== 制御構造とは ==
▲{{main|ミルズの構造化プログラミング}}[[制御構造]](''control structures'')とは、[[goto文]]によるフロー分岐やループ表現を、[[if文]]による選択構文や[[while文]]による反復構文に置き換えるためのプログラム記法を意味している。ラベル先にジャンプするというgoto文の機能を、if文やwhile文は「特定のプログラム部分だけを実行する」という概念に置き換えている。goto文によるフロー分岐用途は、データの照合/比較結果によって次に実行するプログラム部分の選択と、データの照合/比較結果が任意条件を満たしてる間だけ繰り返すプログラム部分の反復という二つのパターンに集約されることが経験則で知られていたので、これを専用の記号で形式化したのが制御構造であった。
▲上述の「プログラム部分」とは命令コード(''instruction code'')のまとまりを意味しており、サブプログラム(''subprogram'')と総称されている。サブプログラムとは、[[ステートメント]](''statement'')[[コードブロック]](''code block'')[[サブルーチン]](''subroutine'')の総称である。ステートメントは命令コードの一行を意味する。コードブロックは一行以上のステートメントをまとめたものである。サブルーチンは一行以上のステートメントまたは一個以上のコードブロックを内包する。サブプログラムは直列状または入れ子状に配置される。その実行順序を決定するものが制御構造であり、以下の三つがある。
▲#'''順次'''(''sequence'')サブプログラムを順々に実行する。
▲#'''選択'''(''selection'') 条件式が導出した状態に従い、次に実行するサブプログラムを選択して分岐する。
▲#'''反復'''(''repetition'')条件式が導出した特定の状態の間、サブプログラムを繰り返し実行する。
<br />[[ファイル:Structured_program_patterns.png|中央|サムネイル|700x700ピクセル|順次、選択、反復の描写図(青はNSダイアグラム、緑はフローチャート)]]▼
▲
<br />制御構造の登場は1960年公開のプログラミング言語「[[ALGOL|ALGOL60]]」まで遡る事ができる。1966年に[[コラド・ベーム]]らが順次・選択・反復のフロー万能性を数学的に証明したが、それはあくまで論理的研究だった。1968年の[[エドガー・ダイクストラ|ダイクストラ]]の投書によって制御構造に対する関心は大きく高まった。ただしその物議を醸すタイトル(goto文は有害)を付けたのは[[ニクラウス・ヴィルト]]であった。1970年代、制御構造の普及を重視していたIBM社の[[ハーラン・ミルズ]]は、1969年にダイクストラが発表してこれも反響を得ていた論文タイトル(構造化プログラミング)を自社の技術セミナーマーケティングに活用する
== 構造化設計 ==
[[ファイル:6 Decomposition Structure.svg|サムネイル|構造化設計の一例]]
上述の[[制御構文]]をコーディング視点の下流工程テクニックとすると、構造化設計(''structured design'')はプログラムデザイン視点の上流工程テクニックであり、こちらも構造化プログラミングと呼ばれるものである。構造化設計では概して、'''サブルーチン'''(''subroutine'')と'''モジュール'''(''module'')が主要な役割を果たす事になる。モジュールはプログラム規模の拡大で増え続けるサブルーチンとデータをグループ化して管理しやすくするために、1960年代に考案された機能である。モジュールは任意のサブルーチン群とデータ群の双方をひとまとめにするプログラム要素であり、[[サブルーチン]]階層と[[モジュール]]の組み合わせでプログラム全体を構造化するのが構造化設計である。[[凝集度]]や[[結合度]]といった考え方もここから生まれている。
構造化設計は総称用語である。[[モジュール]]を重視したプログラム開発は1960年代後半から研究が始まっており、コンピュータソフトウェア界隈のエキスパートたちによって、いずれも構造化(''structured'')が接頭辞につく数々のテクニックが発表されている。1975年発表「構造化設計 -structured design(SD)」、1978年発表「構造化分析 -structured analysis(SA)」、1981年発表「構造化分析設計技法 -[[構造化分析設計技法|structured analysis and design technique]](SADT)」、1980年代発表「構造化体系分析設計手法 -[[SSADM|structured systems analysis and design method]](SSADM)」、1989年発表「モダン構造化分析 -modern structured analysis」などが広く普及している。著名な専門家としては、グレンフォード・マイヤーズ、ラリー・コンスタンティン、[[エドワード・ヨードン]]、[[トム・デマルコ]]などがいる。
この構造化設計と[[エドガー・ダイクストラ|ダイクストラ]]の構造化プログラミングの違いは、前者がモジュールを普通にサブルーチンとデータの構成体として扱っているのに対して、後者はモジュールを抽象体として扱おうとしている点である。後者では、段階的に抽象化した各モジュールの階層的な連結と、抽象データ構造と抽象ステートメントを連携させる共同詳細化といった考え方が提示されており、この詳細については後節で述べられる。ダイクストラが提唱した「抽象化」はその[[アバンギャルド|前衛]]さから1970年代を通して理解を得られることはなく、発案者本来の構造化プログラミングは上流工程視点からも普及することはなかった。
== 歴史 ==
'''第一幕'''
構造化プログラミングの誕生は、1960年代から浮上した[[ソフトウェア危機]]問題と密接に結びついている。ソフトウェア危機とはコンピュータ性能の進化に伴うソフトウェア要求度の高まりが、プログラムサイズの際限無い肥大化と複雑化を招き、近いうちに現実的な期間内でのプログラム開発が不可能になるだろうとする悲観的予測である{{#tag:ref|[[ソフトウェア危機]]の始まりと構造化プログラミングの歴史について<ref name="the_science_of_programming"/>の第23章に詳しい。|group="注釈"}}。実際に1960年代のソフトウェア開発現場では仕様不一致、納期遅れ、予算超過といった事態が頻発していた<ref name="the_science_of_programming">{{cite book |first=D.|last=グリース |authorlink=:en:David Gries|title=プログラミングの科学 |translator=筧捷彦 |publisher=培風館 |year=1991 |isbn=4563007943}}</ref>。当時のプログラムは[[goto文]]を多用するタコ足[[フローチャート]]によるものが大半だったので<ref name="program_design_chap6sec1">山崎利治, "流れ図", ''プログラムの設計'', 共立出版, 1990, pp.110-113. ISBN 4320023781</ref>、すぐに[[スパゲティコード]]化することが多く、複雑怪奇なジャングルフロー図と化しているものも珍しくなかった<ref name="structured_programming_with_go_to_statements">{{Cite journal|last=Knuth|first=D. E.|year=1974|title=Structured Programming with go to Statements Computing Surveys|journal=ACM, New York, NY, USA|volume=6|number=4|pages=261-301|id={{citeseerx|10.1.1.103.6084}}|authorlink=ドナルド・クヌース}}</ref>。1959年に計算機科学者[[ハインツ・ツェマネク]]は、goto文の多用に警鐘を鳴らす論文を発表している。1960年に公開されたプログラミング言語「[[ALGOL|ALGOL60]]」は、BEGINとENDで区切られた[[コードブロック]]を制御するIF選択文とFOR反復文を初めて提供していた。1966年に計算機科学者[[コラド・ベーム]]とジュゼッペ・ヤコピーニは、あらゆるフローチャートは順次・選択・反復の組み合わせで表現できることの数学的証明をし、これは[[構造化定理|ベームとヤコピーニの証明]]と呼ばれた<ref name="flow_diagrams_turing_machines_and_languages_with_only_two_formation_rules">{{Cite journal|last=Böhm|first=C.|last2=Jacopini|first2=G|year=1966|title=Flow Diagrams, Turing Machines And Languages With Only Two Formation Rules|journal=Communications of the ACM|volume=9|issue=5|pages=366-371|id={{citeseerx|10.1.1.119.9119}}|journl=ACM, New York, NY, USA}}</ref>。計算機科学者[[ドナルド・クヌース]]は、これらの潮流を構造化文(''structured statement'')の第一幕と定義した<ref name="structured_programming_with_go_to_statements" />。▼
▲構造化プログラミングの誕生は、1960年代から浮上した[[ソフトウェア危機]]問題と密接に結びついている。ソフトウェア危機とはコンピュータ性能の進化に伴うソフトウェア要求度の高まりが、プログラムサイズの際限無い肥大化と複雑化を招き、近いうちに現実的な期間内でのプログラム開発が不可能になるだろうとする悲観的予測である{{#tag:ref|[[ソフトウェア危機]]の始まりと構造化プログラミングの歴史について<ref name="the_science_of_programming"/>の第23章に詳しい。|group="注釈"}}。実際に1960年代のソフトウェア開発現場では仕様不一致、納期遅れ、予算超過といった事態が頻発していた<ref name="the_science_of_programming">{{cite book |first=D.|last=グリース |authorlink=:en:David Gries|title=プログラミングの科学 |translator=筧捷彦 |publisher=培風館 |year=1991 |isbn=4563007943}}</ref>。当時のプログラムは[[goto文]]を多用するタコ足[[フローチャート]]によるものが大半だったので<ref name="program_design_chap6sec1">山崎利治, "流れ図", ''プログラムの設計'', 共立出版, 1990, pp.110-113. ISBN 4320023781</ref>、すぐに[[スパゲティコード]]化することが多く、複雑怪奇なジャングルフロー図と化しているものも珍しくなかった<ref name="structured_programming_with_go_to_statements">{{Cite journal|last=Knuth|first=D. E.|year=1974|title=Structured Programming with go to Statements Computing Surveys|journal=ACM, New York, NY, USA|volume=6|number=4|pages=261-301|id={{citeseerx|10.1.1.103.6084}}|authorlink=ドナルド・クヌース}}</ref>。1959年に計算機科学者[[ハインツ・ツェマネク]]は、goto文の多用に警鐘を鳴らす論文を発表している。1960年に公開されたプログラミング言語「[[ALGOL|ALGOL60]]」は、BEGINとENDで区切られた[[コードブロック]]を制御するIF選択文とFOR反復文を初めて提供していた。計算機科学者[[ニクラウス・ヴィルト]]はこれらを構造化文(structured statement)と呼んだ<ref name="systematic_programming">N.ヴィルト, ''系統的プログラミング/入門'', 野下浩平, 筧捷彦, 武市正人 訳, 近代科学社, 1978. </ref>。1966年に計算機科学者[[コラド・ベーム]]とジュゼッペ・ヤコピーニは、あらゆるフローチャートは順次・選択・反復の組み合わせで表現できることの数学的証明をし、これは[[構造化定理|ベームとヤコピーニの証明]]と呼ばれた<ref name="flow_diagrams_turing_machines_and_languages_with_only_two_formation_rules">{{Cite journal|last=Böhm|first=C.|last2=Jacopini|first2=G|year=1966|title=Flow Diagrams, Turing Machines And Languages With Only Two Formation Rules|journal=Communications of the ACM|volume=9|issue=5|pages=366-371|id={{citeseerx|10.1.1.119.9119}}|journl=ACM, New York, NY, USA}}</ref>。計算機科学者[[ドナルド・クヌース]]は、これらの潮流を構造化文
'''第二幕'''
1968年、計算機科学者[[エドガー・ダイクストラ]]の[[Association for Computing Machinery|ACM]]機関紙への投書「Go To Statement Considered Harmful<ref name="go_to_statement_considered_harmful">{{Cite journal|id={{citeseerx|10.1.1.132.875}} |author=E. Dijkstra |authorlink=エドガー・ダイクストラ |title=Go To Statement Considered Harmful |journal=Communications of the ACM |volume=11 |issue= 3 |year=1968 |pages= 147-148 }}</ref>」は、その物議を醸す題名でソフトウェア界隈にいわゆるgoto文論争を巻き起こすことになった<ref name="bit1975_go_to_statement_considered_harmful">{{cite|author=E.W.ダイクストラ|authorlink=エドガー・ダイクストラ|title=GO TO 論争:第1部 go to 文有害説|translator=木村泉|journak=bit|volume=7|issue=5|year=1975|pages=6-9|publisher=共立出版}}</ref><ref name="bit1975_goto_controversy">{{cite |editor=B.リーヴェンワス編 |title=GO TO 論争:第2部 GO TO 論争 |translator=木村泉 訳 |journal=bit |volume=7 |issue=5 |year=1975 |pages=10-26 |publisher=共立出版 }}</ref>。goto文論争は当時のプログラマたちに構造化文をより強く意識させることにも貢献している<ref name="bit1975_explanation">木村泉, "GO TO 論争:第3部 解説", ''bit'', Vol.7, Issue 5, 1975, pp.27-39, 共立出版.</ref>。これを構造化文の第二幕と定義したクヌースは「第二幕はそのムーブメントの大きさによって多くの人にとっての第一幕になった」と自著で述べた<ref>有澤誠訳『文芸的プログラミング』p.45</ref>。1968年度開催の[[北大西洋条約機構|NATO]]ソフトウェア工学会議で[[ソフトウェア危機]]は正式な用語になり<ref name="software_engineering_conferences1968">[http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF B. Randell and J.N. Buxton, (Eds.), ''Software Engineering'', NATO Scientific Affairs Division, Brussels, Belgium, 1969.]</ref>計算機科学分野共通の懸案事項になった<ref name="from_craft_to_scientific_discipline" />。翌1969年度開催の[[北大西洋条約機構|NATO]]ソフトウェア工学会議においてダイクストラは「Structured Programming<ref name="structured_programming" />」と名付けた論文を寄稿した。これが「構造化プログラミング」の正式な初出である。その内容はソフトウェア危機解決策としての[[正当性 (計算機科学)|ソフトウェア正当性]][[プログラム検証|検証技術]]の確立に焦点を当てたものであり、[[トップダウン設計とボトムアップ設計|トップダウン設計]]、[[抽象化 (計算機科学)|抽象化]]、[[モジュール|モジュール化]]、共同詳細化([[抽象データ型]]の原型)といったプログラム全体の
'''第三幕'''
▲1968年、計算機科学者[[エドガー・ダイクストラ]]の[[Association for Computing Machinery|ACM]]機関紙への投書「Go To Statement Considered Harmful<ref name="go_to_statement_considered_harmful">{{Cite journal|id={{citeseerx|10.1.1.132.875}} |author=E. Dijkstra |authorlink=エドガー・ダイクストラ |title=Go To Statement Considered Harmful |journal=Communications of the ACM |volume=11 |issue= 3 |year=1968 |pages= 147-148 }}</ref>」は、その物議を醸す題名でソフトウェア界隈にいわゆるgoto文論争を巻き起こすことになった<ref name="bit1975_go_to_statement_considered_harmful">{{cite|author=E.W.ダイクストラ|authorlink=エドガー・ダイクストラ|title=GO TO 論争:第1部 go to 文有害説|translator=木村泉|journak=bit|volume=7|issue=5|year=1975|pages=6-9|publisher=共立出版}}</ref><ref name="bit1975_goto_controversy">{{cite |editor=B.リーヴェンワス編 |title=GO TO 論争:第2部 GO TO 論争 |translator=木村泉 訳 |journal=bit |volume=7 |issue=5 |year=1975 |pages=10-26 |publisher=共立出版 }}</ref>。goto文論争は当時のプログラマたちに構造化文をより強く意識させることにも貢献している<ref name="bit1975_explanation">木村泉, "GO TO 論争:第3部 解説", ''bit'', Vol.7, Issue 5, 1975, pp.27-39, 共立出版.</ref>。これを構造化文の第二幕と定義したクヌースは「第二幕はそのムーブメントの大きさによって多くの人にとっての第一幕になった」と自著で述べた<ref>有澤誠訳『文芸的プログラミング』p.45</ref>。1968年度開催の[[北大西洋条約機構|NATO]]ソフトウェア工学会議で[[ソフトウェア危機]]は正式な用語になり<ref name="software_engineering_conferences1968">[http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF B. Randell and J.N. Buxton, (Eds.), ''Software Engineering'', NATO Scientific Affairs Division, Brussels, Belgium, 1969.]</ref>計算機科学分野共通の懸案事項になった<ref name="from_craft_to_scientific_discipline" />。翌1969年度開催の[[北大西洋条約機構|NATO]]ソフトウェア工学会議においてダイクストラは「Structured Programming<ref name="structured_programming" />」と名付けた論文を寄稿した。これが「構造化プログラミング」の正式な初出である。その内容はソフトウェア危機解決策としての[[正当性 (計算機科学)|ソフトウェア正当性]][[プログラム検証|検証技術]]の確立に焦点を当てたものであり、[[トップダウン設計とボトムアップ設計|トップダウン設計]]、[[抽象化 (計算機科学)|抽象化]]、[[モジュール|モジュール化]]といったプログラム全体の構造設計手法が提唱されていた。goto文回避など構造化文に関する事柄は数行に留まっていたが{{#tag:ref|"statements transferring control to labelled points" という言葉で一応 goto 文に触れている<ref name="structured_programming" />|group="注釈"}}、goto文論争に熱心なプログラマたちの間ではこの論文を昨年の投書の延長と見る向きも少なからず存在していた。後年のダイクストラは構造化プログラミングという言葉を作った際に二つの失敗をしたと述べている。商標登録しなかった事と、厳密な定義化を避けた事である<ref name="also_speech_dijkstra">和田英一, "ダイクストラかく語りき", ''bit'', Vol.9, Issue 1, 1977, pp.4-6, 共立出版. </ref><ref name="from_craft_to_scientific_discipline">{{cite |naid=110002753409 |authir=E.W.ダイクストラ |title=プログラミング−工芸から科学へ |journal=情報処理 |volume=18 |number=12 |year=1977 |page=1248-1256 |publisher=情報処理学会 }}</ref>。
'''終幕'''
後年、ダイクストラは自身が作った構造化プログラミングという言葉に不快感を示して避けるようになった<ref name="three_days_with_dijkstra">中山晴康, "ダイクストラ教授との3日間", ''bit'', Vol.9, Issue 1, 1977, pp.7-9, 共立出版. </ref>。この言葉を作った時、彼はプログラミングが手工芸から科学へ発展することを期待していた<ref name="also_speech_dijkstra" />。しかし構造化プログラミングという言葉は実利を求めるために使われるようになった<ref name="three_days_with_dijkstra" />。次のような逸話がある。ソフトウェア技術者[[エドワード・ヨードン]]の事務所にセミナー依頼の電話がかかってきた。プロジェクトメンバー全員に構造化プログラミングを1日で叩きこんで欲しいという内容である。それが終わったらプロジェクト期間を半分にするという。その理由は「構造化プログラミングは生産性を2倍にするという触れ込みですから」であった<ref name="managing_the_structured_techniques">Edward Nash Yourdon, ''構造化手法によるソフトウェア開発'', 黒田純一郎, 渡部研一 訳, 日経BP社, 1987. </ref>。▼
▲後年、ダイクストラは自身が作った構造化プログラミングという言葉に不快感を示して避けるようになった<ref name="three_days_with_dijkstra">中山晴康, "ダイクストラ教授との3日間", ''bit'', Vol.9, Issue 1, 1977, pp.7-9, 共立出版. </ref>。この言葉を作った時、彼はプログラミングが手工芸から科学へ発展することを期待していた<ref name="also_speech_dijkstra" />。しかし構造化プログラミングという言葉は実利を求めるために使われるようになった<ref name="three_days_with_dijkstra" />。次のような逸話がある。
== ダイクストラの構造化プログラミング ==
34 ⟶ 48行目:
「Structured Programming」という用語自体を生み出したのは計算機科学者[[エドガー・ダイクストラ]]であり、1969年のNATOソフトウェア工学会議で発表された論文が初出とされている。彼は2001年のノートで自分が作り出した「構造化プログラミング」という用語は結局異なる解釈で持ち去られてしまったと述べている<ref>{{Cite web|url=https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1308.html|title=What led to “Notes on Structured Programming”|accessdate=2020-1|publisher=}}</ref>。
ダイクストラが提唱した構造化プログラミングは、[[正当性 (計算機科学)|プログラム正当性]][[プログラム検証|検証]]技術の確立を
=== 1968年の投書「goto文は有害」 ===
54 ⟶ 68行目:
詳細化の際には'''共同詳細化'''(''joint-refinement'')という考え方が示されている。これは抽象データ構造の詳細化と共にそれを扱う抽象ステートメントを同時に詳細化し、それを1つのプログラムテキストのユニットに分離するというものである。このユニットをダイクストラは真珠(pearl)と呼んだ。また、抽象的な真珠が1段階具体的な真珠に依存し、その真珠がさらに具体的な真珠に依存していったものをネックレスに例えた。そしてネックレスの上部は下部に関わらず正しさを証明することができ、また下部を取り替えることでプログラムのバリエーションを労力をかけずに作れるとした。
=== 1972年の共著「構造化プログラミング」 ===
1972年の共著「Structured Programming<ref name="structured_programming_72">O.-J. Dahl and E. W. Dijkstra and C. A. R. Hoare, ''Structured Programming'', Academic Press, London, 1972</ref>」は計算機科学界の錚々たる三名による三章構成で、第一章はエドガー・ダイクストラの「structured programming」、第二章は[[アントニー・ホーア]]の「data structuring」、第三章は[[オルヨハン・ダール]]の「hierarchical program structures」となっていた。結びの章の「階層型プログラム構造」を著したダールは[[Simula|Simula67]]の開発者である。Simula67はオブジェクト指向プログラミングの草分けであり、この章名からクラスの継承による階層構造を重視していたことが伺える。ダイクストラの構造化プログラミングは、制御構
ダイクストラ提唱の構造化プログラミングを支持する[[ドナルド・クヌース]]は、1974年に自著「Structured Programming with go to Statements<ref name="structured_programming_with_go_to_statements" />」を上梓し、その中でgoto-lessの本質に関する補足と解説を加えた。これは当時のgoto文論争に一つの区切りを付けるものであったが、幅広い認知を得るには到らず同様の論争はその後も泥炭の火災のように燻ぶり続けた。1970年代後半からマイコンが普及して[[BASIC]]などを扱うパーソナルユーザーが増えると、goto命令を使わないのが構造化プログラミングといった見解が取り上げられて再び議論が始まるなど、この論争の影響は後年まで残った<ref group="注釈">直接は無関係だが、ダイクストラはBASIC批判の急先鋒でもあった。マイコン普及以前の1970年代に既に、BASICでプログラミング教育をすべきでない、と強く主張している([https://en.wikiquote.org/wiki/Edsger%20W.%20Dijkstra#How_do_we_tell_truths_that_might_hurt?_(1975) wikiquote:Edsger W. Dijkstra#How do we tell truths that might hurt? (1975)])。</ref>。
71 ⟶ 78行目:
なお、ベームとヤコピーニの証明は、フローチャートやそれによって表現されるプログラム・関数・チューリングマシンなどの理論的側面に注目している。これは任意の論理回路が[[否定論理積|NAND]]素子の組み合わせによって表現できるとか、[[ラムダ計算|λ式]]がSおよびKという名の2つの[[SKIコンビネータ計算|コンビネータ]]によって表現できるとかいった研究に近い。回路設計者が直接NANDを組み合わせて電子回路を設計しないのと同じように、構造化定理は良いプログラムの作成を(少なくとも直接的には)意図していない。ハレルも構造化定理は実際の内容以上に引用されて民間伝承定理(''folk theorem'')化していると指摘していた<ref name=":0" />。
=== ダイクストラの後述 ===
ダイクストラは2001年のノート「[https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1308.html What led to “Notes on Structured Programming”]」(構造化プログラミング表記の由来)でこのように述べている。
1968年の自分は「A case against goto statement」(goto文が不利な事例)と題した記事(''article'')をCommunications of the ACM([[Association for Computing Machinery|ACM]]の機関紙)に投稿したが、当期の刊行を急ぐ編集担当者の意向で投書(''letter to the Editor'')にされる事になり、更にその担当者独自の考えで「The goto statement considered harmful」(goto文は有害)という全く新しい題名を付けられた。その担当者とは[[ニクラウス・ヴィルト]]であった。また、自分が提唱した構造化プログラミングの本質的内容の普及を好まない某社が
==脚注==
'''注釈'''{{Reflist|group="注釈"}}'''出典'''{{Reflist|2}}▼
▲{{Reflist|group="注釈"}}
== 参考文献 ==
113 ⟶ 101行目:
* {{Citation |和書| title=プログラミングの方法 | author=E.W.ダイクストラ | author2=W.H.J.フェイエン | translator=玉井浩 | year=1991 | publisher=サイエンス社}}
== 関連項目 ==
*[[goto文]]▼
*[[制御構文]]
*[[構造化定理]]
*[[構造化分析設計技法]]
*[[SSADM|構造化体系分析設計手法]]
*[[ジャクソンの構造化プログラミング]]
▲*[[goto文]]
*[[ALGOL]]
'''関連人物'''
135 ⟶ 116行目:
*[[ニクラウス・ヴィルト]]
*[[ドナルド・クヌース]]
*[[コラド・ベーム]]▼
*[[ハーラン・ミルズ]]
▲*[[コラド・ベーム]]
== 外部リンク ==
*[https://www.tatapa.org/~takuo/structured_programming/structured_programming.html 意外と知られていない構造化プログラミング]
*[https://calculator-cafe.com/readings/Structured_programming/Structured_programming.html 翻訳:構造化プログラミングを最初に提唱した文書]
{{プログラミング言語の関連項目}}
|