構造化プログラミングはまだ必要ではないのか？

**デフォルトの名無しさん** · 2018/08/15(水) 00:28:28.85

構造化プログラミングで言うところの「抽象化データ構造とその操作の抽象文の共同詳細化」はオブジェクト指向のクラスで実現された。
しかし、オブジェクト指向だけでは、階層化と段階的詳細化と段階的抽象化が実現できない。

まだ構造化プログラミングは必要なのではないのか？
しかし、今は風化しているように思えて仕方がないし、ダイクストラの考えを知っていれば、もっとマシなコードが書けそうだが。

（Wikipedia の構造化プログラミング）
https://ja.wikipedia.org/wiki/%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

**デフォルトの名無しさん** · 2018/08/15(水) 11:01:29.41

コード書くときに「これはオブジェクト指向、あっちは構造化プログラム」っていちいち意識するかバカ者

**デフォルトの名無しさん** · 2018/08/15(水) 11:43:51.12

>>2
とはいえオブジェクト指向だけで説明できないことも多い。
クラスにすれば全て解決ではない。
構造化プログラミングを意識しないと無駄なクラスをたくさん作ることになる。

**デフォルトの名無しさん** · 2018/08/15(水) 14:01:49.63

>>1
構造化プログラミングについて少し歴史的なことをメモしておこう

構造化定理は逐次的プログラム（つまり並行して動作し得る複数のプロセス・スレッド・タスクが存在せず単一のプログラムカウンタで済むプログラム）について
３基本構造（順接、分岐、反復）の表現能力に関する数学的事実を述べた定理に過ぎず、書かれるプログラムの信頼性とか読み易さ・理解し易さとは無関係

それをさも関係があるように錯覚させたのが実務畑のHarlan D. Millsの狡猾なところであり、またある意味では有能なところでもある
つまり、多くのプログラマはバカだから単純なクライテリアでなければ理解できないから、バカ向けの単純なクライテリアを与えてやった、これが確信犯Millsの功績であり罪過でもある
言い換えればDijkstraの高尚な“structured programming”の精神などはバカな大衆プログラマには理解不能で豚の耳に念仏だとMillsは悟っていたから
Dijkstraの提唱した“structured programming”という標語だけ借りて中身はバカ向けに完全に換骨奪胎したのがMills流の“structured programming＝goto-less programming”という一種の運動
そして、この運動を権威づけるために使ったのが単なる表現定理に過ぎない構造化定理だったわけだ
つまり「この運動が正しいことはちゃんと数学で保証されてるんだよ！」って権威づけをしたわけね

アカデミアの世界にずっと身を置いていたDijkstraとは違い、MillsはIBMの研究員として開発現場の指導なども行って現場プログラマのほとんどはバカばかりだと嫌というほど思い知らされていたはず
だからこそ「正しいが難し過ぎてバカには正しく理解するのは不可能」なDijkstra流の高尚な“structured programming”からキャッチフレーズの“structured programming”だけ流用して
「正しくないがバカにも理解し実行できて多少は効果が見込める」Mills流の低俗な“structured programming”を広めたのだよ

そしてMichael Jacksonパパが構造化定理に基づいて事務処理向けのプログラミングを入出力データ構造の対応から３基本構造を用いる形で系統的に導出する手法として
JSP (Jackson Structured Programming) を提案して大人気を博したことでMills流の低俗な“structured programming”運動は一層の盛り上がりを見せたというわけ

**デフォルトの名無しさん** · 2018/08/15(水) 17:57:46.43

>>1
Wikipediaより

>1987年の第9回ソフトウェア工学国際会議(ICSE)において、Millsは会場にチューリング賞受賞者がいないことを確かめると
>「ダイクストラやホーア達はどこへ行ってしまったのか。我々はもう彼らから学ぶものがないのか。」とその現状を批判した
>（しかし木村泉の見解が当たっていたとするならば、「ソフトウェア工学」をそういったものにしていった張本人こそが、その発言をしたMillsであるということになる）。

酷いよなあ
ダイクストラの研究を粉砕した張本人がよくこんなことを言えるわ

**デフォルトの名無しさん** · 2018/08/15(水) 20:19:38.78

（きちんとクラスが整理された上での）OOPこそ構造化プログラミングの結実したものと思っていたんだが違うのか

**デフォルトの名無しさん** · 2018/08/15(水) 20:52:41.51

構造化とオブジェクトは別物だと思っていたが

**デフォルトの名無しさん** · 2018/08/15(水) 21:28:28.97

今はオブジェクト指向さえできれば十分という風潮がある。
しかし、オブジェクト指向は主にクラスを使うというだけであって、
綺麗で分かりやすいプログラムを書けるかどうかとは別問題。

構造化プログラミングは綺麗で分かりやすいプログラムを書く手法としては今でも大事かと。

**デフォルトの名無しさん** · 2018/08/15(水) 21:34:08.82

>>8
>オブジェクト指向は主にクラスを使うというだけであって

そりゃいくら何でも偏見

**デフォルトの名無しさん** · 2018/08/15(水) 21:41:38.81

COBOL、VB、Java…と時代が流れても馬鹿は馬鹿なコードを書く。

**デフォルトの名無しさん** · 2018/08/15(水) 22:39:09.18

>>1
選択するようなもんじゃないじゃん・・・
何で片っぽだけで存在出来ると思ってんの？

**デフォルトの名無しさん** · 2018/08/15(水) 22:43:49.88

>>11
自分は片方だけとは書いていないが？

**デフォルトの名無しさん** · 2018/08/16(木) 00:11:08.97

>>1 がクソコードしか書けないのは分かったからいちいちスレ立てんな。

**デフォルトの名無しさん** · 2018/08/16(木) 00:21:20.74

>>13
いや、ｽﾚ建ての言い分は稚拙かもしれないが、
型クラスベース+継承でソフトウエアを表現すると
依存の茂みを作ってスパゲティーの山になる欠点に薄々気がついて
王様の耳はロバの耳と、あえて言っているのかもしれない…

**デフォルトの名無しさん** · 2018/08/16(木) 00:46:01.96

>>14
オブジェクト指向で却ってややこしくなった面もあるかもね

**デフォルトの名無しさん** · 2018/08/16(木) 01:20:22.82

オブジェクト指向技術はエディタの機能で代替できるような気がする。
エディタにはコードの検索や置換機能があるし、
VimやSublime,サクラエディタで高速に既存コードを再利用できる。
だからエディタの機能やVimを極めれば継承とかほぼ要らないし、
再利用性重視でなくてもいい。
変更の影響範囲とかもエディタを使って洗い出せば、管理できる。
だからオブジェクト指向の高度な機能を使わなくてもエディタや
ツールで代替えできる。
コードの差分はGitやWinMergeで洗い出せる。
オブジェクト指向のガチガチの設計を書くととにかく
変数名、メソッド名などの名前が長くなる。
名前が横に長いと非常に読みにくく画面外に隠れるし、
名前というのはスペース区切りもカンマ区切りもないわけだから、
上記のエディタ機能で編集がやりにくい。
だからJavaみたいなガチガチのオブジェクト指向ってもう今の時代
必要ないんだと思う。JavaScriptやPythonくらいのオブジェクト指向
だけで十分だもの。
Javaの作法の時代遅れ感とか、馬鹿馬鹿しさってそろそろ気付くべき。

**デフォルトの名無しさん** · 2018/08/16(木) 09:06:07.27

>>12
>>1
>まだ構造化プログラミングは必要なのではないのか？

条件が整えば不要になると自分で書いてるじゃん。

**デフォルトの名無しさん** · 2018/08/16(木) 09:09:40.06

>>15
2010年のインタビューでは、オブジェクト指向の御大は「実現方法に欠点があった」と考えてるようだ。

オブジェクト指向プログラミングは間違いだったか?
https://www.infoq.com/jp/news/2010/07/objects-smalltalk-erlang
>このインタビューを受けたのは、Erlangの最初の開発者であるJoe Armstrong博士とSmalltalk、OOP、パターンに長い間関係している
>Ralph Johnson博士だ。私たちは「間違った道」を当てもなくさまよって
>きたが、これはオブジェクトの考え方の実現方法に欠点があったため
>であり、この考え方自体の欠点ではないと2人は述べた。

**デフォルトの名無しさん** · 2018/08/16(木) 09:45:07.99

>>18
これってクラスが良くないってこと？
Erlangの仮想マシンのプロセスみたいなものが良いってこと？

**デフォルトの名無しさん** · 2018/08/17(金) 09:05:58.30

元祖オブジェクト志向は俺らのモノだってだけの主張

**デフォルトの名無しさん** · 2018/08/17(金) 09:31:41.05

そもそもオブジェクト指向は、データとアルゴリズムをクラスとして組み合わせただけのこと。
構造化プログラミングみたいに綺麗なコードを書くためのものではない。

**デフォルトの名無しさん** · 2018/08/17(金) 21:12:36.99

>>21
なるほど、構造化プログラミングは設計手順でもあるのかー

オブジェクト指向だとドメイン駆動とかユースケース駆動なんかが
それにあたるのかね

Wikipediaの構造化プログラミングには↓こう書いてあって

> プログラムを記述するのではなく、機能を抽象化した「仮想機械」を想定し、その「仮想機械が提供する命令群」でプログラムを構成する

これってオブジェクトの設計にも当てはまるよね
オブジェクトは構造化の手段の一つとみることもできそう

**デフォルトの名無しさん** · 2018/08/17(金) 21:21:26.89

>>22
つーか、ダイクストラが抽象化データ構造という概念を提案していて、
それがオブジェクト指向のクラスに似た考えだった。

**デフォルトの名無しさん** · 2018/08/18(土) 02:37:34.71

>>22
> > プログラムを記述するのではなく、機能を抽象化した「仮想機械」を想定し、その「仮想機械が提供する命令群」でプログラムを構成する
>
> これってオブジェクトの設計にも当てはまるよね
> オブジェクトは構造化の手段の一つとみることもできそう

ところがSimula 67の頃はともかく、Smalltalk-80以降のオブジェクト指向の人々は暴走して上の構造化プログラミングでの抽象機械という思考上の粒度とは
およそ対応しないほど細かい粒度のオブジェクトをどんどん使い始めた、例えば「１つの数だって立派なオブジェクトだ！」といった形でね

オブジェクト指向がそのように暴走しだした時＝オブジェクト原理主義が始まったから、オブジェクト指向を熱心に使う人々の大半は構造化プログラミングとは無関係になり、
オブジェクト指向で作られたプログラムはDijkstraが考えていたようなプログラムの正しさを論じやすいようにしっかりとした構造を持つものではなく、
まるで簡単に取り外しできて自由に回転できる自由継手ばかりで組み上げられたようなクネクネとして「形」というものが良く見えない代物になった

確かに細かいオブジェクトを自由に組み合わせて作れば部品の追加や削除は容易になるが、プログラムの正しさを論じるには余りにも自由度が高すぎて見通しが悪すぎる

**デフォルトの名無しさん** · 2018/08/18(土) 06:54:35.39

>>24
>ところがSimula 67の頃はともかく、Smalltalk-80以降のオブジェクト指向の人々は暴走して上の構造化プログラミングでの抽象機械という思考上の粒度とは
>およそ対応しないほど細かい粒度のオブジェクトをどんどん使い始めた、例えば「１つの数だって立派なオブジェクトだ！」といった形でね

確かにオブジェクト指向はそんなものだと漠然と思っていたけど
何でもオブジェクトにすればいいってものではないよなあ。
結局、オブジェクト指向の導入によってプログラムは難解になっただけだった。
柔軟性は上がったけど可読性は低下した。

**デフォルトの名無しさん** · 2018/08/18(土) 07:26:02.71

わかりみが深い

**デフォルトの名無しさん** · 2018/08/18(土) 09:50:15.71

>>25
暴走というより、プログラミングの可能性追究の過程だからね。
「可読性という産業的な面の利便性」とは別の、今で言えば自動プログラミングの方向だし。

**デフォルトの名無しさん** · 2018/08/18(土) 10:59:20.89

>>26
わかりみが深いの意味と使い方とは？きもい言葉だけど元ネタはまさかの漱石？
https://kotoyumin.com/wakarimi-mean-3531

**デフォルトの名無しさん** · 2018/08/18(土) 12:39:52.96

Smalltalk で何でもオブジェクトになるのは文法と実装からほぼ必然なので許してやれ

**デフォルトの名無しさん** · 2018/08/18(土) 12:48:08.70

>>29
Smalltalkはオブジェクト指向を突き詰めたらどうなるのかを実現した言語だし

**デフォルトの名無しさん** · 2018/08/18(土) 14:51:08.96

>>28
「わかりみ」は文法違反の単なる誤用で日本語の意味のある単語としては認められない

＞本文中の他の「?み」の例、つまり「ありがたみ」や「悲しみ」それに漱石が使った「淋しみ」は
＞どれも形容詞「ありがたい」・「悲しい」・「淋しい」の語幹に「み」を付けて名詞化した言葉であるが「わかりみ」は違う

上に加えると
「わかりみ」の語根「わかり」は動詞「わかる」の連用形なので形容詞のように体言にかかり修飾することすらできない単語で
それに「～み」を付けた形を日本語の言葉として使うのは単なる無知を曝け出しているだけのこと

**デフォルトの名無しさん** · 2018/08/18(土) 22:07:01.87

Smalltalkなんて死んだ言語を語ってもなー

**デフォルトの名無しさん** · 2018/08/18(土) 22:17:54.75

>>1
ダイクストラの提唱した検証を前提としたプログラミングが必要か？という
疑問であれば、これから必要だし今後はさらに重要になると断言できる
実際、24時間365日正しく動作するバグ0の品質要求が当たり前な
組み込み開発の一部では、必須の技術要素になりつつある

ただし、ソフトウェア検証への対比としてオブジェクト指向を挙げる事に違和感がある
ソフトウェア検証とオブジェクト志向は互いに交差する概念であって対立はしない
実際、たとえば VDMにオブジェクト指向を導入したVDM++が登場しているし、
Alloy は最初からオブジェクト指向の概念を前提として設計されている

**デフォルトの名無しさん** · 2018/08/19(日) 02:21:20.02

>>31
言語学上はある表現が間違ってる云々といった議論は意味を持たない
例えば、あらゆる方言は標準語から見れば「誤り」だがそのような主張をする人はいない
一定の範囲で通用しているならそれは「正しい」言葉なのだ

**デフォルトの名無しさん** · 2018/08/19(日) 11:26:16.86

>>33
>実際、24時間365日正しく動作するバグ0の品質要求が当たり前な
>組み込み開発の一部では、必須の技術要素になりつつある

具体的にどうやっているんだ？

**デフォルトの名無しさん** · 2018/08/19(日) 15:50:15.02

>>35
開発したいシステムの外部仕様をVDMやAlloyといった形式的仕様記述言語で
記述し、それをツールを使って検証、詳細化という手法で実装言語に変換

詳細に関しては「組込み形式手法」や「組込み仕様記述」でググると、
大量の入門やら事例やらを扱う文書が見つかる

個人的にお勧めの教科書(入門書)は以下の２冊：
・形式手法入門
　https://www.amazon.co.jp/dp/4274211886/
・組み込みソフトへの数理的アプローチ
　https://www.amazon.co.jp/dp/4789838080/

このム板にも専用スレがある（過疎ってるけど
・【Alloy】形式言語による仕様記述【VDM】
　http://mevius.2ch.net/test/read.cgi/tech/1357387746/

**デフォルトの名無しさん** · 2018/08/19(日) 17:46:32.00

>>36
ありがとう。今の組込はそんなことをやっているんだなあ。

**デフォルトの名無しさん** · 2018/08/19(日) 22:10:30.70

>>32
> Smalltalkなんて死んだ言語

Smalltalkは現役バリバリの言語処理系だが？→http://pharo.org/
そんなことも知らんとかアンテナ低すぎだぞ！wwwwww

**デフォルトの名無しさん** · 2018/08/19(日) 23:25:26.66

>>38
アンテナ強すぎてノイズ拾ってるんちゃうんか？

**デフォルトの名無しさん** · 2018/08/19(日) 23:49:50.24

>>39
アンテナ「強」すぎとかググり力以前に日本語wwww

**デフォルトの名無しさん** · 2018/08/20(月) 00:03:49.68

セックスが強いとも言うし
匂いが強いとも言うのよ
強いって言葉は何にでも使っていいの万能なの

**デフォルトの名無しさん** · 2018/08/20(月) 00:04:58.23

ググり力ってなんすか？www日本語エントロピーが拡散してますよ

**デフォルトの名無しさん** · 2018/08/20(月) 00:18:54.12

エントロピーは「増大」するんだがな

**デフォルトの名無しさん** · 2018/08/20(月) 22:32:57.09

try - catch の大域脱出は構造化プログラミングに入るの？
許されてるのかどうかが知りたい

**デフォルトの名無しさん** · 2018/08/20(月) 22:40:55.14

例外処理やついでに継続なんかは本質的にGOTOだからもちろんダメだろ

**デフォルトの名無しさん** · 2018/08/21(火) 00:53:54.19

>>44
大域脱出は良いことだったのだろうか？

**デフォルトの名無しさん** · 2018/08/21(火) 04:05:08.76

構造化は今でも必要だと思うよ
初期の(今でも?)プログラミングで作られた物が大変だったのは
何もかもが広域だったから
構造化にしてもオブジェクト指向にしても
アクセス範囲を狭小化したのが一番効果が大きい
余りにも何処からでもアクセスされてるとそのアクセスパターンが発散してしまって
組み合わせ数が多くなりすぎて事前予測不可能になる(テストしきれない)
オブジェクト指向プログラミングは粒度が最小化可能な物で
それによってアクセスパターンを最小化してバグを発生させ難く出来る
この部分に一番効用が有る
人間の認識限界
これを理解しているかどうかが鍵となる
エドガーダイクストラが言った一番の要点はアクセス範囲の極小化する為に構造化を提唱した
だからcobolみたいにdataなんちゃらーとプロセデュアなんちゃらーみたいに
処理とアクセスする物が分離されている物が一番問題があると指摘した
basicは変数が広域なので問題が有ると指摘した
クラス型オブジェクト指向プログラミングシステムでは
クラス内に変数とその処理をパッケージングしてアクセス範囲を完全に限定した
だからpropery get/set みたいな内部変数を直接外部から操作するような書き方や
それしか出来ないような言語は問題が有るし
問題有りだと騒がれる

**デフォルトの名無しさん** · 2018/08/21(火) 05:56:38.36

>>44
try - catch は乱暴な仕組みだよなあ。
下の階層の例外を漏らさず捕獲する。
言い換えると下の階層を信用していない仕組み。
この仕組みのせいでますます適当にプログラミングできるようになったかもしれない。

**デフォルトの名無しさん** · 2018/08/21(火) 06:42:58.86

むしろ逆だろ
適当なプログラミングするやつをカバーするために例外機構ができた

**デフォルトの名無しさん** · 2018/08/21(火) 07:14:29.94

>>49
現実に合わせるとそうなるのかねえ
構造化プログラミングは理想に過ぎないのか

**デフォルトの名無しさん** · 2018/08/21(火) 07:27:11.40

規模が小さければ構造化でしょ

**デフォルトの名無しさん** · 2018/08/21(火) 12:05:02.95

トライキャッチは構造化例外処理と呼ばれるけどね

**デフォルトの名無しさん** · 2018/08/21(火) 12:06:08.08

入れ子にできるし
扱うフローが正常か異常かの違いかのお