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

**デフォルトの名無しさん** · 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/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

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

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

>>52
見た目的には構造化されているけど、大域脱出はある意味gotoに近いものがあるかと

**デフォルトの名無しさん** · 2018/08/21(火) 15:24:11.78

>>54
正常フローを抜けるんだからしょうがない

**デフォルトの名無しさん** · 2018/08/21(火) 15:24:39.70

フローが違うんですよ

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

>>54
> 見た目的には構造化されているけど、大域脱出はある意味gotoに近いものがあるかと

脱出でのgotoは検証のしやすさを乱さないからDijkstra本来の構造化プログラミングの精神には反しない（というのを昔、誰かが書いてたように思うが詳しいことは覚えてない）
問題は例えば制御構造（複合文）の内部のラベルに向かって構造の外側からgoto文等のジャンプによって制御を移す（飛び込む）ケース、確かCとかでは許されたのでは
これを許すと検証が非常に面倒になるので構造化プログラミングとしては許し難い暴挙

**デフォルトの名無しさん** · 2018/08/22(水) 02:09:46.54

とはいえ、関数ポインタ(継承含む)があると例外は検証できなくなるし
検証しようとシグネチャに例外の種類を明記させると大変面倒なことになるしなー
Swiftや、C++の新規格みたいに最近は例外を投げるか投げないかだけを明記するのが流行りっぽい

**デフォルトの名無しさん** · 2018/08/22(水) 02:24:49.37

ゴジゴシリン
ヘルスハンバーグ

**デフォルトの名無しさん** · 2018/08/22(水) 18:55:08.64

>>58
> とはいえ、関数ポインタ(継承含む)があると例外は検証できなくなるし

関数ポインタが許される言語の検証は例外処理の検証以上に厄介だよ
現実問題として関数ポインタや手続き（関数）の引数・結果値としての手続き（関数）を許す言語の検証は
非常に労力を要することなるので実用的ではないと思うが

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

複数返り値さえあれば例外なんてほとんど必要ないのに

**デフォルトの名無しさん** · 2018/08/23(木) 12:25:24.88

コアダンプ万歳

**デフォルトの名無しさん** · 2018/08/23(木) 12:39:10.83

ブルスクマンセー！

**デフォルトの名無しさん** · 2018/08/23(木) 12:41:10.97

やっぱこれだろ→💣

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

>>61
確かに例外を使い過ぎている感があるよね

**デフォルトの名無しさん** · 2018/08/24(金) 02:12:52.19

>>構造化プログラミング
今でもCOBOLとPL/1では生きてるぞ

**デフォルトの名無しさん** · 2018/08/25(土) 13:33:32.69

Wikipedia の構造化プログラミングが I.hidekazu という奴のせいで酷い内容になっている。

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/25(土) 14:09:07.80

>>67
酷いなそれw
フローチャートの書き方と完全に誤解していないか？

**デフォルトの名無しさん** · 2018/08/25(土) 14:21:12.16

これはひどい

**デフォルトの名無しさん** · 2018/08/25(土) 19:17:08.85

>>67
> Wikipedia の構造化プログラミングが I.hidekazu という奴のせいで酷い内容になっている。
・・・
> こいつは構造化定理と構造化プログラミングの区別ができているのか？
>>68
> 酷いなそれw
> フローチャートの書き方と完全に誤解していないか？

というか、このI.hidekazuって奴はDijkstraとMillsとは同一人物だとでも思ってるみたいね（苦笑）

**デフォルトの名無しさん** · 2018/08/25(土) 19:26:53.82

でも前からこの記事編集してるみたいだぞ

**デフォルトの名無しさん** · 2018/08/25(土) 19:42:13.77

>>70
何をネタ元にしたらこんな記事が書けるのか？

**デフォルトの名無しさん** · 2018/08/25(土) 19:54:15.74

>>67
ノートで抗議している人がいるけど聞く耳持つのかねえ？

**デフォルトの名無しさん** · 2018/08/25(土) 20:01:04.96

加筆前と大して変わってないぞ
図が入って連接・選択・繰り返しがわかりやすくなったくらいだろ
お前らろくに読んでないんじゃないか？

**デフォルトの名無しさん** · 2018/08/25(土) 20:06:43.61

>>74
お前、これを読んで一緒だと思うのか？

加筆前
https://ja.wikipedia.org/w/index.php?title=%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&;oldid=69567277

**デフォルトの名無しさん** · 2018/08/25(土) 20:11:32.98

>>75
正しさの検証手法が詳しくなったよね
それ以外はまったく同じ
全部読んだ

**デフォルトの名無しさん** · 2018/08/25(土) 20:12:05.97

お前らろくに読みもせずにこのスレのバイアスだけで文句言ってるだろ
池沼どもが

**デフォルトの名無しさん** · 2018/08/25(土) 20:13:35.62

>>76
>>77
お前、I.hidekazu本人だろ？とっとと死ねよwww

**デフォルトの名無しさん** · 2018/08/25(土) 20:24:25.98

>>78
違うわ、お前が死ねよ

**デフォルトの名無しさん** · 2018/08/25(土) 20:26:20.67

>>74>>76>>77
文頭からして全然異なっている。KMExyDFm の頭はおかしいのか？

https://ja.wikipedia.org/w/index.php?title=%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&;oldid=69685367

＞ソフトウェアの複雑な制御フローを連接・選択・繰り返しおよびネスティング（nesting）の多層化[1]によって整理しながらプログラミングを行うダイクストラ流段階的詳細化法[2]を言う[3]。

これってノートでも指摘されているように段階的抽象化と段階的詳細化の区別が全然できていない。

＞単純にgoto文を使用しないgoto-lessプログラミングと理解されていることが多い[4][5]。

ここの「理解」を他の人が「誤解」に修正したらI.hidekazuが以下の返信。

＞平成30年8月21日 (火) 14:21‎ I.hidekazu (会話 | 投稿記録)‎ . . (37,161バイト) (-361)‎ . .
＞(歴史的発展に関する記述を脚注を使って整理した。ほか細かい整理。
＞goto lessプログラミングは十分ではない理解ではあるものの、誤解という強い表現を使うほどではないので理解にさせてください。)

つまりI.hidekazuに言わせると、構造化プログラミングを構造化定理と取り違えても誤解というほどの間違いではないということらしい。
明らかに構造化プログラミングと構造化定理の区別ができていない！

**デフォルトの名無しさん** · 2018/08/25(土) 20:32:50.77

>>80
不十分な理解ということだろ
言ってること間違ってないじゃん

＞単純にgoto文を使用しないgoto-lessプログラミングと理解されていることが多い[4][5]。

この文削除でもいいくらい
誤解という言葉はそれってあなたのただの感想ですよねってことになる
感想文書くところじゃないから理解に修正したんだろ

削除してもいいくらいのクソ情報だよ

**デフォルトの名無しさん** · 2018/08/25(土) 20:33:24.59

事実と感想を分けれてない

**デフォルトの名無しさん** · 2018/08/25(土) 20:36:00.98

>>81
お前、I.hidekazu本人じゃないの？ノートに似たようなことを書いているよな。

＞加えて、goto文の論争についてはバッサリ削除してしまっていいと思います。--I.hidekazu（会話） 2012年11月23日 (金)

それと、goto文の話以外は反論できないのか？まあ、できないだろうな。

**デフォルトの名無しさん** · 2018/08/25(土) 20:37:15.65

>>82
それができていないのはあんただろ。
「誤解」が事実であって、「誤解という強い表現を使うほどではない」は完全に感想。

**デフォルトの名無しさん** · 2018/08/25(土) 20:47:08.05

>>80の続き
概要からしておかしい。I.hidekazuは概要のほとんどをフローチャートの説明にしている。
しかし、構造化プログラミングはそういうものではない。

「構造化プログラミングとは何か？」はノートに書いている人の方が正しい。
https://ja.wikipedia.org/wiki/%E3%83%8E%E3%83%BC%E3%83%88:%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

＞・良く構造化されたプログラム (well-structured programs) → 制御フローのことではない
＞・大きなプログラムの理解を助ける段階的抽象化 (step-wise abstraction) → これの反語が段階的詳細化
＞・抽象データとその操作の抽象文の共同詳細化 (joint refinement) → オブジェクト指向のクラスに似た考え
＞・プログラムの階層化（真珠のネックレスとしてのプログラム） (Programs as necklaces strung from pearls) → 段階的抽象化よりも大きな単位の階層化
＞
＞「連接・選択・繰り返し」については、段階的抽象化の一要素に過ぎないのです。

概要の最後にI.hidekazuはこんなことを書いている。

＞これを解決する手段としてダイクストラが開発技法として導入したのが抽象（abstract）及びフローチャートのネスト（nest）すなわち段階的詳細化[17]である。

「抽象（abstract）及びフローチャートのネスト」が段階的詳細化って頭沸いているのか？
抽象的な設計から始めて詳細化していくのが段階的詳細化。
コードの一部を括り出して抽象化していくのが段階的抽象化。
I.hidekazuは完全に理解ができていない。

**デフォルトの名無しさん** · 2018/08/25(土) 20:48:08.63

>>83
違うよ、俺は完全に中立な第三者、その俺から見ても
修正前のものは感情的すぎるというか気持ち悪い
執筆者の感情と客観的な事実が混ざってどす黒い色になってる
こんなの書いてるから日本のWikipediaはバカにされるんだよ

>>84
誤解は事実ではないんですよ、みんなは誤解してるんだという思いなんですよ
書いた人間の思いが誤解という言葉には詰まっています

> 誤解という強い表現を使うほどではない」は完全に感想。
これが構造化プログラミングの中に書かれてたらヤバイですよ
でも書かれてないから問題ないんです
執筆者がどういう思いを持っているかを本文に書くべきではありません
あくまで中立に客観的に平等にそして公平に書くべきです

**デフォルトの名無しさん** · 2018/08/25(土) 20:51:46.61

>>86
>>85を読んでお前の池沼な頭で反論してみろ。
構造化定理と構造化プログラミングは完全に別物なんだよ！

**デフォルトの名無しさん** · 2018/08/25(土) 20:56:25.37

>>87
そうやって罵詈雑言並べ立てて
相手が悪いかのようにしないと
正当性を主張できないんでしょ？
もうその時点でどうかと思うよ

>>85を読んだけど
I.hidekazuが言ってることが正しいと思った

**デフォルトの名無しさん** · 2018/08/25(土) 20:56:49.75

ID:KMExyDFm は、ID:HVFTZtzY が書いていることを理解できていないみたい。
こういう人が来ると疲れるわ。

本質的なことは>>4に書かれているけど、ID:KMExyDFm はこれも理解できないのかなあ？

**デフォルトの名無しさん** · 2018/08/25(土) 20:57:28.89

>>88
>I.hidekazuが言ってることが正しいと思った

その根拠は？

**デフォルトの名無しさん** · 2018/08/25(土) 20:57:37.22

完全にI.hidekazuに論破されてるじゃん
書き換えて正解だよ

**デフォルトの名無しさん** · 2018/08/25(土) 20:58:22.44

>>89
それは全部Wikipediaに書いてあるよ
だから問題ないよね

**デフォルトの名無しさん** · 2018/08/25(土) 20:59:24.06

>>90
鬼絡みして相手を疲れさせようって魂胆かな
読めばわかるよね、自明だよ

**デフォルトの名無しさん** · 2018/08/25(土) 21:00:30.92

そんなに気に入らないなら自分で修正すれば良いのに
このスレでろくに読みもせずになんとなく間違ってる
雰囲気だから叩いておこうという卑しい心が透けて見えるよ
ほんとくだらない

**デフォルトの名無しさん** · 2018/08/25(土) 21:03:00.68

>>89
I.hidekazu本人が来ているだけなので何言っても無駄ですよ。

>>91
意味がわからん。I.hidekazuは誰も論破していない。
まあ、本人だからそういうことにしたいのだろうが。

>>92
書かれていない。Mills がどのようにして構造化プログラミングをダイクストラから奪ったのかが説明不足すぎる。

>>93
>読めばわかるよね、自明だよ

つまり反論できないってことか。

**デフォルトの名無しさん** · 2018/08/25(土) 21:04:35.02

>>95
読解力ないからわからないだけでしょ
100回読み直したら？

> 抽象（abstract）及びフローチャートのネスト（nest）すなわち段階的詳細化[17]である

日本語文法わかる？

**デフォルトの名無しさん** · 2018/08/25(土) 21:07:43.36

>>96
お前（I.hidekazu）、本当にアホだな。

段階的詳細化：抽象設計→詳細設計
段階的抽象化：プログラムコード→コードを括り出して抽象化

日本語文法が分かっていないのはお前だ！
だからWikipediaにあんなことを書くのだろうが！

**デフォルトの名無しさん** · 2018/08/25(土) 21:11:33.03

>>97
及びの意味を考えろよ

単語の意味だけ考えて文章のコンテキストを読めてない
文盲って言うのかな、戦後の日本の国語教育の失敗だよね

結論を言うとWikipediaはいまのままでいい
読書感想文のような客観性のない感情論は削除しまくってもいいと思うけどね
消したら消したでアホどもが騒ぐからしかたなく残してるんだろうな

日本語のWikipediaの品質が低いのはそうしたアホなくせに時間だけは
持て余してるオタクどもに配慮しなければいけないからだろ

**デフォルトの名無しさん** · 2018/08/25(土) 21:12:42.26

I.hidekazu = ID:KMExyDFm は、ここで敗北すると面子丸つぶれなので必死。
I.hidekazuでGoogle検索するとここが出て来るからなwww

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

>>98
>及びの意味を考えろよ

一［接］《漢文訓読で接続詞に使う「及」の字を「および」と読んだところから》複数の事物・事柄を並列して挙げたり、別の事物・事柄を付け加えて言ったりするのに用いる語。と。ならびに。また。そして。「生徒及び父兄」「国語、数学、及び英語は必修」
[補説]多くの語を並列するときは、最後にくる語との間にだけ置くことが多い。
二［名］及ぶこと。届くこと。

明らかに一の意味だ。

> 抽象（abstract）及びフローチャートのネスト（nest）すなわち段階的詳細化[17]である

つまり、I.hidekazuは「抽象が段階的詳細化に含まれる」と言っているわけだな。
アホじゃん。

**デフォルトの名無しさん** · 2018/08/25(土) 21:18:54.69

>>98
>文盲って言うのかな、戦後の日本の国語教育の失敗だよね

それはお前だ。お前みたいな奴がいるから Wikipedia のレベルが低下する。

**デフォルトの名無しさん** · 2018/08/25(土) 21:20:27.77

>>99
何度も言ってるけど、俺はI.hidekazuではないよ
君は思い込みが激しいね

こうだと思いこんだらそれは違うよと言っても考えを改めない
難儀な性格してるね、文章もまともに読めないし

5chでバイアスかけられてイキってるだけじゃん

**デフォルトの名無しさん** · 2018/08/25(土) 21:21:20.79

>>102
だったらどういうロジックで俺が間違えているのか書いてみろ

**デフォルトの名無しさん** · 2018/08/25(土) 21:23:05.09

>>100
AおよびB、Cである
という文を
AがBであると読み取るその読解力のなさ
思い込みの激しさたるやもう助けようがないよ

**デフォルトの名無しさん** · 2018/08/25(土) 21:26:08.63

論理的な思考力の弱い人は
普段接するようなものに例えてみると
理解力があがるという認知学の研究結果がある
それをふまえて例文を示そう

空を飛ぶのは鳥および飛行機、すなわちトンボである
という文は
鳥がトンボであることを述べていない

**デフォルトの名無しさん** · 2018/08/25(土) 21:26:27.37

>>104
そうやってはぐらかしてないで反論してみろ。できないよな？負け犬。

**デフォルトの名無しさん** · 2018/08/25(土) 21:29:28.30

>>106
またそうやって相手を貶す発言をする
そういうことを言うから君の言うことに説得力がなくなるんだよ
もっと冷静に議論できないの？

**デフォルトの名無しさん** · 2018/08/25(土) 21:29:55.14

>>106
ID:KMExyDFm は、はぐらかしを続けてスレを流しているのではないでしょうか？
ロジカルな反論は全くできていないし、する気もないのでしょう。
ID:KMExyDFm が負けを認めているのと一緒です。

**デフォルトの名無しさん** · 2018/08/25(土) 21:33:07.32

>>108
議論に勝ちも負けも良いも悪いもないよ
そうやってなんでもかんでも勝ち負けで考えるから
相手を貶めてやろうなんてことになって
議論が成り立たなくなるんだよ

Wikipediaに書き込む時は冷静になってから書き込むんやで
Wikipediaに勝ち負けなんてないんやからな、おじさんとの約束やで

**デフォルトの名無しさん** · 2018/08/25(土) 21:35:30.91

>>109
やはりはぐらかすだけですね。こんな人にかまっても時間の無駄です。

**デフォルトの名無しさん** · 2018/08/25(土) 21:38:13.82

>>110
だな。もうやめとくわ。

**デフォルトの名無しさん** · 2018/08/25(土) 21:42:32.14

プログラムを実際に書いてると同じような処理があれば纏めようとするだけで、それが構造化にしなきゃとかオブジェクト指向にしなきゃとか考えないよ
そういうのに拘るのは教科書知識で定義をうんちく垂れてる層か他人が作ったのを組み合わせてるだけの層
でしょ
ぶっちゃけ定義なんてどうでもいい

**デフォルトの名無しさん** · 2018/08/25(土) 21:43:07.54

『抽象（abstract）』及び『フローチャートのネスト（nest）すなわち段階的詳細化[17]』である。
『抽象（abstract）及びフローチャートのネスト（nest）』すなわち『段階的詳細化[17]』である。

誤読されたくなければ読点でも入れとけ

**デフォルトの名無しさん** · 2018/08/25(土) 21:43:55.80

君たちは何を成し遂げたいんですか？

Wikipediaの内容が気に入らないなら書き換えればいいじゃないですか
それをやらずにこのスレで客観性を欠くバイアスを掛け合って
心地よくなっても意味がないというか、それこそ時間の浪費ですよ

**デフォルトの名無しさん** · 2018/08/26(日) 00:54:37.75

酷い流れだ

**デフォルトの名無しさん** · 2018/08/26(日) 01:02:24.37

I.hidekazu登場

https://ja.wikipedia.org/wiki/%E3%83%8E%E3%83%BC%E3%83%88:%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

人の話を聞かないではぐらかすところがID:KMExyDFmに似ている

**デフォルトの名無しさん** · 2018/08/26(日) 04:22:57.95

構造化プログラミングについてI.hidekazuの理解が完全に間違っている証拠

この投稿の時点で現行のI.hidekazu版の構造化プログラミングの記事では
「ダイクストラの構造化技法」などという項目があり、そこには
＞従来のフローチャートの進行方向を単線化するため、プログラムは順序的プログラムでなくてはならず、
＞さらにその順序的プログラムはフローチャートの制御の規律を固守するため[23]、
＞・・・、goto文は使用しないようにすべきであるとした[26][28]。

そもそもダイクストラは技法など述べたことはない。
彼の有名な「構造的プログラミング」（ホーア、ダールとの共著書の中の彼の論説）でも
段階的に詳細化を行ってプログラムに至るという考え方については述べているが
とても技法と呼べるほど具体的で詳細な技術レベルのものではなくせいぜい「正しい考え方」に過ぎない。

更に言えば、ダイクストラは「goto文は使用しないようにすべきである」というような単純な規準は主張していない。
これを主張したのはダイクストラでなくIBMのMillsである。

ダイクストラの主張したことは「goto文は検証の障害になることが多い」ということと
「プログラムはその正しさを示せるように書かれるべきである」ということである。
この２つの主張と「goto文は使用しないようにすべきである」という正しくはMillsの主張とが全くの別物だと
理解できないI.hidekazuのような類の人間は「構造化プログラミング」の記事を執筆すべきでない。

そういうダイクストラの主張に無理解でまたMillsの役割も知らず彼の名前もその記事の中で正しく位置付けられない
全くの無知な素人が、記事を勝手に書くことは他の執筆者や利用者にとって全くの迷惑をかけるだけなので
己の無知蒙昧さを自覚して執筆せず前のバージョンに戻して自重するのが正常な人間として最初に成すべき事柄である。

**デフォルトの名無しさん** · 2018/08/26(日) 04:27:40.47

>>117訂正
> 彼の有名な「構造的プログラミング」（ホーア、ダールとの共著書の中の彼の論説）でも

失礼、「構造的プログラミング」→「構造化プログラミング」

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

>>117
ここでイキってないでWikipediaで議論するか
書き換えるかしなよ、いい加減邪魔だよ

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

ダイクストラ文学というべきかなあ、このときの作者の思いを述べなさいみたいな
読書感想文なんだよね、構造化プログラミングは文学なのかね

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

>「goto文は検証の障害になることが多い」
>「プログラムはその正しさを示せるように書かれるべきである」

>「goto文は使用しないようにすべきである」

ついでに言うと、これは演繹してるだけだから全く同じことを述べてる

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

>>66
COBOLってさ
プログラム仕様書をそのままプログラム化させるのが目的なようで、宣言文だらけ
プログラムの半分が宣言文じゃないかっていうぐらい
回りくどいんだよね
データのバイト長(ワード長)まで記述してんだから
演算子も確か記号使わず、単語だし
足し算ならPLUSなどと初期のLISPみたいで
(うろ覚え)

**デフォルトの名無しさん** · 2018/08/26(日) 13:22:18.83

>>117
>>116の一番下に書けば？

**デフォルトの名無しさん** · 2018/08/26(日) 13:23:30.72

>>121
お前、昨日登場した基地外だな
そこしか突っ込めないのかよ
自分の都合の悪いことにはツッコミできないんだなw

**デフォルトの名無しさん** · 2018/08/26(日) 13:29:42.32

バイアス要員が来ました

**デフォルトの名無しさん** · 2018/08/26(日) 13:31:18.29

わざわざ同じワード使って自己紹介しなくても

**デフォルトの名無しさん** · 2018/08/26(日) 14:37:42.81

hidekazu の人気に嫉妬…　＞＜

**デフォルトの名無しさん** · 2018/08/26(日) 14:54:55.94

>>117
そこまで書けるなら>>116のWikipediaの「構造化プログラミング」のノートに書けばいいのに。
書いていることは正しいのに行動に移さないのはちょっとねえ

**デフォルトの名無しさん** · 2018/08/26(日) 15:20:05.51

このｽﾚの低学歴低知能たちは
教育用や論文の疑似ｺｰﾄﾞに
なんでpascalがよく採用されてるか
まったく分かってない