構造化プログラミングはまだ必要ではないのか？
構造化プログラミングで言うところの「抽象化データ構造とその操作の抽象文の共同詳細化」はオブジェクト指向のクラスで実現された。
しかし、オブジェクト指向だけでは、階層化と段階的詳細化と段階的抽象化が実現できない。
まだ構造化プログラミングは必要なのではないのか？
しかし、今は風化しているように思えて仕方がないし、ダイクストラの考えを知っていれば、もっとマシなコードが書けそうだが。
（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 コード書くときに「これはオブジェクト指向、あっちは構造化プログラム」っていちいち意識するかバカ者 >>2
とはいえオブジェクト指向だけで説明できないことも多い。
クラスにすれば全て解決ではない。
構造化プログラミングを意識しないと無駄なクラスをたくさん作ることになる。 >>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”運動は一層の盛り上がりを見せたというわけ >>1
Wikipediaより
>1987年の第9回ソフトウェア工学国際会議(ICSE)において、Millsは会場にチューリング賞受賞者がいないことを確かめると
>「ダイクストラやホーア達はどこへ行ってしまったのか。我々はもう彼らから学ぶものがないのか。」とその現状を批判した
>（しかし木村泉の見解が当たっていたとするならば、「ソフトウェア工学」をそういったものにしていった張本人こそが、その発言をしたMillsであるということになる）。
酷いよなあ
ダイクストラの研究を粉砕した張本人がよくこんなことを言えるわ （きちんとクラスが整理された上での）OOPこそ構造化プログラミングの結実したものと思っていたんだが違うのか 今はオブジェクト指向さえできれば十分という風潮がある。
しかし、オブジェクト指向は主にクラスを使うというだけであって、
綺麗で分かりやすいプログラムを書けるかどうかとは別問題。
構造化プログラミングは綺麗で分かりやすいプログラムを書く手法としては今でも大事かと。 >>8
>オブジェクト指向は主にクラスを使うというだけであって
そりゃいくら何でも偏見 COBOL、VB、Java…と時代が流れても馬鹿は馬鹿なコードを書く。 >>1
選択するようなもんじゃないじゃん・・・
何で片っぽだけで存在出来ると思ってんの？ >>1 がクソコードしか書けないのは分かったからいちいちスレ立てんな。 >>13
いや、ｽﾚ建ての言い分は稚拙かもしれないが、
型クラスベース+継承でソフトウエアを表現すると
依存の茂みを作ってスパゲティーの山になる欠点に薄々気がついて
王様の耳はロバの耳と、あえて言っているのかもしれない… >>14
オブジェクト指向で却ってややこしくなった面もあるかもね オブジェクト指向技術はエディタの機能で代替できるような気がする。
エディタにはコードの検索や置換機能があるし、
VimやSublime,サクラエディタで高速に既存コードを再利用できる。
だからエディタの機能やVimを極めれば継承とかほぼ要らないし、
再利用性重視でなくてもいい。
変更の影響範囲とかもエディタを使って洗い出せば、管理できる。
だからオブジェクト指向の高度な機能を使わなくてもエディタや
ツールで代替えできる。
コードの差分はGitやWinMergeで洗い出せる。
オブジェクト指向のガチガチの設計を書くととにかく
変数名、メソッド名などの名前が長くなる。
名前が横に長いと非常に読みにくく画面外に隠れるし、
名前というのはスペース区切りもカンマ区切りもないわけだから、
上記のエディタ機能で編集がやりにくい。
だからJavaみたいなガチガチのオブジェクト指向ってもう今の時代
必要ないんだと思う。JavaScriptやPythonくらいのオブジェクト指向
だけで十分だもの。
Javaの作法の時代遅れ感とか、馬鹿馬鹿しさってそろそろ気付くべき。 >>12
>>1
>まだ構造化プログラミングは必要なのではないのか？
条件が整えば不要になると自分で書いてるじゃん。 >>15
2010年のインタビューでは、オブジェクト指向の御大は「実現方法に欠点があった」と考えてるようだ。
オブジェクト指向プログラミングは間違いだったか?
https://www.infoq.com/jp/news/2010/07/objects-smalltalk-erlang
>このインタビューを受けたのは、Erlangの最初の開発者であるJoe Armstrong博士とSmalltalk、OOP、パターンに長い間関係している
>Ralph Johnson博士だ。私たちは「間違った道」を当てもなくさまよって
>きたが、これはオブジェクトの考え方の実現方法に欠点があったため
>であり、この考え方自体の欠点ではないと2人は述べた。 >>18
これってクラスが良くないってこと？
Erlangの仮想マシンのプロセスみたいなものが良いってこと？ そもそもオブジェクト指向は、データとアルゴリズムをクラスとして組み合わせただけのこと。
構造化プログラミングみたいに綺麗なコードを書くためのものではない。 >>21
なるほど、構造化プログラミングは設計手順でもあるのかー
オブジェクト指向だとドメイン駆動とかユースケース駆動なんかが
それにあたるのかね
Wikipediaの構造化プログラミングには↓こう書いてあって
> プログラムを記述するのではなく、機能を抽象化した「仮想機械」を想定し、その「仮想機械が提供する命令群」でプログラムを構成する
これってオブジェクトの設計にも当てはまるよね
オブジェクトは構造化の手段の一つとみることもできそう >>22
つーか、ダイクストラが抽象化データ構造という概念を提案していて、
それがオブジェクト指向のクラスに似た考えだった。 >>22
> > プログラムを記述するのではなく、機能を抽象化した「仮想機械」を想定し、その「仮想機械が提供する命令群」でプログラムを構成する
>
> これってオブジェクトの設計にも当てはまるよね
> オブジェクトは構造化の手段の一つとみることもできそう
ところがSimula 67の頃はともかく、Smalltalk-80以降のオブジェクト指向の人々は暴走して上の構造化プログラミングでの抽象機械という思考上の粒度とは
およそ対応しないほど細かい粒度のオブジェクトをどんどん使い始めた、例えば「１つの数だって立派なオブジェクトだ！」といった形でね
オブジェクト指向がそのように暴走しだした時＝オブジェクト原理主義が始まったから、オブジェクト指向を熱心に使う人々の大半は構造化プログラミングとは無関係になり、
オブジェクト指向で作られたプログラムはDijkstraが考えていたようなプログラムの正しさを論じやすいようにしっかりとした構造を持つものではなく、
まるで簡単に取り外しできて自由に回転できる自由継手ばかりで組み上げられたようなクネクネとして「形」というものが良く見えない代物になった
確かに細かいオブジェクトを自由に組み合わせて作れば部品の追加や削除は容易になるが、プログラムの正しさを論じるには余りにも自由度が高すぎて見通しが悪すぎる >>24
>ところがSimula 67の頃はともかく、Smalltalk-80以降のオブジェクト指向の人々は暴走して上の構造化プログラミングでの抽象機械という思考上の粒度とは
>およそ対応しないほど細かい粒度のオブジェクトをどんどん使い始めた、例えば「１つの数だって立派なオブジェクトだ！」といった形でね
確かにオブジェクト指向はそんなものだと漠然と思っていたけど
何でもオブジェクトにすればいいってものではないよなあ。
結局、オブジェクト指向の導入によってプログラムは難解になっただけだった。
柔軟性は上がったけど可読性は低下した。 >>25
暴走というより、プログラミングの可能性追究の過程だからね。
「可読性という産業的な面の利便性」とは別の、今で言えば自動プログラミングの方向だし。 Smalltalk で何でもオブジェクトになるのは文法と実装からほぼ必然なので許してやれ >>29
Smalltalkはオブジェクト指向を突き詰めたらどうなるのかを実現した言語だし >>28
「わかりみ」は文法違反の単なる誤用で日本語の意味のある単語としては認められない
＞本文中の他の「?み」の例、つまり「ありがたみ」や「悲しみ」それに漱石が使った「淋しみ」は
＞どれも形容詞「ありがたい」・「悲しい」・「淋しい」の語幹に「み」を付けて名詞化した言葉であるが「わかりみ」は違う
上に加えると
「わかりみ」の語根「わかり」は動詞「わかる」の連用形なので形容詞のように体言にかかり修飾することすらできない単語で
それに「〜み」を付けた形を日本語の言葉として使うのは単なる無知を曝け出しているだけのこと >>1
ダイクストラの提唱した検証を前提としたプログラミングが必要か？という
疑問であれば、これから必要だし今後はさらに重要になると断言できる
実際、24時間365日 正しく動作するバグ0の品質要求が当たり前な
組み込み開発の一部では、必須の技術要素になりつつある
ただし、ソフトウェア検証への対比としてオブジェクト指向を挙げる事に違和感がある
ソフトウェア検証とオブジェクト志向は互いに交差する概念であって対立はしない
実際、たとえば VDMにオブジェクト指向を導入したVDM++が登場しているし、
Alloy は最初からオブジェクト指向の概念を前提として設計されている >>31
言語学上はある表現が間違ってる云々といった議論は意味を持たない
例えば、あらゆる方言は標準語から見れば「誤り」だがそのような主張をする人はいない
一定の範囲で通用しているならそれは「正しい」言葉なのだ >>33
>実際、24時間365日 正しく動作するバグ0の品質要求が当たり前な
>組み込み開発の一部では、必須の技術要素になりつつある
具体的にどうやっているんだ？ >>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/ >>36
ありがとう。今の組込はそんなことをやっているんだなあ。 >>32
> Smalltalkなんて死んだ言語
Smalltalkは現役バリバリの言語処理系だが？→http://pharo.org/
そんなことも知らんとかアンテナ低すぎだぞ！wwwwww >>38
アンテナ強すぎてノイズ拾ってるんちゃうんか？ >>39
アンテナ「強」すぎとかググり力以前に日本語wwww セックスが強いとも言うし
匂いが強いとも言うのよ
強いって言葉は何にでも使っていいの万能なの ググり力ってなんすか？www日本語エントロピーが拡散してますよ try - catch の大域脱出は構造化プログラミングに入るの？
許されてるのかどうかが知りたい 例外処理やついでに継続なんかは本質的にGOTOだからもちろんダメだろ 構造化は今でも必要だと思うよ
初期の(今でも?)プログラミングで作られた物が大変だったのは
何もかもが広域だったから
構造化にしてもオブジェクト指向にしても
アクセス範囲を狭小化したのが一番効果が大きい
余りにも何処からでもアクセスされてるとそのアクセスパターンが発散してしまって
組み合わせ数が多くなりすぎて事前予測不可能になる(テストしきれない)
オブジェクト指向プログラミングは粒度が最小化可能な物で
それによってアクセスパターンを最小化してバグを発生させ難く出来る
この部分に一番効用が有る
人間の認識限界
これを理解しているかどうかが鍵となる
エドガーダイクストラが言った一番の要点はアクセス範囲の極小化する為に構造化を提唱した
だからcobolみたいにdataなんちゃらーとプロセデュアなんちゃらーみたいに
処理とアクセスする物が分離されている物が一番問題があると指摘した
basicは変数が広域なので問題が有ると指摘した
クラス型オブジェクト指向プログラミングシステムでは
クラス内に変数とその処理をパッケージングしてアクセス範囲を完全に限定した
だからpropery get/set みたいな内部変数を直接外部から操作するような書き方や
それしか出来ないような言語は問題が有るし
問題有りだと騒がれる >>44
try - catch は乱暴な仕組みだよなあ。
下の階層の例外を漏らさず捕獲する。
言い換えると下の階層を信用していない仕組み。
この仕組みのせいでますます適当にプログラミングできるようになったかもしれない。 むしろ逆だろ
適当なプログラミングするやつをカバーするために例外機構ができた >>49
現実に合わせるとそうなるのかねえ
構造化プログラミングは理想に過ぎないのか 入れ子にできるし
扱うフローが正常か異常かの違いかのお >>52
見た目的には構造化されているけど、大域脱出はある意味gotoに近いものがあるかと >>54
> 見た目的には構造化されているけど、大域脱出はある意味gotoに近いものがあるかと
脱出でのgotoは検証のしやすさを乱さないからDijkstra本来の構造化プログラミングの精神には反しない（というのを昔、誰かが書いてたように思うが詳しいことは覚えてない）
問題は例えば制御構造（複合文）の内部のラベルに向かって構造の外側からgoto文等のジャンプによって制御を移す（飛び込む）ケース、確かCとかでは許されたのでは
これを許すと検証が非常に面倒になるので構造化プログラミングとしては許し難い暴挙 とはいえ、関数ポインタ(継承含む)があると例外は検証できなくなるし
検証しようとシグネチャに例外の種類を明記させると大変面倒なことになるしなー
Swiftや、C++の新規格みたいに最近は例外を投げるか投げないかだけを明記するのが流行りっぽい >>58
> とはいえ、関数ポインタ(継承含む)があると例外は検証できなくなるし
関数ポインタが許される言語の検証は例外処理の検証以上に厄介だよ
現実問題として関数ポインタや手続き（関数）の引数・結果値としての手続き（関数）を許す言語の検証は
非常に労力を要することなるので実用的ではないと思うが 複数返り値さえあれば例外なんてほとんど必要ないのに >>構造化プログラミング
今でもCOBOLとPL/1では生きてるぞ >>67
酷いなそれw
フローチャートの書き方と完全に誤解していないか？ >>67
> Wikipedia の構造化プログラミングが I.hidekazu という奴のせいで酷い内容になっている。
・・・
> こいつは構造化定理と構造化プログラミングの区別ができているのか？
>>68
> 酷いなそれw
> フローチャートの書き方と完全に誤解していないか？
というか、このI.hidekazuって奴はDijkstraとMillsとは同一人物だとでも思ってるみたいね（苦笑） >>70
何をネタ元にしたらこんな記事が書けるのか？ >>67
ノートで抗議している人がいるけど聞く耳持つのかねえ？ 加筆前と大して変わってないぞ
図が入って連接・選択・繰り返しがわかりやすくなったくらいだろ
お前らろくに読んでないんじゃないか？ >>75
正しさの検証手法が詳しくなったよね
それ以外はまったく同じ
全部読んだ お前らろくに読みもせずにこのスレのバイアスだけで文句言ってるだろ
池沼どもが >>76
>>77
お前、I.hidekazu本人だろ？とっとと死ねよwww >>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に言わせると、構造化プログラミングを構造化定理と取り違えても誤解というほどの間違いではないということらしい。
明らかに構造化プログラミングと構造化定理の区別ができていない！ >>80
不十分な理解ということだろ
言ってること間違ってないじゃん
＞単純にgoto文を使用しないgoto-lessプログラミングと理解されていることが多い[4][5]。
この文削除でもいいくらい
誤解という言葉はそれってあなたのただの感想ですよねってことになる
感想文書くところじゃないから理解に修正したんだろ
削除してもいいくらいのクソ情報だよ >>81
お前、I.hidekazu本人じゃないの？ノートに似たようなことを書いているよな。
＞加えて、goto文の論争についてはバッサリ削除してしまっていいと思います。--I.hidekazu（会話） 2012年11月23日 (金)
それと、goto文の話以外は反論できないのか？まあ、できないだろうな。 >>82
それができていないのはあんただろ。
「誤解」が事実であって、「誤解という強い表現を使うほどではない」は完全に感想。 >>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は完全に理解ができていない。 >>83
違うよ、俺は完全に中立な第三者、その俺から見ても
修正前のものは感情的すぎるというか気持ち悪い
執筆者の感情と客観的な事実が混ざってどす黒い色になってる
こんなの書いてるから日本のWikipediaはバカにされるんだよ
>>84
誤解は事実ではないんですよ、みんなは誤解してるんだという思いなんですよ
書いた人間の思いが誤解という言葉には詰まっています
> 誤解という強い表現を使うほどではない」は完全に感想。
これが構造化プログラミングの中に書かれてたらヤバイですよ
でも書かれてないから問題ないんです
執筆者がどういう思いを持っているかを本文に書くべきではありません
あくまで中立に客観的に平等にそして公平に書くべきです >>86
>>85を読んでお前の池沼な頭で反論してみろ。
構造化定理と構造化プログラミングは完全に別物なんだよ！ >>87
そうやって罵詈雑言並べ立てて
相手が悪いかのようにしないと
正当性を主張できないんでしょ？
もうその時点でどうかと思うよ
>>85を読んだけど
I.hidekazuが言ってることが正しいと思った ID:KMExyDFm は、ID:HVFTZtzY が書いていることを理解できていないみたい。
こういう人が来ると疲れるわ。
本質的なことは>>4に書かれているけど、ID:KMExyDFm はこれも理解できないのかなあ？ >>88
>I.hidekazuが言ってることが正しいと思った
その根拠は？ 完全にI.hidekazuに論破されてるじゃん
書き換えて正解だよ >>89
それは全部Wikipediaに書いてあるよ
だから問題ないよね >>90
鬼絡みして相手を疲れさせようって魂胆かな
読めばわかるよね、自明だよ そんなに気に入らないなら自分で修正すれば良いのに
このスレでろくに読みもせずになんとなく間違ってる
雰囲気だから叩いておこうという卑しい心が透けて見えるよ
ほんとくだらない >>89
I.hidekazu本人が来ているだけなので何言っても無駄ですよ。
>>91
意味がわからん。I.hidekazuは誰も論破していない。
まあ、本人だからそういうことにしたいのだろうが。
>>92
書かれていない。Mills がどのようにして構造化プログラミングをダイクストラから奪ったのかが説明不足すぎる。
>>93
>読めばわかるよね、自明だよ
つまり反論できないってことか。 >>95
読解力ないからわからないだけでしょ
100回読み直したら？
> 抽象（abstract）及びフローチャートのネスト（nest）すなわち段階的詳細化[17]である
日本語文法わかる？ >>96
お前（I.hidekazu）、本当にアホだな。
段階的詳細化：抽象設計→詳細設計
段階的抽象化：プログラムコード→コードを括り出して抽象化
日本語文法が分かっていないのはお前だ！
だからWikipediaにあんなことを書くのだろうが！ >>97
及びの意味を考えろよ
単語の意味だけ考えて文章のコンテキストを読めてない
文盲って言うのかな、戦後の日本の国語教育の失敗だよね
結論を言うとWikipediaはいまのままでいい
読書感想文のような客観性のない感情論は削除しまくってもいいと思うけどね
消したら消したでアホどもが騒ぐからしかたなく残してるんだろうな
日本語のWikipediaの品質が低いのはそうしたアホなくせに時間だけは
持て余してるオタクどもに配慮しなければいけないからだろ I.hidekazu = ID:KMExyDFm は、ここで敗北すると面子丸つぶれなので必死。
I.hidekazuでGoogle検索するとここが出て来るからなwww >>98
>及びの意味を考えろよ
一［接］《漢文訓読で接続詞に使う「及」の字を「および」と読んだところから》複数の事物・事柄を並列して挙げたり、別の事物・事柄を付け加えて言ったりするのに用いる語。と。ならびに。また。そして。「生徒及び父兄」「国語、数学、及び英語は必修」
[補説]多くの語を並列するときは、最後にくる語との間にだけ置くことが多い。
二［名］及ぶこと。届くこと。
明らかに一の意味だ。
> 抽象（abstract）及びフローチャートのネスト（nest）すなわち段階的詳細化[17]である
つまり、I.hidekazuは「抽象が段階的詳細化に含まれる」と言っているわけだな。
アホじゃん。 >>98
>文盲って言うのかな、戦後の日本の国語教育の失敗だよね
それはお前だ。お前みたいな奴がいるから Wikipedia のレベルが低下する。 >>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
構造化プログラミングの話を・・・ > それよりも I.hidekazu の正当性を説明せよ。
正当性なんかないよ。
だから全て消されただろ
IPv4とIPv6を持つ誰かの手によってな >>202
正当性がないなら消されるのか
消されるなら正当性がないのか
どっち？ >>203
正当性がないなら、書き込みは無かったものとして扱われる
正当性がないものが書き込まれるってのがそもそも
悪いことなのでそれが無かった状態にされる
本来はなかったことにするのが一番いいのだがwikipediaの仕様上
それができないので削除で代用するしかないだけ >>204
消されないなら正当性があるってことやね
一昨日までは正当性があったんやな
Wikipediaの記事は全部正当性があるんやな >>205
気づかれてないだけ。気づかれればこうやってもとに戻される >>206
消すことの正当性がなかったら消したものが元に戻されますな
気づかれてないだけで 削除は勇み足というか、僕はそうは思わないっていう個人の感想レベルの
根拠なんだよな、ダイクストラ信者っていうのかなあの気持ち悪い感じ
ああいうオタクがWikipediaにのさばってるんやな >>207
消したのが元も戻るっていうのは意味不明。
（同じ内容で？）また書き込むだけでしょ？
正当性がないと判断された内容をまた書き込むとか
反感を買うだけだけどね 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
ご意見いただき誠にありがとうございます。私も最初はgoto-lessプログラミングというのは一種の誤解だと思っていましたが、よく考えれば、本当にはっきり間違いであれば提唱者のダイクストラがなにか言っていないとおかしいわけですし、そういう論文等が自分は見つけられなかったので、それほど大きく間違っていると判断することはできないと思いました。
「構造化プログラミング」という著書が既にあって内容も確認できる中、ちゃんと本で確認するプログラマーもいらっしゃるわけですし、そんな全くの間違いが一般に流布するというのは考えにくいとも思いました。ご批判になるべく対応したいはと思いますが、構造化定理に分割してしまうと主題がわからなくなってしまう感じになると思いますし、検討事項としたいなと考えます。
できれば申し訳ございませんがご容赦くださいませ。--I.hidekazu（会話） 2018年8月26日 (日) 14:15 (UTC) >>209
> 消したのが元も戻るっていうのは意味不明。
>（同じ内容で？）また書き込むだけでしょ？
意味解ってんじゃんｗ嘘つき
消すべきでないものを消しても反感買うだけだよ >>211
筋が通ってるな、論理的に完全に正しい判断だと思った >>208
いいのいいの、あの変なやつを召喚するのが目的だから。
こっそり書き換えて、気づかれるまで、変な記事を残す
指摘されても、気づかないふりして変な記事を撤回しない。
そうやっていつまでも変な記事が残るのが大問題
まず戻す。そして次はレビューが済んだもののみを
つけつければ良い >>212
> 消すべきでないものを消しても反感買うだけだよ
それは１人だけだから良い >>216
一人だけの根拠を君は示せないだろ
そうやって姑息な嘘を付き続けるのをやめなさい >>211
>「構造化プログラミング」という著書が既にあって内容も確認できる中、
>ちゃんと本で確認するプログラマーもいらっしゃるわけですし、
>そんな全くの間違いが一般に流布するというのは考えにくいとも思いました。
ちゃんと本で確認するプログラマーなんてほんの一部
英語圏のプログラマーでもダイクストラの本なんて読んでいない
日本だと「構造化プログラミング」はすでに絶版
こういう人はどうしたものか？ このスレを見ている5000万人の5chユーザが消したことに
対して憤ってるかも知れないでしょうが >>218
悪魔の証明の話？
俺にその手は通じないよｗ >>221
論理はわかるでしょ？
一人だって君は言ったけどそれにはなんの根拠もない
ことは明らかだから君は平気でその場しのぎの嘘をつく
クズ野郎だねってことを僕は証明したのさ >>223
可能性が存在するのはわかるでしょ？
一人であることは証明できないから
一人じゃない可能性が存在するって論理だよ 電卓オタクを擁護してるのは姑息な嘘を平気で付くクソ野郎なんですよみなさん
5000万人のみなさん >>225
知ってる知ってる
幽霊はいる派ってやつだよね
科学的だよね（笑いｗ >>222
問題ありだと思いますが？
実際に作業するプログラマーは学術的にプログラミングを捉えていないし、
ダイクストラの分かり難い話よりもIBMのミルズの簡単な構造化定理を選ぶでしょ。
>>211の人は現実を見れていない >>227
> それは１人だけだ
この発言はダメでしたね
一人であることを君が知れるわけがないじゃないですか
何人の人がここを見てるかもわからないのに
どうやって一人だと知ったのでしょうか
知ることができないことをさも知ってるかのように振る舞った
これは相手を騙す意志がないとできない状況なので君は嘘を付いた
君には明白な悪意を持って発言した
君の発言は説得力を失ったと言えます ﾓﾅﾀﾞｲｽｷは
ｿﾌﾄｳｪｱのｽﾀｯｸで
制御やevalを実行できるｲﾝﾀｰﾌﾟﾘﾀ（当然ｺﾚもｿﾌﾄｳｪｱ）の作りを
ｵﾌﾞｼﾞｪｸﾄ指向とかいってる
そしてｵﾚは翻訳しただけだから
ｵﾚは関係ないとかいってる
で、こんなﾔﾂがﾚﾋﾞｭｰがどうこうとかいってる
頭おかしいの？
こんな頭悪いのがﾚﾋﾞｭｰできんの？
なんでこんな頭悪いのが偉そうにしてんの？ 悪魔の証明とか幽霊とか
わけのわからないことを言って笑って
誤魔化そうとしてますが嘘がバレた以上
君が取るべき手段は謝罪だと思います ぷｗ オレはオレがしたいようにするよｗ
だから謝罪したいと思ったら、謝罪しますーｗ >>230
半角きもい
構造化プログラミングの話をしているなら構造化プログラミングの話で論破すれば？
他の話を持ち出すということは自分に自信がないってことでしょ？ 週も変わったことだし今週は Monadaisuki を重点的に査定して行く方向で 構造化定理と構造化ﾌﾟﾛｸﾞﾗﾐﾝｸﾞは
英語版同様きっちり分けて記述したほうががいい
ｵﾚが収束のために提案できることはｺﾚ以外ない >>238
それを拒否しているのが>>211に書いた人でして >>230
>>233さんの言う通りだと思います
RPLの話を持ち出しても構造化プログラミングの話とは無関係 プログラムに関する知識が皆無なんじゃないか疑惑だろ
構造化プログラミングと大いに関係ある
免許持ってない医者が腹かっさばいてたら殺人罪だろうが
事の重大さを考えろ ｷﾐﾗはな自省というもんがない
そこが問題なﾜｹ
自分たちがいかに無能でｺﾞﾐでｸｽﾞなのか
という自覚がないﾜｹ
だからいつまでたってもまともな人間になれないﾜｹ
わかる？
はやく人間になりなさい Monadaisuki に反発している人は、どうして Monadaisuki がノートに書いたことについて具体的に反論できないのだろうか？
構造化プログラミングと無関係のところを必死に叩いているだけ
>>242 と >>241 を読むだけで ID:wSgDz8cK と ID:zX+eejgv が荒らしだとよく分かる
ここを荒らしたいだけ このスレWikipedia観察日記じゃないからな
Wikipediaのこと書いてる時点で全員荒らしだろ
バカヤロウが >>246
論点ずらして逃げ出すんなら自由だぞｗ
＞Wikipediaのこと書いてる時点で全員荒らしだろ
＞バカヤロウが
なるほどWikipediaの記事関連で20件ほども１人で投稿してるお前が最悪のスレ荒らしということだな >>245
これが真実。
ID:wSgDz8cK と ID:zX+eejgv は具体的な反論ができないし、いつも論点をずらして逃げているだけ。
昨日の ID:IHxJX3F+ や ID:hANAm2gW と同一人物。
こんなことをして得をするのは誰なのか？
こいつらが I.hidekazu 本人だとすれば、理解できる。
>>174
>174 1 名前:デフォルトの名無しさん Mail: 投稿日:2018/08/26(日) 19:21:42.20 ID:IHxJX3F+
>あのな、5才児と東大の教授が違うことを言ってた場合
>東大の教授の方が正しいに決まってるだろ
>常識で考えろよ
これも I.hidekazu 本人が書いたと思うと納得できる。
5才児 = Monadaisuki
東大の教授 = I.hidekazu
ということだが、I.hidekazu が東大の教授と断言できる根拠が全然ない。
自画自賛と解釈すれば納得できるが。 >>245
>>247
全くその通り
>>249の言うことが正しいのかどうか不明だが、ここまで荒らすと言うことは何か目的があるんだろう
もっとも Monadaisuki に嫉妬しているだけという5ちゃんねるにありがちなことかもしれないが やば
ﾏｼﾞｷﾁが発作おこしてる
ｺﾚはﾎﾝﾓﾉさんがきてるわ。。。
分かりやすい。。。 >>261
ちなみにこいつは >>67 ではない
>>67 が電卓オタクだということに気づかず
擁護したただの痛いやつ >>263
論破されたのはお前だろ
その電卓オタクやらのどこが間違えているのか書いてみろ まだやっているのか？
結論は >>245 >>247 >>249 で出ている 一応言うておくと、２０２０年プログラミング教育はじまるやろ。
構造化プログラミングを知らない教師教えてるの怖いっていうと思うぜ。
本屋に構造化プログラミングの本は売ってないけど基本だとは知ってるだろう。
自分の子供に跳ね返ることをやるのはよくないと思うぜ。 >>267
それでも日本は強行するんだよね、、
つまり、基本的な事をないがしろにして教育進めると言う でもお前らろくに教育受けてない分際でよく頑張ってるじゃん
それを教育受けられるようにしたらもっと良くなるだろ >>267
そもそも教師ごときがプログラミングを教えるな！！！ っていうか、学校で教えるほどのプログラミングが
どれだけ使えるんだって話だな。
そしてそれと同様に、学校で教える算数（数学）も
理科も、役に立たんだろ？
内容のレベルには期待しないのがデフォやで？ >>272
そもそも学校って何のためにあるの？って気がするよね >>273
朝早く起きて学校に通学して、同級生とともに年上の人の話を休憩を挟みつつ
黙って聞くというところに慣れるためのところだと思う。すごい役に立つ。
そういう枠組みがあると社会に出たときに上司も統制しやすいからだろう。
騒ぐ奴には小学校出たのかって言っておけば抑え込めるし。
無意味に良い教育とか言い出してその枠組み壊しちゃうから統制できなくなる。
不良学生押さえ込むために体育教師が空手を真剣にやりだしたんで部活で空手を
うまく教えることができていました、というのが昔の実態だと思う。 潜在能力のある子ども達をもれなく発掘するために全員に知識を授けている
結果として上位何パーセントかのエリートに抜けなく教育を施せるならなんでもいいのだけど
無差別に教育して試験で選ぶより確実な方法がないのが現状なので学校がある
他の無才の子ども達は本当は教育は要らないんだけどエリート発掘のための必要経費と割り切る
遺伝子解析の精度が向上して最初から才能がわかるようになったら義務教育はなくなるだろうね
エリート以外の人達は知識がないほうがコントロールしやすいから逆に教育しないほうが搾取しやすくなる >>275
それは別に構わないのだけど、AIの理論で言う所の評価関数一つしか設定してなくない？
金融工学に、卵は一つのカゴに入れるなという格言あるし、各評価関数の相関性ばらけ
させたほうがよくない？これサブプライムローンと構造同じじゃない。 >>276
評価関数は複数ある
学科目や部活動のことね >>277
なるほど。ちゃんと考えているなら安心だ。 >>275
なるほど、船頭多くして船山に登るってやつだな >>275
なるほど、働きアリの法則ってやつだな
よく働いてる働きアリだけをあつめても、
なぜか2割はサボるようになるというやつ >>274
ほとんどのガキには機能していない
>>275の言うように大半のガキに教育は不要
>>277
それは無理なくね？
評価関数は受験だけだと思うのだが？ 学科目や部活動が評価関数になるなら
ビデオゲームの上手さも評価関数になって良いはずだ >>282
評価関数にできるだろうけど、多様な解釈を許す開かれになるので、
ただ一つの評価関数には落とし込めないと思う。ゲームにもよると思うが。 >>281
>評価関数は受験だけだと思うのだが？
ほんこれ つまり、受験の点数が高い人ほど
評価も高いという評価関数を作れば良いんだな ステータスオープンって叫んだら
評価値が表示されればいいのにね 値（数字）である必要はないな、自分なら比較可能なformを導入して
極小formみたいなものを安定解とするな。 >>285
日本の世の中はそれで回っているのが実情 >>280
なかなか考え深い理論だね
「働いたら負け」と考える自宅警備員はフリーライダーなのかな？それともサボってるだけなのかな？
そしてこの2-6-2の理論が構造化にも関係してるところがまた凄い
自宅警備員が構造化の大切な要素とは思ってもみなかった
(構造化プログラムとは無関係だろうけどさ) 構造化プログラミングでは
イベント駆動のハンドラが実装できない。 例えばC言語は構造化プログラミングだから
イベント駆動という概念が存在しない X windowsでも Windowsでも
普通にｲﾍﾞﾝﾄﾙｰﾌﾟもってる
そのｲﾍﾞﾝﾄを受け取ったときの処理を記述すれば
それはよく巷でいうところのｲﾍﾞﾝﾄﾊﾝﾄﾞﾗの一種になる
ちまたでは
そのそれぞれのｲﾍﾞﾝﾄの処理関数をｲﾍﾞﾝﾄﾊﾝﾄﾞﾗと呼称してることが多い
で、それとほんの少し別の話で
ｼｸﾞﾅﾙになると通常割込ﾍﾞｸﾀの制御はOSで隠ぺい化されてる
ｼｸﾞﾅﾙが発生したときの動作を記述した処理を
ﾕｰｻﾞｰがﾚｼﾞｽﾄしておけばその処理をOSが呼びだすようになってる
当然、ｺﾚもｲﾍﾞﾝﾄﾊﾝﾄﾞﾗの一種といえる FORTRAN 66でイベントハンドラ書いたことあるよ
コンパイラオプションでなんか指定してたと思う
汎用機に繋げたジョイスティックによるUI処理で
だからCだって、出来るんじゃないの？ >>296
Cの場合、関数のポインタをイベントハンドラとして登録するような仕組みにすればできる オブジェクト指向は機能をオブジェクト同士の関係性でしか
記述できないからわかりにくいんだよな
構造化プログラムは機能が独立してるから分かりやすいんだよな >>298
オブジェクト指向と構造化プログラミングは相反するものなのかねえ？
構造化プログラミングにもクラスの概念に似たものはあるはずだが >>299
構造化プログラミングにもクラスの概念に似たものはあるはずだが
これが構造化プログラミングが廃れた原因だろ
これ使うならオブジェクト指向で記述したほうがいい
オブジェクト指向はわかりにくいとかいたが、世の中には
「わかりにくく」表現するしかないものある >>300
抽象化データ構造+その上で動作する抽象化文がオブジェクトやクラスに相当するのだが、ダイクストラ氏はもっと大きな単位で考えていたみたい。
しかし、オブジェクト指向言語のオブジェクトはかなり細かい単位になってしまった。 機能ってのはほんらいモノではコトなわけだ
それを無理やり関数って形でモノにするのが構造化プログラム
だからまくいった構造化プログラムは断然わかりやすい
まあ構造化プログラムは頭いいやつにしかできない
凡人はオブジェクトが一番だよ 学校がフィルタリングの機能程度くらいしか果たしていないから
もう少し技能を見に付け入られる場にする必要が有る
小学生からやる必要は無いと思うけど
中学生くらいからどういう職業に就くか?
という視点で組みなおした方が良い ちょっと煽られたことがあるからって排除したらダメだって。
哲学者がやっと生業を得られたもんで、今までの業界に対する
不遇を怨念のようにぶつけているだけじゃないか？
構造化がどうだのオブジェクトがどうだのということではなくて、
僕らは歴史的に言えば哲学者に相当する人種です、と区分けしたい
だけでしょ。 こんなページを見つけた。
翻訳：構造化プログラミングを最初に提唱した文書
http://calculator-cafe.com/readings/Structured_programming/Structured_programming.html
この最初の文章と書籍 "Structured programming"（1972年）とは違いがあるのかな？
同じ考え？ 構造化プログラミングとオブジェクト指向って、
どっちか一方だけを残すようなもんじゃないだろ。 >>308
第２章を書いたホーアが誰からアドバイスを受けたか。
たぶんホーア経由でダイクストラは何を聞いたか。 興味深いなぁ
元々プログラミング専門でやってきてなくて転向してきたから
理屈は分かってるつもりだが本質を問われると自信ないんだよなー >>312
大丈夫だ。日本のプログラマーのほとんどはプログラミングの本質なんて理解していない。 つーか、プログラミングの本質ってなんだ？
それをダイクストラが作ろうとしたけど、ミルズに妨害されてうやむやになったのでは？ アルゴリズム+データ構造=プログラミングって本があったろ。
まさにタイトルが真実ついてるなと。
検索とか出来る様になってもテキストファイルや、WinAPIが標準でサポートするbmpファイルは弄れても、世の中で求められてるのはjpegや各種カメラのRAWファイルの編集。
データ構造が分からないと触れもしない。
解析とか勉強しないとかね。 >>317
>アルゴリズム+データ構造=プログラミングって本があったろ。
>まさにタイトルが真実ついてるなと。
それってクラスのことじゃね？
結局、オブジェクト指向で全部いいやってなってしまった アセンブラだってアルゴリズムとデータ構造じゃん
それをどう扱いやすくするかが問題なわけで >>318
言われてみればそうなんだけど、実際にはクラスは型の側面が強くて、クラス作ったら手続き(アルゴリズム)を内包するデータ構造になってしまった。 STLが最初に登場した時はデータ構造から切り離されたアルゴリズムに対してOOPな方々からフルボッコだったらしいよ
最終的には勝利したのは歴史が示すとおり 何を持って勝利なのかわからんが、
STLに相当するものが他の言語にないのはなぜか？
その答えはわかっていて、C++のオブジェクト指向は貧弱だったんだよ。
機能も貧弱だし、なにより標準のオブジェクト指向ライブラリが存在しなかった。
あとC++にGCがないから仕方なくSTLを使ってるっていうのがもう一つの大きな理由だな GCデフォだと困る場面もある
仮想マシン使うならGCデフォでも良いがそーじゃないでしょ >>323
それが本当の理由。構造化がとかアルゴリズムがうんたらじゃなくて
GCでは困る場合に対応しようとしたためにSTLが必要になった pythonはSTL相当の機能を備えてると言える？ >>322
いわゆる instantiate なる語が C++ 界隈以外ではほとんど聞かれない、のと同値なのではないでしょうか？ instantiateでぐぐったらUnityしかでてこんのだがｗ >>325
STLが不要と言える機能は搭載してますね。
1. GCを備えてるから、STLのなんたら_ptrが不要
2. コンテナデータ型を備えてるから、STLのコンテナ型およびイテレータが不要 STLの肝かつ叩かれた部分はアルゴリズムをコンテナのメソッドにせずに外出ししているところで
コンテナ部分が言語組込みかライブラリ実装かはどうでもいい
pythonに関して言えば(今は違うが)変数に型が付かないので特に意識しなくても
関数を異なる型に使いまわせるのだから同じようなもんだ これ読むとなんらオブジェクト指向と相反しないなw
というか現在に至るプログラミングの基礎を提唱しただけに見えるわ >>333
よーしよしよしよしよし( ＾∀＾)ノシ >>331
分かりやすくなったと言うよりは以前の記事の構成が悪すぎて歴史のところ以外は意味不明だった。
しかも I.hidekazu とか言う構造化定理と構造化プログラミングの区別のできないアホがさらに酷くなりそうになったところをここの住民が元に戻した。 >>335
正 区別のできないアホがさらに酷くしてしまった
誤 区別のできないアホがさらに酷くなりそうになった >>332
オブジェクト指向と相反はしないけど一緒でもないんだよね。 そりゃ構造化プログラミングに足りないものを
補ったのがオブジェクト指向なんだから当然だろう >>338
Simulaがまさにそんな感じ
ALGOL+Classだったからなあ 値だけで論理演算する機能ってほしいと思ってるんだけどなかなかないのかな
例えば
if(value == (1 || 2 || 3) )
だったらvalueが1~3のあいだならtureになるとか。
if(value == (1 || '1' || true) )
みたいに型を飛び越えられたらなお便利。
OR演算が書きやすくなるな。 UnkoValues.contains(value) >>340
値だけで論理演算してないじゃん
それ、論理演算子 == とか || に
そういう意味をもたせてるだけでしょ？ value in [1, 2, 3] のように書ける言語はたくさんある
こういうのは論理演算じゃなく集合演算
値の論理演算のニュアンスに近いのはJavaScriptの x = y || -1 みたいな式 >>331
やっとまともな記事になった。
構造化プログラミングは構造化定理と別物なんだよ。 >>343
inみたいな演算子が無くても関数はあるよな 構造化プログラミングって
１９８０年頃はやはったなー ダイキストラも懐かしいー
95年頃に銀行で顧客サービスの最短パスもとめるのに
つかったわ〜 >>349
たいてい構造化定理のことを指しているけどな >>340
true|falseを返す関数とか作れば良いんじゃね 関数で切り出すとか構造体にまとめるとか当たり前のことをやらん馬鹿があまりに多すぎる。 もうやめようぜ。
これだけじゃエスパーじゃないとわからんか もう気が済んだんじゃないか？
こういう世界になって本当に満足なのか？
理由まだ残っているのか？
俺はなんとか頑張ったぜ 上で荒らし行為を行っていた I.hidekazu が降臨！
https://ja.wikipedia.org/wiki/%E5%88%A9%E7%94%A8%E8%80%85%E2%80%90%E4%BC%9A%E8%A9%B1:Monadaisuki#%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%E3%81%AE%E8%A8%98%E4%BA%8B%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6
＞あれは私がコツコツと毎週末に図書館に通ったりして見つけた文献やネット古書店で集めた古書、
＞国立国会図書館で複写した文献など（総額費用数十万円）を自分の余暇や日中の仕事時間の合間
＞に考えに考えてまとめた内容を、インターネットに接続できる人なら誰でも閲覧できるネット百科
＞事典のWikipediaの記事として無料で図まで含めて作成した記事だったんです。
こいつアホすぎるわ。
構造化定理と構造化プログラミングの区別もできないくせに数十万円使って調査ってバカ丸出し。
金かけても内容がクソなら意味ないだろうに。 >>357
その人、かなりおかしいというかキティなのかねえ？
ここを読んでいたら目眩がしてくるよ
Wikipedia:管理者への立候補/i.hidekazu/20141215
https://ja.wikipedia.org/wiki/Wikipedia:%E7%AE%A1%E7%90%86%E8%80%85%E3%81%B8%E3%81%AE%E7%AB%8B%E5%80%99%E8%A3%9C/i.hidekazu/20141215
＞結果
＞賛成 2 票、反対 13 票、無効票なし。ガイドラインに基づき、今回は見送りとなります。
こんな人が管理者になったらやばすぎる なんだと！本人降臨だぞ！
○ビー・エムか○ロックスか知らないけど操作しすぎなんだよ！
アラン・ケイのオブジェクト指向なんてマイケル・ジャクソンの
JSD法のパクりじゃねえか。
商業戦略上業界あげて黙ってたから混乱してるんじゃねえか‼ 憶測混じりでもうこの際だ言ってやる
JSD法の分析パートの用語「実体」を「オブジェクト」に置き換えたのがいわゆるオブジェクト指向の哲学
実装パートの言語をsmalltalkとかにしてマルチスレッドなGUI開発させるためのバズワードが
オブジェクト指向プログラミング JSDっていつ考案された？
ジャクソンシステム開発で検索してもあまり良い情報が出てこないんだよね すまん。システム開発の出版は1983年で年代的に後だったわ。 Simula の登場が1967年
Smalltalk の登場が1980年 >>363
> Smalltalk の登場が1980年
“登場”をどうとるかによるけど
Smalltalk（というかメッセージングのオブジェクト指向のコンセプト）自体は
Smalltalk-72の時点、つまり1972年にはもう実証されていて
コンセプトも同年のダイナブック構想の論文で言及済みということはある パルアルトでは70年代初頭から開発されてきたと言われるがほとんど秘密で
1981年8月号のBYTE誌の特集として突如大公開された。
いまから見直してみるとmachOSのディストリビューションの開発者の
ゲイツ氏とジョブズ氏にGUIシステムとそのプログラミング手法として
オブジェクト指向プログラミングを公開する必要があったから
なのかもしれない。
クラウドもそうだがパルアルトは未だに生きていると考えるべきだと思う ネットワークプログラミングを含めオブジェクト指向は成功を納めたが
時代はハードウェア制御と機械学習に進んでいるし、人間から十分な
学習データを取得してしまえばそれもやることなくなる >>366
なんだか、その辺から拾ってきたバズワード並べただけで、
意味が見出せないんだが >>369
> ウィキペディアの構造化定理のページに基地外来襲！！！
> 「構造化定理」を「構造化プログラム原則」という訳のわからない言葉に変えようとしている。
誰かウィキペディアを書ける人は、このGoldensundown2の提案に反対しているのに対する反論としての
＞・・・。「Structure theorem」＝構造化定理は数学分野のものと重複してる紛らわしい言葉という点も御考慮ください。--Goldensundown2（会話） 2019年9月9日 (月) 13:56 (UTC)
に対して、
「Structure theorem」は数学の定理と同じ意味（幾つかの公理から演繹的に証明される命題）としての定理だから、「構造化定理」と呼ぶのが適切で
「原理」という言葉を使うのは不適切どころか完全な間違い
と反論を書いて下さると嬉しい 今に始まったことじゃないけど日本のwikipediaってクソばかりだな。
Windowsとかアンチが多そうな記事は悪意が感じられる >>372
構造化定理の記事は比較的ちゃんと書かれているのでは？
しかし、>>369のようにおかしな人が来て悪化させてしまうこともある ちゃんとファイル分割して関数切り分けして構造体切り出すだけで
ほとんどのプログラムはまっとうになる。
問題はそれをできてないバカが圧倒的に多いだけ。 出来る人が少ないと仕事がこなせない
だからわざわざ構造化プログラムだとか言って教える必要が有るんでしょ
ただ罵詈雑言を言う事の方こそにこそ意味がない
自分が凄いって自慢したいだけ >>376
関数切り出しだとか当たり前のこともできずに
無駄に動的なポリモルフィズム入れたり
そんな輩にまともな話は通じないんだよ。
自慢じゃなくて普通のことを普通にやれというだけの話。
糞機能よりも大事なことは山ほどあるってのに。 ぶっ（笑）
構造化プログラミングなんて1985年頃から雑誌で話題だったわ（笑） >>378
> 構造化プログラミングなんて1985年頃から雑誌で話題だったわ（笑）
1985年頃って、お前、10年近く遅れてるぞ（爆笑） >>378
しかし、構造化プログラミングを理解していないプログラマーは多いぞ ＞構造化プログラミングはまだ必要ではないのか？
まだそんなこといってんのかｗ
その昔グリースの「プログラミングの科学」を読んだ自分
プログラム検証の時代はまだ来ないのか？！ ジャクソンの構造化プログラミングというものもあるがそっちのほうが重要じゃね? >>383
データ構造がうまくできていれば、制御は必ず書けるからねえ お前らが追い出したせいで圏論に戻ってきやがった
受取拒否させろ 関数は無数(無限)に存在する。
よって、どんなにクラスやメソッドを増やそうとも必ず新たにクラスやメソッドを作る必要性が出て来る。
手続きは無くならない。
手続き型言語をある程度宣言的に扱うのにオブジェクト指向プログラミングは有効だが、一定以上の抽象化は出来ない。
だからこそ、関数を作る際も宣言的に書ける関数型言語に鞍替えした。
趣味グラマーだから出来るんだが。 スレ立てちまったけど、こっちに書き込めばよかったか？
ミルズの構造化プログラミングって正しいんですか？
https://mevius.5ch.net/test/read.cgi/tech/1647521816/
> 67 名前：デフォルトの名無しさん[] 投稿日：2018/08/25(土) 13:33:32.69 ID:8WZtp+ee [1/7]
> 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
>
> こいつは構造化定理と構造化プログラミングの区別ができているのか？
もしかして I.hidekazu と鳥海秀一って同一人物？
jus共催 第58回花粉シェル芸勉強会
https://event-search.info/event/e8cbb0ae7ee1adf336fa87f42b77c4bb/
午前の部: 勉強会
今回は「間違いだらけの構造化プログラミング(その2)」というお題で鳥海秀一さんが話をします。
ユニケージとかシェル芸で悪名高いUSP周りの人間で驚愕してるんだが ただのこじつけだと思うがこんなのを見つけた
https://twitter.com/hdkz/with_replies
> I Hidekazu
> @hdkz
> 石川県金沢市
> 2010年4月からTwitterを利用しています
I Hidekazu のIは石川県金沢市のI
金沢大学ではUSPがユニケージを大学で教えてる
https://twitter.com/5chan_nel (5ch newer account) YouTubeで動画公開してる。見てないけど、めちゃくちゃな
理論を広めてなければいいんだが誰か検証してくれない？
https://www.youtube.com/channel/UCt5Alt1QuKhe2_e5n4gKazA 文字列のフォーマットなんかはまともなライブラリが無いと関数に切り出してもそのまま書いてもゲロ吐きそうなコードになるよな >>393
それは違う人だぞ
https://jp.quora.com/profile/IWAKI-Hidekazu/questions
こっちがi.hidekazu
それはいいとして、ブロック依頼:i.hidekazuを立てたのでこのスレの被害者の人にも見て欲しい >>398
動画見たが自分ぬ意見は言うが根拠の話はしない
動画の品質が最低、動画関連の勉強してから上げてね >>399
動画は見てないけど多分別人だからwikipediaの方を助けて欲しいん リッチー大佐といいシェルショッカーとユニケージといい
あいつら自分の意見は言うが根拠の話は全くしないんだよな
調べてみるとほぼすべて間違い。呆れてしまう。
リッチー大佐とかユニケージがのデータベースを使わない理由
> 10.1.2 RDBMS は、データ管理術を知らないプログラマーのための発明品
> 始めに断っておくがここで述べる話は人づてに聞いた話である。
> 秘密結社シェルショッカー米国支部が米国内の大学で耳にした情報によれば、「リレーショナルデータベース
> というのは、データ管理術を知らないプログラマーのための道具に過ぎない」ときっぱり言い切る者たちがいた
> らしい。その者たちの言い分はだいたいこんな感じだったという
「秘密結社シェルショッカー米国支部が米国内の大学で耳にした情報」 
