構造化プログラミングはまだ必要ではないのか？
■ このスレッドは過去ログ倉庫に格納されています
構造化プログラミングで言うところの「抽象化データ構造とその操作の抽象文の共同詳細化」はオブジェクト指向のクラスで実現された。
しかし、オブジェクト指向だけでは、階層化と段階的詳細化と段階的抽象化が実現できない。
まだ構造化プログラミングは必要なのではないのか？
しかし、今は風化しているように思えて仕方がないし、ダイクストラの考えを知っていれば、もっとマシなコードが書けそうだが。
（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 >>99
何度も言ってるけど、俺はI.hidekazuではないよ
君は思い込みが激しいね
こうだと思いこんだらそれは違うよと言っても考えを改めない
難儀な性格してるね、文章もまともに読めないし
5chでバイアスかけられてイキってるだけじゃん >>102
だったらどういうロジックで俺が間違えているのか書いてみろ >>100
AおよびB、Cである
という文を
AがBであると読み取るその読解力のなさ
思い込みの激しさたるやもう助けようがないよ 論理的な思考力の弱い人は
普段接するようなものに例えてみると
理解力があがるという認知学の研究結果がある
それをふまえて例文を示そう
空を飛ぶのは鳥および飛行機、すなわちトンボである
という文は
鳥がトンボであることを述べていない >>104
そうやってはぐらかしてないで反論してみろ。できないよな？負け犬。 >>106
またそうやって相手を貶す発言をする
そういうことを言うから君の言うことに説得力がなくなるんだよ
もっと冷静に議論できないの？ >>106
ID:KMExyDFm は、はぐらかしを続けてスレを流しているのではないでしょうか？
ロジカルな反論は全くできていないし、する気もないのでしょう。
ID:KMExyDFm が負けを認めているのと一緒です。 >>108
議論に勝ちも負けも良いも悪いもないよ
そうやってなんでもかんでも勝ち負けで考えるから
相手を貶めてやろうなんてことになって
議論が成り立たなくなるんだよ
Wikipediaに書き込む時は冷静になってから書き込むんやで
Wikipediaに勝ち負けなんてないんやからな、おじさんとの約束やで >>109
やはりはぐらかすだけですね。こんな人にかまっても時間の無駄です。 プログラムを実際に書いてると同じような処理があれば纏めようとするだけで、それが構造化にしなきゃとかオブジェクト指向にしなきゃとか考えないよ
そういうのに拘るのは教科書知識で定義をうんちく垂れてる層か他人が作ったのを組み合わせてるだけの層
でしょ
ぶっちゃけ定義なんてどうでもいい 『抽象（abstract）』及び『フローチャートのネスト（nest）すなわち段階的詳細化[17]』である。
『抽象（abstract）及びフローチャートのネスト（nest）』すなわち『段階的詳細化[17]』である。
誤読されたくなければ読点でも入れとけ 君たちは何を成し遂げたいんですか？
Wikipediaの内容が気に入らないなら書き換えればいいじゃないですか
それをやらずにこのスレで客観性を欠くバイアスを掛け合って
心地よくなっても意味がないというか、それこそ時間の浪費ですよ 構造化プログラミングについてI.hidekazuの理解が完全に間違っている証拠
この投稿の時点で現行のI.hidekazu版の構造化プログラミングの記事では
「ダイクストラの構造化技法」などという項目があり、そこには
＞従来のフローチャートの進行方向を単線化するため、プログラムは順序的プログラムでなくてはならず、
＞さらにその順序的プログラムはフローチャートの制御の規律を固守するため[23]、
＞・・・、goto文は使用しないようにすべきであるとした[26][28]。
そもそもダイクストラは技法など述べたことはない。
彼の有名な「構造的プログラミング」（ホーア、ダールとの共著書の中の彼の論説）でも
段階的に詳細化を行ってプログラムに至るという考え方については述べているが
とても技法と呼べるほど具体的で詳細な技術レベルのものではなくせいぜい「正しい考え方」に過ぎない。
更に言えば、ダイクストラは「goto文は使用しないようにすべきである」というような単純な規準は主張していない。
これを主張したのはダイクストラでなくIBMのMillsである。
ダイクストラの主張したことは「goto文は検証の障害になることが多い」ということと
「プログラムはその正しさを示せるように書かれるべきである」ということである。
この２つの主張と「goto文は使用しないようにすべきである」という正しくはMillsの主張とが全くの別物だと
理解できないI.hidekazuのような類の人間は「構造化プログラミング」の記事を執筆すべきでない。
そういうダイクストラの主張に無理解でまたMillsの役割も知らず彼の名前もその記事の中で正しく位置付けられない
全くの無知な素人が、記事を勝手に書くことは他の執筆者や利用者にとって全くの迷惑をかけるだけなので
己の無知蒙昧さを自覚して執筆せず前のバージョンに戻して自重するのが正常な人間として最初に成すべき事柄である。 >>117訂正
> 彼の有名な「構造的プログラミング」（ホーア、ダールとの共著書の中の彼の論説）でも
失礼、「構造的プログラミング」→「構造化プログラミング」 >>117
ここでイキってないでWikipediaで議論するか
書き換えるかしなよ、いい加減邪魔だよ ダイクストラ文学というべきかなあ、このときの作者の思いを述べなさいみたいな
読書感想文なんだよね、構造化プログラミングは文学なのかね >「goto文は検証の障害になることが多い」
>「プログラムはその正しさを示せるように書かれるべきである」
>「goto文は使用しないようにすべきである」
ついでに言うと、これは演繹してるだけだから全く同じことを述べてる >>66
COBOLってさ
プログラム仕様書をそのままプログラム化させるのが目的なようで、宣言文だらけ
プログラムの半分が宣言文じゃないかっていうぐらい
回りくどいんだよね
データのバイト長(ワード長)まで記述してんだから
演算子も確か記号使わず、単語だし
足し算ならPLUSなどと初期のLISPみたいで
(うろ覚え) >>121
お前、昨日登場した基地外だな
そこしか突っ込めないのかよ
自分の都合の悪いことにはツッコミできないんだなw >>117
そこまで書けるなら>>116のWikipediaの「構造化プログラミング」のノートに書けばいいのに。
書いていることは正しいのに行動に移さないのはちょっとねえ このｽﾚの低学歴低知能たちは
教育用や論文の疑似ｺｰﾄﾞに
なんでpascalがよく採用されてるか
まったく分かってない >>129
どうしてなんですか？
先生教えてください それが分かる程度ならWikipediaを編集できる
わかった？ >>131
先生はWikipediaを編集できるのですか？ 編集できる
しかしｵﾚはwikipedeiaなんか編集しない
編集できることと編集することは
まったく関係ないからな >>133
先生は教育用や論文の疑似ｺｰﾄﾞになんでpascalが採用されてるかわかりますか？ 分かってる
しかしｵﾚはこのｽﾚにその理由なんか書かない
ｵﾚが分かってることと、ｵﾚがこのｽﾚに書くことは
まったく関係ないからな >>135
僕は知りたいと思ってます
僕以外にもわからない人いると思います
スレにとって有意義だと思います
教えてください
なんでpascalが採用されてるんですか？ >>128
Wikipediaのアカウント作ってないし、それ以前にWikiの書き方を知らないんだ
これだけのために書き方を勉強する気もしないしね いくつかの学者は、Bohm-Jacopiniの結果に純粋なアプローチをとり、B?h
m-Jacopiniの証拠では必要でないため、ループの途中からの復帰や復帰な
どの命令でさえ悪い習慣であると主張し、すべてのループが単一の出口点。
この純粋主義的アプローチは、1990年代半ばまでの学術の入門プログラミン
グ授業の教授のための好ましいツールであったパスカル・プログラミング言
語（1968-1969年に設計されたもの）で具現化されている[9]
B?hm-Jacopini定理を直接適用すると、構造化されたグラフに追加の局所変
数が導入され、コードの重複も生じる可能性があります。後者の問題は、こ
の文脈ではループと半分の問題と呼ばれている[13]。パスカルはこれらの問
題の両方に影響され、Eric S. Robertsの経験的研究によれば、学生のプ
ログラマは、配列内の要素を検索する関数を書くことを含む、いくつかの単
純な問題に対してPascalで正しい解決策を定めることが困難でした。ロバー
ツが引用したHenry Shapiroの1980年の調査では、Pascalが提供する制御
構造だけを使用した場合、被験者の20％のみが正しい解答を得たが、被験者
はこの問題のコードを書いていなかった。ループの真中[9] >>121
> 「goto文は検証の障害になることが多い」
> >「プログラムはその正しさを示せるように書かれるべきである」
>
> >「goto文は使用しないようにすべきである」
>
> ついでに言うと、これは演繹してるだけだから全く同じことを述べてる
それが君やI.hidekazuの根本的な間違い
Dijkstraの主張は正しさを示せるようなプログラムを書くべきということであって
gotoは障害になり易いと主張しているに過ぎない
つまり正しさを示す上で障害にならないgoto文まで使用すべきでないとはDijkstraは主張していない
goto文を使わず３基本構造で書けという分かり易いが極めて薄っぺらな主張をしたのはDijkstraでなくMillsだよ
これを区別できない人間は己の無知を認識して黙ってろ >>140
それはダイクストラを悪者にしたくないという気持ちの現れだわ
お気持ちが混じり合ってど汚い色に変色してる
ダイクストラに対する冒涜だわ、ダイクストラはそんな薄っぺらいことが
言いたかったんじゃない、goto文はプログラムの障害だと明確に述べている 構造化ﾌﾟﾛｸﾞﾗﾑの理念は
3つの制御構造で適切なｺｰﾄﾞすら記述できないｱﾝﾘｶﾊﾞﾌﾞﾙな知恵遅れは
ｺｰﾄﾞなんか書いてはﾀﾞﾒということだからな
頭悪いﾊﾞｶはあっちいけといってるﾜｹ
わかった？ >>138
Wikipedia は間違えた情報を広める害悪だわな。
Google の重視する網羅性が突出しているので、どうしても検索の上位になってしまう。
しかし、Wikipedia の書き方なんて勉強ってほどでもないと思うけどねえ。 >>143
Pascalは論文の疑似コードに採用されてる
お前はその理由を解ってない >>142
>>146
Mills がダイクストラの発言を明確に理解しているとしたら悪質だな。
ダイクストラの構造化プログラミングを構造化定理とすり替えて広めたのは Mills の故意ってことになる。 >>147
君は理解の意味を履き違えている
日本語の文法を勉強したが良い
Millsは悪くない
ダイクストラはMillsに感謝してる >>148
>ダイクストラはMillsに感謝してる
ソース Millsはダイクストラの発言を敷衍したんだよ
換言するとMillsの発言はダイクストラの発言とみなせるってこと >>149
ダイクストラ
>「goto文は検証の障害になることが多い」
>「プログラムはその正しさを示せるように書かれるべきである」
Mills
>「goto文は使用しないようにすべきである」
これがそのソース
Millsはダイクストラをフォローアップしてるわけ >>150
ふえん
【敷衍】
《名・ス他》意味のわかりにくい所を、やさしく言い替えたり詳しく述べたりして説明すること。
Mills のニセ構造化プログラミングは、敷衍（ふえん）ではなくて、劣化に過ぎない。 Monadaisuki曰く
Wikipedia中毒者はWikipediaを使いこなすことにエリート意識を感じ、他
人の記事に因縁・難癖をつけて優越感を得るのを日常とする人間があまりに
も多い
Monadaisukiがやってることのように思えるが >>154
>>155
反論できないから無関係のものを持ち出す典型例 このｽﾚはﾈﾄｦﾁｽﾚか
ﾈﾄｦﾁならﾈﾄｦﾁ板がある
そっちで楽しくやりなさい >>156
>>152がアスペルガーだと言ってI.hidekazuの人格攻撃をしていたので
それに対するカウンターとしてMonadaisukiの方がヤヴァくない？
と言ってみました、どう思います？ Monadaisukiの言動について >>157
先生はPascalでプログラミングやるんですか？ 構造化プログラミングが捗る言語とかあったら教えて欲しいです >>158
少なくともWikipediaの構造化プログラミングの記事に関してはまともな行動をしているだろう。 昔、turbo pascalを実習で使ったことはある ｺﾚはPCで使えた
まさに、ｸﾞﾗﾌ使って最短経路求めるﾔﾂとかもその実習の中に入ってた
それ以来使ったことない >>155
まあ、Wkipediaに問題が多いのは間違いないかと。
それと Monadaisuki は Wikipedia に対する貢献も大きい。
いくつかの英文記事を翻訳している。
特に「ズブルチの偶像」の翻訳は英語版Wikipediaを読み込んで書かれた傑作。 >>164
>>148みたいなキチガイ説を唱えているお前こそIT素人だろwww >>165
いま、ワイの話してるんちゃうやろ！
Wikiで議論してる連中の話や
石像が専門の人が知ったかして絡んでるだけやな >>166
それとは別にお前が基地外なのは事実だろw >>167
なるほど、なるほど、プログラミングについてはズブの素人とお見受けしました
>>168
キチガイはお前やろ、引くわ 発端は >>67 からやな
とどのつまり結論としては Monadaisuki がニワカというのが
このスレの総意であり最終回答
Wikiの話はこれで終いや >>172
勝手に総意にするな。だから基地外扱いされる。
それと、I.hidekazuの書いていることが正しいかどうかが問題であって、
もう一人がニワカだろうがニカワだろうがどうでもいい。 >>173
あのな、5才児と東大の教授が違うことを言ってた場合
東大の教授の方が正しいに決まってるだろ
常識で考えろよ >>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+ >>175
> 全記事調べたけど、I.hidekazu が新規作成した項目はない。
何が言いたいんですか？
そんなに権威が大事ですか？ >>176
あんたが言い出したんだろ
自分の言ったことに責任持てよ！ 日本のwikipediaはyahoo知恵遅れ程度の情報の質だからな
むしろ新規作成したことあるならﾔﾊﾞｲわ >>178
だったら書かなかったら？
I.hidekazu = ID:IHxJX3F+ = ID:hANAm2gW ごちゃごちゃ言う前に修正したら良いだろ
wikipediaなんだから >>180
ノートで合意を形成するのが理想。
次点で I.hidekazu の反対派があそこに大量に書き込んで多数決状態に持って行く。
最悪は I.hidekazu の修正を元に戻して編集合戦に移行する。 どうせ書き込んだやつは満足して消え去ってる
まずは戻してそいつを召喚するのが先
でないといつまでたっても戻せない こんなとこで争ってんのか
とんだ迷惑もいいところ
知恵遅れﾊﾟﾖﾁｮﾝのｻﾏｰﾀｲﾑｽﾚと似てる ここを見た人（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 はこんなことを言っている。
＞近いうちに図表の追加も含めて修正したいと思いますので、しばしの間ご容赦願います。
編集合戦になるのは明らかかと >>184
どういうこと？
平成30年8月20日 (月) 17:16 (UTC) のソースコード と
現在の版に相違点はないんだけど？
＞近いうちに図表の追加も含めて修正したいと思いますので、しばしの間ご容赦願います。
どうせこない。だいたい編集は用意してからやるべきことだ。 >>185
すまぬ。平成30年8月13日 (月) 14:21 (UTC)だった。 しばしの間ご容赦願いますとか書いて、
どうせそのまま放置して、大きな反論もないし
事実上この内容で同意取れたってことにするつもりだろ >>188
元に戻してくれた人がいた。
平成30年8月26日 (日) 13:03 (UTC) 114.157.218.74 (会話) . . (33,159バイト) (-4,363) . . (戻す版を間違えていたので修正) >>189
あぁ、それな。同一人物だよ。IPv4とIPv6の両方が有効だと
どちらでつながるかはブラウザの気まぐれなんだよ >>190
確か IPv6 で先に通信して失敗したら IPv4 でリトライだったのでは？ >>191
いや、ブラウザの気まぐれ。
おそらく速い方だけど、誤差で切り替わる このｽﾚ
ﾓﾅﾀﾞｲｽｷきてるわ
電卓ｦﾀで電卓の新規ﾍﾟｰｼﾞ書いたﾓﾅﾀﾞｲｽｷきてるわ
逆ﾎﾟｰﾗﾝﾄﾞ記法で記述するﾌﾟﾛｸﾞﾐﾝｸﾞﾊﾟﾗﾀﾞｲﾑで
ｵﾌﾞｼﾞｪｸﾄ指向とかwikipediaに書いてるﾓﾅﾀﾞｲｽｷきてるわ >>192
（ ´_ゝ`）ﾌｰﾝ
>>193
論理的に反論してください
そいつのことはどうでもいい >>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で接続しています。 >>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 の正当性を説明せよ。 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名前解決や接続方法が個別に規定されています。 >>198
すまぬ。腹が立ったので、自分のことのように感じた。 なるほどね。Firefoxも切り替わるようになってるのね
http://www.net.c.dendai.ac.jp/~kodaira/
FirefoxやGoogle Chromeでは既にHappy Eyeballsが実装されており、
こちらはDNS問い合わせで先に応答した方で通信を試みるという方法を採っている。
また、もしこれが300[ms]経過してもACKが返ってこない場合は通信失敗とみなして次の候補アドレスで通信を試みる。 >>199
（ ´_ゝ`）ﾌｰﾝ
>>197>>200
構造化プログラミングの話を・・・ ■ このスレッドは過去ログ倉庫に格納されています
