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

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

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

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

**デフォルトの名無しさん** · 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
反論できないから無関係のものを持ち出す典型例

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

このｽﾚはﾈﾄｦﾁｽﾚか
ﾈﾄｦﾁならﾈﾄｦﾁ板がある

そっちで楽しくやりなさい

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

>>156
>>152がアスペルガーだと言ってI.hidekazuの人格攻撃をしていたので
それに対するカウンターとしてMonadaisukiの方がヤヴァくない？
と言ってみました、どう思います？ Monadaisukiの言動について

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

>>157
先生はPascalでプログラミングやるんですか？

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

構造化プログラミングが捗る言語とかあったら教えて欲しいです

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

>>158
少なくともWikipediaの構造化プログラミングの記事に関してはまともな行動をしているだろう。

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

昔、turbo pascalを実習で使ったことはある　ｺﾚはPCで使えた
まさに、ｸﾞﾗﾌ使って最短経路求めるﾔﾂとかもその実習の中に入ってた　
それ以来使ったことない

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

>>155
まあ、Wkipediaに問題が多いのは間違いないかと。
それと Monadaisuki は Wikipedia に対する貢献も大きい。
いくつかの英文記事を翻訳している。
特に「ズブルチの偶像」の翻訳は英語版Wikipediaを読み込んで書かれた傑作。

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

>>163
ITが専門やないんやな
道理で

**デフォルトの名無しさん** · 2018/08/26(日) 18:32:27.68

>>164
>>148みたいなキチガイ説を唱えているお前こそIT素人だろwww

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

>>165
いま、ワイの話してるんちゃうやろ！
Wikiで議論してる連中の話や
石像が専門の人が知ったかして絡んでるだけやな

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

>>166
もっと調べろよw
https://ja.wikipedia.org/wiki/%E5%88%A9%E7%94%A8%E8%80%85:Monadaisuki#%E6%96%B0%E8%A6%8F%E3%81%AB%E4%BD%9C%E6%88%90%E3%81%97%E3%81%9F%E9%A0%85%E7%9B%AE

F1、オーディオ、IT、電卓、石像と色々ある。

**デフォルトの名無しさん** · 2018/08/26(日) 18:38:31.00

>>166
それとは別にお前が基地外なのは事実だろw

**デフォルトの名無しさん** · 2018/08/26(日) 18:41:10.37

>>167
なるほど、なるほど、プログラミングについてはズブの素人とお見受けしました

>>168
キチガイはお前やろ、引くわ

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

はい話題のすり替え完了

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

>>170
ほんまそれな

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

発端は >>67 からやな
とどのつまり結論としては Monadaisuki がニワカというのが
このスレの総意であり最終回答
Wikiの話はこれで終いや

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

>>172
勝手に総意にするな。だから基地外扱いされる。
それと、I.hidekazuの書いていることが正しいかどうかが問題であって、
もう一人がニワカだろうがニカワだろうがどうでもいい。

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

>>173
あのな、5才児と東大の教授が違うことを言ってた場合
東大の教授の方が正しいに決まってるだろ
常識で考えろよ

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

>>174
お前みたいな奴のせいで権威だけ気にして情報の質を考えないアホが増えたわけだ。

I.hidekazu
https://ja.wikipedia.org/wiki/%E5%88%A9%E7%94%A8%E8%80%85:I.hidekazu

全記事調べたけど、I.hidekazu が新規作成した項目はない。
他人の記事にちょっかいだすだけのクズ

そもそも I.hidekazu に権威があるとなぜ言える？あ、本人の降臨か？
I.hidekazu = ID:IHxJX3F+

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

>>175
> 全記事調べたけど、I.hidekazu が新規作成した項目はない。

何が言いたいんですか？
そんなに権威が大事ですか？

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

>>176
あんたが言い出したんだろ
自分の言ったことに責任持てよ！

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

日本のwikipediaはyahoo知恵遅れ程度の情報の質だからな
むしろ新規作成したことあるならﾔﾊﾞｲわ

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

>>178
だったら書かなかったら？
I.hidekazu = ID:IHxJX3F+ = ID:hANAm2gW

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

ごちゃごちゃ言う前に修正したら良いだろ
wikipediaなんだから

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

>>180
ノートで合意を形成するのが理想。
次点で I.hidekazu の反対派があそこに大量に書き込んで多数決状態に持って行く。
最悪は I.hidekazu の修正を元に戻して編集合戦に移行する。

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

どうせ書き込んだやつは満足して消え去ってる
まずは戻してそいつを召喚するのが先
でないといつまでたっても戻せない

**デフォルトの名無しさん** · 2018/08/26(日) 21:51:19.01

こんなとこで争ってんのか
とんだ迷惑もいいところ

知恵遅れﾊﾟﾖﾁｮﾝのｻﾏｰﾀｲﾑｽﾚと似てる

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

ここを見た人（2400:4176:21c8:4710:98e7:fa2d:da98:52ec）だろうけど、これでは取り消しになってないよ。

＞平成30年8月26日 (日) 12:25‎ 2400:4176:21c8:4710:98e7:fa2d:da98:52ec (会話)‎ . . (37,522バイト) (-5,202)‎ . . (https://mevius.5ch.net/test/read.cgi/tech/1534260508/ で酷い内容と書かれていたので取り消し)

元に戻すには、平成30年8月20日 (月) 17:16‎ (UTC) のソースコードを丸ごとコピーして、今のソースコードを全部削除してからそれを貼り付ける必要がある。
ただし、今はそこまでやる必要はない。

>>182
I.hidekazu はこんなことを言っている。

＞近いうちに図表の追加も含めて修正したいと思いますので、しばしの間ご容赦願います。

編集合戦になるのは明らかかと

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

>>184
どういうこと？

平成30年8月20日 (月) 17:16‎ (UTC) のソースコードと
現在の版に相違点はないんだけど？

＞近いうちに図表の追加も含めて修正したいと思いますので、しばしの間ご容赦願います。

どうせこない。だいたい編集は用意してからやるべきことだ。

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

>>185
すまぬ。平成30年8月13日 (月) 14:21‎ (UTC)だった。

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

>>186
なるほど

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

しばしの間ご容赦願いますとか書いて、
どうせそのまま放置して、大きな反論もないし
事実上この内容で同意取れたってことにするつもりだろ

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

>>188
元に戻してくれた人がいた。

平成30年8月26日 (日) 13:03 (UTC)‎ 114.157.218.74 (会話)‎ . . (33,159バイト) (-4,363)‎ . . (戻す版を間違えていたので修正)

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

>>189
あぁ、それな。同一人物だよ。IPv4とIPv6の両方が有効だと
どちらでつながるかはブラウザの気まぐれなんだよ

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

>>190
確か IPv6 で先に通信して失敗したら IPv4 でリトライだったのでは？

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

>>191
いや、ブラウザの気まぐれ。
おそらく速い方だけど、誤差で切り替わる

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

このｽﾚ
ﾓﾅﾀﾞｲｽｷきてるわ

電卓ｦﾀで電卓の新規ﾍﾟｰｼﾞ書いたﾓﾅﾀﾞｲｽｷきてるわ

逆ﾎﾟｰﾗﾝﾄﾞ記法で記述するﾌﾟﾛｸﾞﾐﾝｸﾞﾊﾟﾗﾀﾞｲﾑで
ｵﾌﾞｼﾞｪｸﾄ指向とかwikipediaに書いてるﾓﾅﾀﾞｲｽｷきてるわ

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

>>192
（　´_ゝ`）ﾌｰﾝ

>>193
論理的に反論してください
そいつのことはどうでもいい

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

>>194
まあ知らないなら勉強すればいいだけだよ。恥ずかしくないよｗ
https://productforums.google.com/forum/?hl=ja#!topic/chrome-ja/tIbaS1oRIDk;context-place=forum/chrome-ja

> IPv6フォールバックやIPv6無効化等とは180度方向性が違うのですが、IPv4/v6デュアルスタック環境下で、パフォーマンスの
> 問題からChromeにIPv6を優先して使用するようにさせるオプションはありますか？
>
> と言うのは、ChromeとFirefoxでIPv6への接続挙動が異なるからです。
> https://www.youtube.com/ に接続し動画を視聴した場合、同じ環境化でFirefoxはIPv6側に優先的に多数接続しますが、
> Chromeは1-2個を除いては殆どIPv4で接続しています。

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

>>193
>逆ﾎﾟｰﾗﾝﾄﾞ記法で記述するﾌﾟﾛｸﾞﾐﾝｸﾞﾊﾟﾗﾀﾞｲﾑで
>ｵﾌﾞｼﾞｪｸﾄ指向とかwikipediaに書いてるﾓﾅﾀﾞｲｽｷきてるわ

それってRPL言語のこと？（Forthじゃないよね？）
英語版Wikipediaにこうかいてあるんですけど
https://en.wikipedia.org/wiki/RPL_(programming_language)

＞Paradigm : stack, structured, object-oriented

その人はこれをそのまま翻訳しただけ。
それにRPLのスタックに入れるものはオブジェクトなので、別に間違いでもない。
自分でクラスを作ることはできないが、オブジェクト指向的に作られている面はある。

>>195
どうしてここで IPv6 の話が出てくるのか？
それにFirefoxがIPv6側に優先なら自分は別に間違えてもいない。
それよりも I.hidekazu の正当性を説明せよ。

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

Happy Eyeballsって名前があるんだな。しかもRFCで標準化されてる

https://www.nic.ad.jp/ja/basics/terms/happy-eyeballs.html

Happy Eyeballsとは、 IPv6とIPv4の共存期において、 IPv6とIPv4の双方が利用可能な
デュアルスタック環境において発生するフォールバック問題(*)を緩和するために、
IPv4とIPv6のうち通信状態の良い方を優先する仕組みです。

Happy Eyeballsでは、通信開始当初からIPv6とIPv4の両方のプロトコルを用いて通信先と接続を行い、
先に接続に成功した方のプロトコルから得られた結果をユーザーへ出力します。

通信が失敗した後に、別のプロトコルを用いてあらためて通信を開始する場合と比較して、
切り替えに必要な時間を短縮することが可能になると想定されています。

Happy EyeballsはRFC6555で標準化されており、クライアントがサーバへ接続する際の
DNS名前解決や接続方法が個別に規定されています。

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

>>196
IPv6の話は私が書いたんですけど？

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

>>198
すまぬ。腹が立ったので、自分のことのように感じた。

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

なるほどね。Firefoxも切り替わるようになってるのね

http://www.net.c.dendai.ac.jp/~kodaira/

　FirefoxやGoogle Chromeでは既にHappy Eyeballsが実装されており、
こちらはDNS問い合わせで先に応答した方で通信を試みるという方法を採っている。
また、もしこれが300[ms]経過してもACKが返ってこない場合は通信失敗とみなして次の候補アドレスで通信を試みる。