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

**デフォルトの名無しさん** · 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/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がよく採用されてるか
まったく分かってない

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

>>129
どうしてなんですか？
先生教えてください

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

それが分かる程度ならWikipediaを編集できる
わかった？

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

>>131
先生はWikipediaを編集できるのですか？

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

編集できる
しかしｵﾚはwikipedeiaなんか編集しない
編集できることと編集することは
まったく関係ないからな

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

>>133
先生は教育用や論文の疑似ｺｰﾄﾞになんでpascalが採用されてるかわかりますか？

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

分かってる
しかしｵﾚはこのｽﾚにその理由なんか書かない
ｵﾚが分かってることと、ｵﾚがこのｽﾚに書くことは
まったく関係ないからな

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

>>135
僕は知りたいと思ってます
僕以外にもわからない人いると思います
スレにとって有意義だと思います

教えてください
なんでpascalが採用されてるんですか？

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

https://en.wikipedia.org/wiki/Structured_program_theorem
いちいちｵﾚがｽﾚに書かなくてもｺｺに書いてある
ｵﾚがいちいちｽﾚに書く理由がない

**デフォルトの名無しさん** · 2018/08/26(日) 16:05:39.46

>>128
Wikipediaのアカウント作ってないし、それ以前にWikiの書き方を知らないんだ
これだけのために書き方を勉強する気もしないしね

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

いくつかの学者は、Bohm-Jacopiniの結果に純粋なアプローチをとり、B?h
m-Jacopiniの証拠では必要でないため、ループの途中からの復帰や復帰な
どの命令でさえ悪い習慣であると主張し、すべてのループが単一の出口点。
この純粋主義的アプローチは、1990年代半ばまでの学術の入門プログラミン
グ授業の教授のための好ましいツールであったパスカル・プログラミング言
語（1968-1969年に設計されたもの）で具現化されている[9]

B?hm-Jacopini定理を直接適用すると、構造化されたグラフに追加の局所変
数が導入され、コードの重複も生じる可能性があります。後者の問題は、こ
の文脈ではループと半分の問題と呼ばれている[13]。パスカルはこれらの問
題の両方に影響され、Eric S. Robertsの経験的研究によれば、学生のプ
ログラマは、配列内の要素を検索する関数を書くことを含む、いくつかの単
純な問題に対してPascalで正しい解決策を定めることが困難でした。ロバー
ツが引用したHenry Shapiroの1980年の調査では、Pascalが提供する制御
構造だけを使用した場合、被験者の20％のみが正しい解答を得たが、被験者
はこの問題のコードを書いていなかった。ループの真中[9]

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

>>121
> 「goto文は検証の障害になることが多い」
> >「プログラムはその正しさを示せるように書かれるべきである」
>
> >「goto文は使用しないようにすべきである」
>
> ついでに言うと、これは演繹してるだけだから全く同じことを述べてる

それが君やI.hidekazuの根本的な間違い

Dijkstraの主張は正しさを示せるようなプログラムを書くべきということであって
gotoは障害になり易いと主張しているに過ぎない

つまり正しさを示す上で障害にならないgoto文まで使用すべきでないとはDijkstraは主張していない
goto文を使わず３基本構造で書けという分かり易いが極めて薄っぺらな主張をしたのはDijkstraでなくMillsだよ

これを区別できない人間は己の無知を認識して黙ってろ

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

>>140
それはダイクストラを悪者にしたくないという気持ちの現れだわ
お気持ちが混じり合ってど汚い色に変色してる

ダイクストラに対する冒涜だわ、ダイクストラはそんな薄っぺらいことが
言いたかったんじゃない、goto文はプログラムの障害だと明確に述べている

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

Millsはダイクストラの発言を明確に理解してる

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

>>142
こいつ完全に狂っているわw

**デフォルトの名無しさん** · 2018/08/26(日) 16:39:29.01

構造化ﾌﾟﾛｸﾞﾗﾑの理念は
3つの制御構造で適切なｺｰﾄﾞすら記述できないｱﾝﾘｶﾊﾞﾌﾞﾙな知恵遅れは
ｺｰﾄﾞなんか書いてはﾀﾞﾒということだからな

頭悪いﾊﾞｶはあっちいけといってるﾜｹ

わかった？

**デフォルトの名無しさん** · 2018/08/26(日) 16:39:47.15

>>138
Wikipedia は間違えた情報を広める害悪だわな。
Google の重視する網羅性が突出しているので、どうしても検索の上位になってしまう。

しかし、Wikipedia の書き方なんて勉強ってほどでもないと思うけどねえ。

**デフォルトの名無しさん** · 2018/08/26(日) 16:44:00.05

>>143
Pascalは論文の疑似コードに採用されてる
お前はその理由を解ってない

**デフォルトの名無しさん** · 2018/08/26(日) 16:56:18.06

>>142
>>146
Mills がダイクストラの発言を明確に理解しているとしたら悪質だな。
ダイクストラの構造化プログラミングを構造化定理とすり替えて広めたのは Mills の故意ってことになる。

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

>>147
君は理解の意味を履き違えている
日本語の文法を勉強したが良い
Millsは悪くない
ダイクストラはMillsに感謝してる

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

>>148
>ダイクストラはMillsに感謝してる

ソース

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

Millsはダイクストラの発言を敷衍したんだよ
換言するとMillsの発言はダイクストラの発言とみなせるってこと

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

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

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

これがそのソース
Millsはダイクストラをフォローアップしてるわけ

**デフォルトの名無しさん** · 2018/08/26(日) 17:03:51.84

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#I.hidekazu%E3%81%95%E3%82%93%E3%81%AE%E4%BF%AE%E6%AD%A3%E3%81%8C%E9%85%B7%E3%81%99%E3%81%8E%E3%82%8B%E4%BB%B6

I.hidekazu という人は人の話を全く聞かない。アスペルガーなのかもしれない。

**デフォルトの名無しさん** · 2018/08/26(日) 17:07:00.07

>>150
ふえん
【敷衍】
《名・ス他》意味のわかりにくい所を、やさしく言い替えたり詳しく述べたりして説明すること。

Mills のニセ構造化プログラミングは、敷衍（ふえん）ではなくて、劣化に過ぎない。

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

>>152
こっちの方が痛いと思う
https://ja.wikipedia.org/wiki/%E5%88%A9%E7%94%A8%E8%80%85:Monadaisuki

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

Monadaisuki曰く

Wikipedia中毒者はWikipediaを使いこなすことにエリート意識を感じ、他
人の記事に因縁・難癖をつけて優越感を得るのを日常とする人間があまりに
も多い

Monadaisukiがやってることのように思えるが

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

>>154
>>155
反論できないから無関係のものを持ち出す典型例