TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
●●●●TCL/TKなら俺に聞け 4●●●●
VBSで便利なプログラムを作れスレ
大唐吐蕃回廊漢宮秋月康秀華南京都大白微宮廷記
つまりRubyってPerlの後続じゃん？
Google Maps API 質問箱
Rust Part5
Ruby 初心者スレッド Part 63
【Delphi互換!?】FreePascal/Lazarus その2【GPL】
Julia Juno Jupyter part1
【QBASIC互換!?】FreeBasic【GPL】 2
構造化プログラミングはまだ必要ではないのか？
- 1 ：2018/08/15 〜 最終レス ：2020/04/26
- 構造化プログラミングで言うところの「抽象化データ構造とその操作の抽象文の共同詳細化」はオブジェクト指向のクラスで実現された。
しかし、オブジェクト指向だけでは、階層化と段階的詳細化と段階的抽象化が実現できない。
まだ構造化プログラミングは必要なのではないのか？
しかし、今は風化しているように思えて仕方がないし、ダイクストラの考えを知っていれば、もっとマシなコードが書けそうだが。
（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 ：
- コード書くときに「これはオブジェクト指向、あっちは構造化プログラム」っていちいち意識するかバカ者
- 3 ：
- >>2
とはいえオブジェクト指向だけで説明できないことも多い。
クラスにすれば全て解決ではない。
構造化プログラミングを意識しないと無駄なクラスをたくさん作ることになる。
- 4 ：
- >>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”運動は一層の盛り上がりを見せたというわけ
- 5 ：
- >>1
Wikipediaより
>1987年の第9回ソフトウェア工学国際会議(ICSE)において、Millsは会場にチューリング賞受賞者がいないことを確かめると
>「ダイクストラやホーア達はどこへ行ってしまったのか。我々はもう彼らから学ぶものがないのか。」とその現状を批判した
>（しかし木村泉の見解が当たっていたとするならば、「ソフトウェア工学」をそういったものにしていった張本人こそが、その発言をしたMillsであるということになる）。
酷いよなあ
ダイクストラの研究を粉砕した張本人がよくこんなことを言えるわ
- 6 ：
- （きちんとクラスが整理された上での）OOPこそ構造化プログラミングの結実したものと思っていたんだが違うのか
- 7 ：
- 構造化とオブジェクトは別物だと思っていたが
- 8 ：
- 今はオブジェクト指向さえできれば十分という風潮がある。
しかし、オブジェクト指向は主にクラスを使うというだけであって、
綺麗で分かりやすいプログラムを書けるかどうかとは別問題。
構造化プログラミングは綺麗で分かりやすいプログラムを書く手法としては今でも大事かと。
- 9 ：
- >>8
>オブジェクト指向は主にクラスを使うというだけであって
そりゃいくら何でも偏見
- 10 ：
- COBOL、VB、Java…と時代が流れても馬鹿は馬鹿なコードを書く。
- 11 ：
- >>1
選択するようなもんじゃないじゃん・・・
何で片っぽだけで存在出来ると思ってんの？
- 12 ：
- >>11
自分は片方だけとは書いていないが？
- 13 ：
- >>1 がクソコードしか書けないのは分かったからいちいちスレ立てんな。
- 14 ：
- >>13
いや、ｽﾚ建ての言い分は稚拙かもしれないが、
型クラスベース+継承でソフトウエアを表現すると
依存の茂みを作ってスパゲティーの山になる欠点に薄々気がついて
王様の耳はロバの耳と、あえて言っているのかもしれない…
- 15 ：
- >>14
オブジェクト指向で却ってややこしくなった面もあるかもね
- 16 ：
- オブジェクト指向技術はエディタの機能で代替できるような気がする。
エディタにはコードの検索や置換機能があるし、
VimやSublime,サクラエディタで高速に既存コードを再利用できる。
だからエディタの機能やVimを極めれば継承とかほぼ要らないし、
再利用性重視でなくてもいい。
変更の影響範囲とかもエディタを使って洗い出せば、管理できる。
だからオブジェクト指向の高度な機能を使わなくてもエディタや
ツールで代替えできる。
コードの差分はGitやWinMergeで洗い出せる。
オブジェクト指向のガチガチの設計を書くととにかく
変数名、メソッド名などの名前が長くなる。
名前が横に長いと非常に読みにくく画面外に隠れるし、
名前というのはスペース区切りもカンマ区切りもないわけだから、
上記のエディタ機能で編集がやりにくい。
だからJavaみたいなガチガチのオブジェクト指向ってもう今の時代
必要ないんだと思う。JavaScriptやPythonくらいのオブジェクト指向
だけで十分だもの。
Javaの作法の時代遅れ感とか、馬鹿馬鹿しさってそろそろ気付くべき。
- 17 ：
- >>12
>>1
>まだ構造化プログラミングは必要なのではないのか？
条件が整えば不要になると自分で書いてるじゃん。
- 18 ：
- >>15
2010年のインタビューでは、オブジェクト指向の御大は「実現方法に欠点があった」と考えてるようだ。
オブジェクト指向プログラミングは間違いだったか?
https://www.infoq.com/jp/news/2010/07/objects-smalltalk-erlang
>このインタビューを受けたのは、Erlangの最初の開発者であるJoe Armstrong博士とSmalltalk、OOP、パターンに長い間関係している
>Ralph Johnson博士だ。私たちは「間違った道」を当てもなくさまよって
>きたが、これはオブジェクトの考え方の実現方法に欠点があったため
>であり、この考え方自体の欠点ではないと2人は述べた。
- 19 ：
- >>18
これってクラスが良くないってこと？
Erlangの仮想マシンのプロセスみたいなものが良いってこと？
- 20 ：
- 元祖オブジェクト志向は俺らのモノだってだけの主張
- 21 ：
- そもそもオブジェクト指向は、データとアルゴリズムをクラスとして組み合わせただけのこと。
構造化プログラミングみたいに綺麗なコードを書くためのものではない。
- 22 ：
- >>21
なるほど、構造化プログラミングは設計手順でもあるのかー
オブジェクト指向だとドメイン駆動とかユースケース駆動なんかが
それにあたるのかね
Wikipediaの構造化プログラミングには↓こう書いてあって
> プログラムを記述するのではなく、機能を抽象化した「仮想機械」を想定し、その「仮想機械が提供する命令群」でプログラムを構成する
これってオブジェクトの設計にも当てはまるよね
オブジェクトは構造化の手段の一つとみることもできそう
- 23 ：
- >>22
つーか、ダイクストラが抽象化データ構造という概念を提案していて、
それがオブジェクト指向のクラスに似た考えだった。
- 24 ：
- >>22
> > プログラムを記述するのではなく、機能を抽象化した「仮想機械」を想定し、その「仮想機械が提供する命令群」でプログラムを構成する
>
> これってオブジェクトの設計にも当てはまるよね
> オブジェクトは構造化の手段の一つとみることもできそう
ところがSimula 67の頃はともかく、Smalltalk-80以降のオブジェクト指向の人々は暴走して上の構造化プログラミングでの抽象機械という思考上の粒度とは
およそ対応しないほど細かい粒度のオブジェクトをどんどん使い始めた、例えば「１つの数だって立派なオブジェクトだ！」といった形でね
オブジェクト指向がそのように暴走しだした時＝オブジェクト原理主義が始まったから、オブジェクト指向を熱心に使う人々の大半は構造化プログラミングとは無関係になり、
オブジェクト指向で作られたプログラムはDijkstraが考えていたようなプログラムの正しさを論じやすいようにしっかりとした構造を持つものではなく、
まるで簡単に取り外しできて自由に回転できる自由継手ばかりで組み上げられたようなクネクネとして「形」というものが良く見えない代物になった
確かに細かいオブジェクトを自由に組み合わせて作れば部品の追加や削除は容易になるが、プログラムの正しさを論じるには余りにも自由度が高すぎて見通しが悪すぎる
- 25 ：
- >>24
>ところがSimula 67の頃はともかく、Smalltalk-80以降のオブジェクト指向の人々は暴走して上の構造化プログラミングでの抽象機械という思考上の粒度とは
>およそ対応しないほど細かい粒度のオブジェクトをどんどん使い始めた、例えば「１つの数だって立派なオブジェクトだ！」といった形でね
確かにオブジェクト指向はそんなものだと漠然と思っていたけど
何でもオブジェクトにすればいいってものではないよなあ。
結局、オブジェクト指向の導入によってプログラムは難解になっただけだった。
柔軟性は上がったけど可読性は低下した。
- 26 ：
- わかりみが深い
- 27 ：
- >>25
暴走というより、プログラミングの可能性追究の過程だからね。
「可読性という産業的な面の利便性」とは別の、今で言えば自動プログラミングの方向だし。
- 28 ：
- >>26
わかりみが深いの意味と使い方とは？きもい言葉だけど元ネタはまさかの漱石？
https://kotoyumin.com/wakarimi-mean-3531
- 29 ：
- Smalltalk で何でもオブジェクトになるのは文法と実装からほぼ必然なので許してやれ
- 30 ：
- >>29
Smalltalkはオブジェクト指向を突き詰めたらどうなるのかを実現した言語だし
- 31 ：
- >>28
「わかりみ」は文法違反の単なる誤用で日本語の意味のある単語としては認められない
＞本文中の他の「?み」の例、つまり「ありがたみ」や「悲しみ」それに漱石が使った「淋しみ」は
＞どれも形容詞「ありがたい」・「悲しい」・「淋しい」の語幹に「み」を付けて名詞化した言葉であるが「わかりみ」は違う
上に加えると
「わかりみ」の語根「わかり」は動詞「わかる」の連用形なので形容詞のように体言にかかり修飾することすらできない単語で
それに「〜み」を付けた形を日本語の言葉として使うのは単なる無知を曝け出しているだけのこと
- 32 ：
- Smalltalkなんて死んだ言語を語ってもなー
- 33 ：
- >>1
ダイクストラの提唱した検証を前提としたプログラミングが必要か？という
疑問であれば、これから必要だし今後はさらに重要になると断言できる
実際、24時間365日 正しく動作するバグ0の品質要求が当たり前な
組み込み開発の一部では、必須の技術要素になりつつある
ただし、ソフトウェア検証への対比としてオブジェクト指向を挙げる事に違和感がある
ソフトウェア検証とオブジェクト志向は互いに交差する概念であって対立はしない
実際、たとえば VDMにオブジェクト指向を導入したVDM++が登場しているし、
Alloy は最初からオブジェクト指向の概念を前提として設計されている
- 34 ：
- >>31
言語学上はある表現が間違ってる云々といった議論は意味を持たない
例えば、あらゆる方言は標準語から見れば「誤り」だがそのような主張をする人はいない
一定の範囲で通用しているならそれは「正しい」言葉なのだ
- 35 ：
- >>33
>実際、24時間365日 正しく動作するバグ0の品質要求が当たり前な
>組み込み開発の一部では、必須の技術要素になりつつある
具体的にどうやっているんだ？
- 36 ：
- >>35
開発したいシステムの外部仕様をVDMやAlloyといった形式的仕様記述言語で
記述し、それをツールを使って検証、詳細化という手法で実装言語に変換
詳細に関しては「組込み 形式手法」や「組込み 仕様記述」でググると、
大量の入門やら事例やらを扱う文書が見つかる
個人的にお勧めの教科書(入門書)は以下の２冊：
・形式手法入門
https://www.amazon.co.jp/dp/4274211886/
・組み込みソフトへの数理的アプローチ
https://www.amazon.co.jp/dp/4789838080/
このム板にも専用スレがある（過疎ってるけど
・【Alloy】形式言語による仕様記述【VDM】
http://mevius.2ch.sc/test/read.cgi/tech/1357387746/
- 37 ：
- >>36
ありがとう。今の組込はそんなことをやっているんだなあ。
- 38 ：
- >>32
> Smalltalkなんて死んだ言語
Smalltalkは現役バリバリの言語処理系だが？→http://pharo.org/
そんなことも知らんとかアンテナ低すぎだぞ！wwwwww
- 39 ：
- >>38
アンテナ強すぎてノイズ拾ってるんちゃうんか？
- 40 ：
- >>39
アンテナ「強」すぎとかググり力以前に日本語wwww
- 41 ：
- セックスが強いとも言うし
匂いが強いとも言うのよ
強いって言葉は何にでも使っていいの万能なの
- 42 ：
- ググり力ってなんすか？www日本語エントロピーが拡散してますよ
- 43 ：
- エントロピーは「増大」するんだがな
- 44 ：
- try - catch の大域脱出は構造化プログラミングに入るの？
許されてるのかどうかが知りたい
- 45 ：
- 例外処理やついでに継続なんかは本質的にGOTOだからもちろんダメだろ
- 46 ：
- >>44
大域脱出は良いことだったのだろうか？
- 47 ：
- 構造化は今でも必要だと思うよ
初期の(今でも?)プログラミングで作られた物が大変だったのは
何もかもが広域だったから
構造化にしてもオブジェクト指向にしても
アクセス範囲を狭小化したのが一番効果が大きい
余りにも何処からでもアクセスされてるとそのアクセスパターンが発散してしまって
組み合わせ数が多くなりすぎて事前予測不可能になる(テストしきれない)
オブジェクト指向プログラミングは粒度が最小化可能な物で
それによってアクセスパターンを最小化してバグを発生させ難く出来る
この部分に一番効用が有る
人間の認識限界
これを理解しているかどうかが鍵となる
エドガーダイクストラが言った一番の要点はアクセス範囲の極小化する為に構造化を提唱した
だからcobolみたいにdataなんちゃらーとプロセデュアなんちゃらーみたいに
処理とアクセスする物が分離されている物が一番問題があると指摘した
basicは変数が広域なので問題が有ると指摘した
クラス型オブジェクト指向プログラミングシステムでは
クラス内に変数とその処理をパッケージングしてアクセス範囲を完全に限定した
だからpropery get/set みたいな内部変数を直接外部から操作するような書き方や
それしか出来ないような言語は問題が有るし
問題有りだと騒がれる
- 48 ：
- >>44
try - catch は乱暴な仕組みだよなあ。
下の階層の例外を漏らさず捕獲する。
言い換えると下の階層を信用していない仕組み。
この仕組みのせいでますます適当にプログラミングできるようになったかもしれない。
- 49 ：
- むしろ逆だろ
適当なプログラミングするやつをカバーするために例外機構ができた
- 50 ：
- >>49
現実に合わせるとそうなるのかねえ
構造化プログラミングは理想に過ぎないのか
- 51 ：
- 規模が小さければ構造化でしょ
- 52 ：
- トライキャッチは構造化例外処理と呼ばれるけどね
- 53 ：
- 入れ子にできるし
扱うフローが正常か異常かの違いかのお
- 54 ：
- >>52
見た目的には構造化されているけど、大域脱出はある意味gotoに近いものがあるかと
- 55 ：
- >>54
正常フローを抜けるんだからしょうがない
- 56 ：
- フローが違うんですよ
- 57 ：
- >>54
> 見た目的には構造化されているけど、大域脱出はある意味gotoに近いものがあるかと
脱出でのgotoは検証のしやすさを乱さないからDijkstra本来の構造化プログラミングの精神には反しない（というのを昔、誰かが書いてたように思うが詳しいことは覚えてない）
問題は例えば制御構造（複合文）の内部のラベルに向かって構造の外側からgoto文等のジャンプによって制御を移す（飛び込む）ケース、確かCとかでは許されたのでは
これを許すと検証が非常に面倒になるので構造化プログラミングとしては許し難い暴挙
- 58 ：
- とはいえ、関数ポインタ(継承含む)があると例外は検証できなくなるし
検証しようとシグネチャに例外の種類を明記させると大変面倒なことになるしなー
Swiftや、C++の新規格みたいに最近は例外を投げるか投げないかだけを明記するのが流行りっぽい
- 59 ：
- ゴジゴシリン
ヘルスハンバーグ
- 60 ：
- >>58
> とはいえ、関数ポインタ(継承含む)があると例外は検証できなくなるし
関数ポインタが許される言語の検証は例外処理の検証以上に厄介だよ
現実問題として関数ポインタや手続き（関数）の引数・結果値としての手続き（関数）を許す言語の検証は
非常に労力を要することなるので実用的ではないと思うが
- 61 ：
- 複数返り値さえあれば例外なんてほとんど必要ないのに
- 62 ：
- コアダンプ万歳
- 63 ：
- ブルスクマンセー！
- 64 ：
- やっぱこれだろ→💣
- 65 ：
- >>61
確かに例外を使い過ぎている感があるよね
- 66 ：
- >>構造化プログラミング
今でもCOBOLとPL/1では生きてるぞ
- 67 ：
- 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
こいつは構造化定理と構造化プログラミングの区別ができているのか？
- 68 ：
- >>67
酷いなそれw
フローチャートの書き方と完全に誤解していないか？
- 69 ：
- これはひどい
- 70 ：
- >>67
> Wikipedia の構造化プログラミングが I.hidekazu という奴のせいで酷い内容になっている。
・・・
> こいつは構造化定理と構造化プログラミングの区別ができているのか？
>>68
> 酷いなそれw
> フローチャートの書き方と完全に誤解していないか？
というか、このI.hidekazuって奴はDijkstraとMillsとは同一人物だとでも思ってるみたいね（苦笑）
- 71 ：
- でも前からこの記事編集してるみたいだぞ
- 72 ：
- >>70
何をネタ元にしたらこんな記事が書けるのか？
- 73 ：
- >>67
ノートで抗議している人がいるけど聞く耳持つのかねえ？
- 74 ：
- 加筆前と大して変わってないぞ
図が入って連接・選択・繰り返しがわかりやすくなったくらいだろ
お前らろくに読んでないんじゃないか？
- 75 ：
- >>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
- 76 ：
- >>75
正しさの検証手法が詳しくなったよね
それ以外はまったく同じ
全部読んだ
- 77 ：
- お前らろくに読みもせずにこのスレのバイアスだけで文句言ってるだろ
池沼どもが
- 78 ：
- >>76
>>77
お前、I.hidekazu本人だろ？とっととRよwww
- 79 ：
- >>78
違うわ、お前がRよ
- 80 ：
- >>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に言わせると、構造化プログラミングを構造化定理と取り違えても誤解というほどの間違いではないということらしい。
明らかに構造化プログラミングと構造化定理の区別ができていない！
- 81 ：
- >>80
不十分な理解ということだろ
言ってること間違ってないじゃん
＞単純にgoto文を使用しないgoto-lessプログラミングと理解されていることが多い[4][5]。
この文削除でもいいくらい
誤解という言葉はそれってあなたのただの感想ですよねってことになる
感想文書くところじゃないから理解に修正したんだろ
削除してもいいくらいのクソ情報だよ
- 82 ：
- 事実と感想を分けれてない
- 83 ：
- >>81
お前、I.hidekazu本人じゃないの？ノートに似たようなことを書いているよな。
＞加えて、goto文の論争についてはバッサリ削除してしまっていいと思います。--I.hidekazu（会話） 2012年11月23日 (金)
それと、goto文の話以外は反論できないのか？まあ、できないだろうな。
- 84 ：
- >>82
それができていないのはあんただろ。
「誤解」が事実であって、「誤解という強い表現を使うほどではない」は完全に感想。
- 85 ：
- >>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は完全に理解ができていない。
- 86 ：
- >>83
違うよ、俺は完全に中立な第三者、その俺から見ても
修正前のものは感情的すぎるというか気持ち悪い
執筆者の感情と客観的な事実が混ざってどす黒い色になってる
こんなの書いてるから日本のWikipediaはバカにされるんだよ
>>84
誤解は事実ではないんですよ、みんなは誤解してるんだという思いなんですよ
書いた人間の思いが誤解という言葉には詰まっています
> 誤解という強い表現を使うほどではない」は完全に感想。
これが構造化プログラミングの中に書かれてたらヤバイですよ
でも書かれてないから問題ないんです
執筆者がどういう思いを持っているかを本文に書くべきではありません
あくまで中立に客観的に平等にそして公平に書くべきです
- 87 ：
- >>86
>>85を読んでお前の池沼な頭で反論してみろ。
構造化定理と構造化プログラミングは完全に別物なんだよ！
- 88 ：
- >>87
そうやって罵詈雑言並べ立てて
相手が悪いかのようにしないと
正当性を主張できないんでしょ？
もうその時点でどうかと思うよ
>>85を読んだけど
I.hidekazuが言ってることが正しいと思った
- 89 ：
- ID:KMExyDFm は、ID:HVFTZtzY が書いていることを理解できていないみたい。
こういう人が来ると疲れるわ。
本質的なことは>>4に書かれているけど、ID:KMExyDFm はこれも理解できないのかなあ？
- 90 ：
- >>88
>I.hidekazuが言ってることが正しいと思った
その根拠は？
- 91 ：
- 完全にI.hidekazuに論破されてるじゃん
書き換えて正解だよ
- 92 ：
- >>89
それは全部Wikipediaに書いてあるよ
だから問題ないよね
- 93 ：
- >>90
鬼絡みして相手を疲れさせようって魂胆かな
読めばわかるよね、自明だよ
- 94 ：
- そんなに気に入らないなら自分で修正すれば良いのに
このスレでろくに読みもせずになんとなく間違ってる
雰囲気だから叩いておこうという卑しい心が透けて見えるよ
ほんとくだらない
- 95 ：
- >>89
I.hidekazu本人が来ているだけなので何言っても無駄ですよ。
>>91
意味がわからん。I.hidekazuは誰も論破していない。
まあ、本人だからそういうことにしたいのだろうが。
>>92
書かれていない。Mills がどのようにして構造化プログラミングをダイクストラから奪ったのかが説明不足すぎる。
>>93
>読めばわかるよね、自明だよ
つまり反論できないってことか。
- 96 ：
- >>95
読解力ないからわからないだけでしょ
100回読み直したら？
> 抽象（abstract）及びフローチャートのネスト（nest）すなわち段階的詳細化[17]である
日本語文法わかる？
- 97 ：
- >>96
お前（I.hidekazu）、本当にアホだな。
段階的詳細化：抽象設計→詳細設計
段階的抽象化：プログラムコード→コードを括り出して抽象化
日本語文法が分かっていないのはお前だ！
だからWikipediaにあんなことを書くのだろうが！
- 98 ：
- >>97
及びの意味を考えろよ
単語の意味だけ考えて文章のコンテキストを読めてない
文盲って言うのかな、戦後の日本の国語教育の失敗だよね
結論を言うとWikipediaはいまのままでいい
読書感想文のような客観性のない感情論は削除しまくってもいいと思うけどね
消したら消したでアホどもが騒ぐからしかたなく残してるんだろうな
日本語のWikipediaの品質が低いのはそうしたアホなくせに時間だけは
持て余してるオタクどもに配慮しなければいけないからだろ
- 99 ：
- I.hidekazu = ID:KMExyDFm は、ここで敗北すると面子丸つぶれなので必死。
I.hidekazuでGoogle検索するとここが出て来るからなwww
- 100 ：
- >>98
>及びの意味を考えろよ
一［接］《漢文訓読で接続詞に使う「及」の字を「および」と読んだところから》複数の事物・事柄を並列して挙げたり、別の事物・事柄を付け加えて言ったりするのに用いる語。と。ならびに。また。そして。「生徒及び父兄」「国語、数学、及び英語は必修」
[補説]多くの語を並列するときは、最後にくる語との間にだけ置くことが多い。
二［名］及ぶこと。届くこと。
明らかに一の意味だ。
> 抽象（abstract）及びフローチャートのネスト（nest）すなわち段階的詳細化[17]である
つまり、I.hidekazuは「抽象が段階的詳細化に含まれる」と言っているわけだな。
アホじゃん。
- 101 ：
- >>98
>文盲って言うのかな、戦後の日本の国語教育の失敗だよね
それはお前だ。お前みたいな奴がいるから Wikipedia のレベルが低下する。
- 102 ：
- >>99
何度も言ってるけど、俺はI.hidekazuではないよ
君は思い込みが激しいね
こうだと思いこんだらそれは違うよと言っても考えを改めない
難儀な性格してるね、文章もまともに読めないし
2chでバイアスかけられてイキってるだけじゃん
- 103 ：
- >>102
だったらどういうロジックで俺が間違えているのか書いてみろ
- 104 ：
- >>100
AおよびB、Cである
という文を
AがBであると読み取るその読解力のなさ
思い込みの激しさたるやもう助けようがないよ
- 105 ：
- 論理的な思考力の弱い人は
普段接するようなものに例えてみると
理解力があがるという認知学の研究結果がある
それをふまえて例文を示そう
空を飛ぶのは鳥および飛行機、すなわちトンボである
という文は
鳥がトンボであることを述べていない
- 106 ：
- >>104
そうやってはぐらかしてないで反論してみろ。できないよな？負け犬。
- 107 ：
- >>106
またそうやって相手を貶す発言をする
そういうことを言うから君の言うことに説得力がなくなるんだよ
もっと冷静に議論できないの？
- 108 ：
- >>106
ID:KMExyDFm は、はぐらかしを続けてスレを流しているのではないでしょうか？
ロジカルな反論は全くできていないし、する気もないのでしょう。
ID:KMExyDFm が負けを認めているのと一緒です。
- 109 ：
- >>108
議論に勝ちも負けも良いも悪いもないよ
そうやってなんでもかんでも勝ち負けで考えるから
相手を貶めてやろうなんてことになって
議論が成り立たなくなるんだよ
Wikipediaに書き込む時は冷静になってから書き込むんやで
Wikipediaに勝ち負けなんてないんやからな、おじさんとの約束やで
- 110 ：
- >>109
やはりはぐらかすだけですね。こんな人にかまっても時間の無駄です。
- 111 ：
- >>110
だな。もうやめとくわ。
- 112 ：
- プログラムを実際に書いてると同じような処理があれば纏めようとするだけで、それが構造化にしなきゃとかオブジェクト指向にしなきゃとか考えないよ
そういうのに拘るのは教科書知識で定義をうんちく垂れてる層か他人が作ったのを組み合わせてるだけの層
でしょ
ぶっちゃけ定義なんてどうでもいい
- 113 ：
- 『抽象（abstract）』及び『フローチャートのネスト（nest）すなわち段階的詳細化[17]』である。
『抽象（abstract）及びフローチャートのネスト（nest）』すなわち『段階的詳細化[17]』である。
誤読されたくなければ読点でも入れとけ
- 114 ：
- 君たちは何を成し遂げたいんですか？
Wikipediaの内容が気に入らないなら書き換えればいいじゃないですか
それをやらずにこのスレで客観性を欠くバイアスを掛け合って
心地よくなっても意味がないというか、それこそ時間の浪費ですよ
- 115 ：
- 酷い流れだ
- 116 ：
- 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に似ている
- 117 ：
- 構造化プログラミングについてI.hidekazuの理解が完全に間違っている証拠
この投稿の時点で現行のI.hidekazu版の構造化プログラミングの記事では
「ダイクストラの構造化技法」などという項目があり、そこには
＞従来のフローチャートの進行方向を単線化するため、プログラムは順序的プログラムでなくてはならず、
＞さらにその順序的プログラムはフローチャートの制御の規律を固守するため[23]、
＞・・・、goto文は使用しないようにすべきであるとした[26][28]。
そもそもダイクストラは技法など述べたことはない。
彼の有名な「構造的プログラミング」（ホーア、ダールとの共著書の中の彼の論説）でも
段階的に詳細化を行ってプログラムに至るという考え方については述べているが
とても技法と呼べるほど具体的で詳細な技術レベルのものではなくせいぜい「正しい考え方」に過ぎない。
更に言えば、ダイクストラは「goto文は使用しないようにすべきである」というような単純な規準は主張していない。
これを主張したのはダイクストラでなくIBMのMillsである。
ダイクストラの主張したことは「goto文は検証の障害になることが多い」ということと
「プログラムはその正しさを示せるように書かれるべきである」ということである。
この２つの主張と「goto文は使用しないようにすべきである」という正しくはMillsの主張とが全くの別物だと
理解できないI.hidekazuのような類の人間は「構造化プログラミング」の記事を執筆すべきでない。
そういうダイクストラの主張に無理解でまたMillsの役割も知らず彼の名前もその記事の中で正しく位置付けられない
全くの無知な素人が、記事を勝手に書くことは他の執筆者や利用者にとって全くの迷惑をかけるだけなので
己の無知蒙昧さを自覚して執筆せず前のバージョンに戻して自重するのが正常な人間として最初に成すべき事柄である。
- 118 ：
- >>117訂正
> 彼の有名な「構造的プログラミング」（ホーア、ダールとの共著書の中の彼の論説）でも
失礼、「構造的プログラミング」→「構造化プログラミング」
- 119 ：
- >>117
ここでイキってないでWikipediaで議論するか
書き換えるかしなよ、いい加減邪魔だよ
- 120 ：
- ダイクストラ文学というべきかなあ、このときの作者の思いを述べなさいみたいな
読書感想文なんだよね、構造化プログラミングは文学なのかね
- 121 ：
- >「goto文は検証の障害になることが多い」
>「プログラムはその正しさを示せるように書かれるべきである」
>「goto文は使用しないようにすべきである」
ついでに言うと、これは演繹してるだけだから全く同じことを述べてる
- 122 ：
- >>66
COBOLってさ
プログラム仕様書をそのままプログラム化させるのが目的なようで、宣言文だらけ
プログラムの半分が宣言文じゃないかっていうぐらい
回りくどいんだよね
データのバイト長(ワード長)まで記述してんだから
演算子も確か記号使わず、単語だし
足し算ならPLUSなどと初期のLISPみたいで
(うろ覚え)
- 123 ：
- >>117
>>116の一番下に書けば？
- 124 ：
- >>121
お前、昨日登場した基地外だな
そこしか突っ込めないのかよ
自分の都合の悪いことにはツッコミできないんだなw
- 125 ：
- バイアス要員が来ました
- 126 ：
- わざわざ同じワード使って自己紹介しなくても
- 127 ：
- hidekazu の人気に嫉妬… ＞＜
- 128 ：
- >>117
そこまで書けるなら>>116のWikipediaの「構造化プログラミング」のノートに書けばいいのに。
書いていることは正しいのに行動に移さないのはちょっとねえ
- 129 ：
- このｽﾚの低学歴低知能たちは
教育用や論文の疑似ｺｰﾄﾞに
なんでpascalがよく採用されてるか
まったく分かってない
- 130 ：
- >>129
どうしてなんですか？
先生教えてください
- 131 ：
- それが分かる程度ならWikipediaを編集できる
わかった？
- 132 ：
- >>131
先生はWikipediaを編集できるのですか？
- 133 ：
- 編集できる
しかしｵﾚはwikipedeiaなんか編集しない
編集できることと編集することは
まったく関係ないからな
- 134 ：
- >>133
先生は教育用や論文の疑似ｺｰﾄﾞになんでpascalが採用されてるかわかりますか？
- 135 ：
- 分かってる
しかしｵﾚはこのｽﾚにその理由なんか書かない
ｵﾚが分かってることと、ｵﾚがこのｽﾚに書くことは
まったく関係ないからな
- 136 ：
- >>135
僕は知りたいと思ってます
僕以外にもわからない人いると思います
スレにとって有意義だと思います
教えてください
なんでpascalが採用されてるんですか？
- 137 ：
- https://en.wikipedia.org/wiki/Structured_program_theorem
いちいちｵﾚがｽﾚに書かなくてもｺｺに書いてある
ｵﾚがいちいちｽﾚに書く理由がない
- 138 ：
- >>128
Wikipediaのアカウント作ってないし、それ以前にWikiの書き方を知らないんだ
これだけのために書き方を勉強する気もしないしね
- 139 ：
- いくつかの学者は、Bohm-Jacopiniの結果に純粋なアプローチをとり、B?h
m-Jacopiniの証拠では必要でないため、ループの途中からの復帰や復帰な
どの命令でさえ悪い習慣であると主張し、すべてのループが単一の出口点。
この純粋主義的アプローチは、1990年代半ばまでの学術の入門プログラミン
グ授業の教授のための好ましいツールであったパスカル・プログラミング言
語（1968-1969年に設計されたもの）で具現化されている[9]
B?hm-Jacopini定理を直接適用すると、構造化されたグラフに追加の局所変
数が導入され、コードの重複も生じる可能性があります。後者の問題は、こ
の文脈ではループと半分の問題と呼ばれている[13]。パスカルはこれらの問
題の両方に影響され、Eric S. Robertsの経験的研究によれば、学生のプ
ログラマは、配列内の要素を検索する関数を書くことを含む、いくつかの単
純な問題に対してPascalで正しい解決策を定めることが困難でした。ロバー
ツが引用したHenry Shapiroの1980年の調査では、Pascalが提供する制御
構造だけを使用した場合、被験者の20％のみが正しい解答を得たが、被験者
はこの問題のコードを書いていなかった。ループの真中[9]
- 140 ：
- >>121
> 「goto文は検証の障害になることが多い」
> >「プログラムはその正しさを示せるように書かれるべきである」
>
> >「goto文は使用しないようにすべきである」
>
> ついでに言うと、これは演繹してるだけだから全く同じことを述べてる
それが君やI.hidekazuの根本的な間違い
Dijkstraの主張は正しさを示せるようなプログラムを書くべきということであって
gotoは障害になり易いと主張しているに過ぎない
つまり正しさを示す上で障害にならないgoto文まで使用すべきでないとはDijkstraは主張していない
goto文を使わず３基本構造で書けという分かり易いが極めて薄っぺらな主張をしたのはDijkstraでなくMillsだよ
これを区別できない人間は己の無知を認識して黙ってろ
- 141 ：
- >>140
それはダイクストラを悪者にしたくないという気持ちの現れだわ
お気持ちが混じり合ってど汚い色に変色してる
ダイクストラに対する冒涜だわ、ダイクストラはそんな薄っぺらいことが
言いたかったんじゃない、goto文はプログラムの障害だと明確に述べている
- 142 ：
- Millsはダイクストラの発言を明確に理解してる
- 143 ：
- >>142
こいつ完全に狂っているわw
- 144 ：
- 構造化ﾌﾟﾛｸﾞﾗﾑの理念は
3つの制御構造で適切なｺｰﾄﾞすら記述できないｱﾝﾘｶﾊﾞﾌﾞﾙな知恵遅れは
ｺｰﾄﾞなんか書いてはﾀﾞﾒということだからな
頭悪いﾊﾞｶはあっちいけといってるﾜｹ
わかった？
- 145 ：
- >>138
Wikipedia は間違えた情報を広める害悪だわな。
Google の重視する網羅性が突出しているので、どうしても検索の上位になってしまう。
しかし、Wikipedia の書き方なんて勉強ってほどでもないと思うけどねえ。
- 146 ：
- >>143
Pascalは論文の疑似コードに採用されてる
お前はその理由を解ってない
- 147 ：
- >>142
>>146
Mills がダイクストラの発言を明確に理解しているとしたら悪質だな。
ダイクストラの構造化プログラミングを構造化定理とすり替えて広めたのは Mills の故意ってことになる。
- 148 ：
- >>147
君は理解の意味を履き違えている
日本語の文法を勉強したが良い
Millsは悪くない
ダイクストラはMillsに感謝してる
- 149 ：
- >>148
>ダイクストラはMillsに感謝してる
ソース
- 150 ：
- Millsはダイクストラの発言を敷衍したんだよ
換言するとMillsの発言はダイクストラの発言とみなせるってこと
- 151 ：
- >>149
ダイクストラ
>「goto文は検証の障害になることが多い」
>「プログラムはその正しさを示せるように書かれるべきである」
Mills
>「goto文は使用しないようにすべきである」
これがそのソース
Millsはダイクストラをフォローアップしてるわけ
- 152 ：
- 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 という人は人の話を全く聞かない。アスペルガーなのかもしれない。
- 153 ：
- >>150
ふえん
【敷衍】
《名・ス他》意味のわかりにくい所を、やさしく言い替えたり詳しく述べたりして説明すること。
Mills のニセ構造化プログラミングは、敷衍（ふえん）ではなくて、劣化に過ぎない。
- 154 ：
- >>152
こっちの方が痛いと思う
https://ja.wikipedia.org/wiki/%E5%88%A9%E7%94%A8%E8%80%85:Monadaisuki
- 155 ：
- Monadaisuki曰く
Wikipedia中毒者はWikipediaを使いこなすことにエリート意識を感じ、他
人の記事に因縁・難癖をつけて優越感を得るのを日常とする人間があまりに
も多い
Monadaisukiがやってることのように思えるが
- 156 ：
- >>154
>>155
反論できないから無関係のものを持ち出す典型例
- 157 ：
- このｽﾚはﾈﾄｦﾁｽﾚか
ﾈﾄｦﾁならﾈﾄｦﾁ板がある
そっちで楽しくやりなさい
- 158 ：
- >>156
>>152がアスペルガーだと言ってI.hidekazuの人格攻撃をしていたので
それに対するカウンターとしてMonadaisukiの方がヤヴァくない？
と言ってみました、どう思います？ Monadaisukiの言動について
- 159 ：
- >>157
先生はPascalでプログラミングやるんですか？
- 160 ：
- 構造化プログラミングが捗る言語とかあったら教えて欲しいです
- 161 ：
- >>158
少なくともWikipediaの構造化プログラミングの記事に関してはまともな行動をしているだろう。
- 162 ：
- 昔、turbo pascalを実習で使ったことはある ｺﾚはPCで使えた
まさに、ｸﾞﾗﾌ使って最短経路求めるﾔﾂとかもその実習の中に入ってた
それ以来使ったことない
- 163 ：
- >>155
まあ、Wkipediaに問題が多いのは間違いないかと。
それと Monadaisuki は Wikipedia に対する貢献も大きい。
いくつかの英文記事を翻訳している。
特に「ズブルチの偶像」の翻訳は英語版Wikipediaを読み込んで書かれた傑作。
- 164 ：
- >>163
ITが専門やないんやな
道理で
- 165 ：
- >>164
>>148みたいなキチガイ説を唱えているお前こそIT素人だろwww
- 166 ：
- >>165
いま、ワイの話してるんちゃうやろ！
Wikiで議論してる連中の話や
石像が専門の人が知ったかして絡んでるだけやな
- 167 ：
- >>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、電卓、石像と色々ある。
- 168 ：
- >>166
それとは別にお前が基地外なのは事実だろw
- 169 ：
- >>167
なるほど、なるほど、プログラミングについてはズブの素人とお見受けしました
>>168
キチガイはお前やろ、引くわ
- 170 ：
- はい話題のすり替え完了
- 171 ：
- >>170
ほんまそれな
- 172 ：
- 発端は >>67 からやな
とどのつまり結論としては Monadaisuki がニワカというのが
このスレの総意であり最終回答
Wikiの話はこれで終いや
- 173 ：
- >>172
勝手に総意にするな。だから基地外扱いされる。
それと、I.hidekazuの書いていることが正しいかどうかが問題であって、
もう一人がニワカだろうがニカワだろうがどうでもいい。
- 174 ：
- >>173
あのな、5才児と東大の教授が違うことを言ってた場合
東大の教授の方が正しいに決まってるだろ
常識で考えろよ
- 175 ：
- >>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+
- 176 ：
- >>175
> 全記事調べたけど、I.hidekazu が新規作成した項目はない。
何が言いたいんですか？
そんなに権威が大事ですか？
- 177 ：
- >>176
あんたが言い出したんだろ
自分の言ったことに責任持てよ！
- 178 ：
- 日本のwikipediaはyahoo知恵遅れ程度の情報の質だからな
むしろ新規作成したことあるならﾔﾊﾞｲわ
- 179 ：
- >>178
だったら書かなかったら？
I.hidekazu = ID:IHxJX3F+ = ID:hANAm2gW
- 180 ：
- ごちゃごちゃ言う前に修正したら良いだろ
wikipediaなんだから
- 181 ：
- >>180
ノートで合意を形成するのが理想。
次点で I.hidekazu の反対派があそこに大量に書き込んで多数決状態に持って行く。
最悪は I.hidekazu の修正を元に戻して編集合戦に移行する。
- 182 ：
- どうせ書き込んだやつは満足して消え去ってる
まずは戻してそいつを召喚するのが先
でないといつまでたっても戻せない
- 183 ：
- こんなとこで争ってんのか
とんだ迷惑もいいところ
知恵遅れﾊﾟﾖﾁｮﾝのｻﾏｰﾀｲﾑｽﾚと似てる
- 184 ：
- ここを見た人（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.2ch.sc/test/read.cgi/tech/1534260508/ で酷い内容と書かれていたので取り消し)
元に戻すには、平成30年8月20日 (月) 17:16‎ (UTC) のソースコードを丸ごとコピーして、今のソースコードを全部削除してからそれを貼り付ける必要がある。
ただし、今はそこまでやる必要はない。
>>182
I.hidekazu はこんなことを言っている。
＞近いうちに図表の追加も含めて修正したいと思いますので、しばしの間ご容赦願います。
編集合戦になるのは明らかかと
- 185 ：
- >>184
どういうこと？
平成30年8月20日 (月) 17:16‎ (UTC) のソースコード と
現在の版に相違点はないんだけど？
＞近いうちに図表の追加も含めて修正したいと思いますので、しばしの間ご容赦願います。
どうせこない。だいたい編集は用意してからやるべきことだ。
- 186 ：
- >>185
すまぬ。平成30年8月13日 (月) 14:21‎ (UTC)だった。
- 187 ：
- >>186
なるほど
- 188 ：
- しばしの間ご容赦願いますとか書いて、
どうせそのまま放置して、大きな反論もないし
事実上この内容で同意取れたってことにするつもりだろ
- 189 ：
- >>188
元に戻してくれた人がいた。
平成30年8月26日 (日) 13:03 (UTC)‎ 114.157.218.74 (会話)‎ . . (33,159バイト) (-4,363)‎ . . (戻す版を間違えていたので修正)
- 190 ：
- >>189
あぁ、それな。同一人物だよ。IPv4とIPv6の両方が有効だと
どちらでつながるかはブラウザの気まぐれなんだよ
- 191 ：
- >>190
確か IPv6 で先に通信して失敗したら IPv4 でリトライだったのでは？
- 192 ：
- >>191
いや、ブラウザの気まぐれ。
おそらく速い方だけど、誤差で切り替わる
- 193 ：
- このｽﾚ
ﾓﾅﾀﾞｲｽｷきてるわ
電卓ｦﾀで電卓の新規ﾍﾟｰｼﾞ書いたﾓﾅﾀﾞｲｽｷきてるわ
逆ﾎﾟｰﾗﾝﾄﾞ記法で記述するﾌﾟﾛｸﾞﾐﾝｸﾞﾊﾟﾗﾀﾞｲﾑで
ｵﾌﾞｼﾞｪｸﾄ指向とかwikipediaに書いてるﾓﾅﾀﾞｲｽｷきてるわ
- 194 ：
- >>192
（ ´_ゝ`）ﾌｰﾝ
>>193
論理的に反論してください
そいつのことはどうでもいい
- 195 ：
- >>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で接続しています。
- 196 ：
- >>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 の正当性を説明せよ。
- 197 ：
- 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 ：
- >>196
IPv6の話は私が書いたんですけど？
- 199 ：
- >>198
すまぬ。腹が立ったので、自分のことのように感じた。
- 200 ：
- なるほどね。Firefoxも切り替わるようになってるのね
http://www.net.c.dendai.ac.jp/~kodaira/
FirefoxやGoogle Chromeでは既にHappy Eyeballsが実装されており、
こちらはDNS問い合わせで先に応答した方で通信を試みるという方法を採っている。
また、もしこれが300[ms]経過してもACKが返ってこない場合は通信失敗とみなして次の候補アドレスで通信を試みる。
- 201 ：
- >>199
（ ´_ゝ`）ﾌｰﾝ
>>197>>200
構造化プログラミングの話を・・・
- 202 ：
- > それよりも I.hidekazu の正当性を説明せよ。
正当性なんかないよ。
だから全て消されただろ
IPv4とIPv6を持つ誰かの手によってな
- 203 ：
- >>202
正当性がないなら消されるのか
消されるなら正当性がないのか
どっち？
- 204 ：
- >>203
正当性がないなら、書き込みは無かったものとして扱われる
正当性がないものが書き込まれるってのがそもそも
悪いことなのでそれが無かった状態にされる
本来はなかったことにするのが一番いいのだがwikipediaの仕様上
それができないので削除で代用するしかないだけ
- 205 ：
- >>204
消されないなら正当性があるってことやね
一昨日までは正当性があったんやな
Wikipediaの記事は全部正当性があるんやな
- 206 ：
- >>205
気づかれてないだけ。気づかれればこうやってもとに戻される
- 207 ：
- >>206
消すことの正当性がなかったら消したものが元に戻されますな
気づかれてないだけで
- 208 ：
- 削除は勇み足というか、僕はそうは思わないっていう個人の感想レベルの
根拠なんだよな、ダイクストラ信者っていうのかなあの気持ち悪い感じ
ああいうオタクがWikipediaにのさばってるんやな
- 209 ：
- >>207
消したのが元も戻るっていうのは意味不明。
（同じ内容で？）また書き込むだけでしょ？
正当性がないと判断された内容をまた書き込むとか
反感を買うだけだけどね
- 210 ：
- 図があってわかりやすかったのに、残念だなあ
- 211 ：
- 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)
- 212 ：
- >>209
> 消したのが元も戻るっていうのは意味不明。
>（同じ内容で？）また書き込むだけでしょ？
意味解ってんじゃんｗ嘘つき
消すべきでないものを消しても反感買うだけだよ
- 213 ：
- >>211
筋が通ってるな、論理的に完全に正しい判断だと思った
- 214 ：
- >>208
いいのいいの、あの変なやつを召喚するのが目的だから。
こっそり書き換えて、気づかれるまで、変な記事を残す
指摘されても、気づかないふりして変な記事を撤回しない。
そうやっていつまでも変な記事が残るのが大問題
まず戻す。そして次はレビューが済んだもののみを
つけつければ良い
- 215 ：
- チッ電卓オタクのせいで優良な記事が台無しだな
- 216 ：
- >>212
> 消すべきでないものを消しても反感買うだけだよ
それは１人だけだから良い
- 217 ：
- >>214
電卓オタクの方がおかしいと思うけどね
- 218 ：
- >>216
一人だけの根拠を君は示せないだろ
そうやって姑息な嘘を付き続けるのをやめなさい
- 219 ：
- >>211
>「構造化プログラミング」という著書が既にあって内容も確認できる中、
>ちゃんと本で確認するプログラマーもいらっしゃるわけですし、
>そんな全くの間違いが一般に流布するというのは考えにくいとも思いました。
ちゃんと本で確認するプログラマーなんてほんの一部
英語圏のプログラマーでもダイクストラの本なんて読んでいない
日本だと「構造化プログラミング」はすでに絶版
こういう人はどうしたものか？
- 220 ：
- このスレを見ている5000万人の2chユーザが消したことに
対して憤ってるかも知れないでしょうが
- 221 ：
- >>218
悪魔の証明の話？
俺にその手は通じないよｗ
- 222 ：
- >>219
大丈夫だ、問題ない
- 223 ：
- >>220
頑張って証明してねｗ
- 224 ：
- >>221
論理はわかるでしょ？
一人だって君は言ったけどそれにはなんの根拠もない
ことは明らかだから君は平気でその場しのぎの嘘をつく
クズ野郎だねってことを僕は証明したのさ
- 225 ：
- >>223
可能性が存在するのはわかるでしょ？
一人であることは証明できないから
一人じゃない可能性が存在するって論理だよ
- 226 ：
- 電卓オタクを擁護してるのは姑息な嘘を平気で付くクソ野郎なんですよみなさん
5000万人のみなさん
- 227 ：
- >>225
知ってる知ってる
幽霊はいる派ってやつだよね
科学的だよね（笑いｗ
- 228 ：
- >>222
問題ありだと思いますが？
実際に作業するプログラマーは学術的にプログラミングを捉えていないし、
ダイクストラの分かり難い話よりもIBMのミルズの簡単な構造化定理を選ぶでしょ。
>>211の人は現実を見れていない
- 229 ：
- >>227
> それは１人だけだ
この発言はダメでしたね
一人であることを君が知れるわけがないじゃないですか
何人の人がここを見てるかもわからないのに
どうやって一人だと知ったのでしょうか
知ることができないことをさも知ってるかのように振る舞った
これは相手を騙す意志がないとできない状況なので君は嘘を付いた
君には明白な悪意を持って発言した
君の発言は説得力を失ったと言えます
- 230 ：
- ﾓﾅﾀﾞｲｽｷは
ｿﾌﾄｳｪｱのｽﾀｯｸで
制御やevalを実行できるｲﾝﾀｰﾌﾟﾘﾀ（当然ｺﾚもｿﾌﾄｳｪｱ）の作りを
ｵﾌﾞｼﾞｪｸﾄ指向とかいってる
そしてｵﾚは翻訳しただけだから
ｵﾚは関係ないとかいってる
で、こんなﾔﾂがﾚﾋﾞｭｰがどうこうとかいってる
頭おかしいの？
こんな頭悪いのがﾚﾋﾞｭｰできんの？
なんでこんな頭悪いのが偉そうにしてんの？
- 231 ：
- 悪魔の証明とか幽霊とか
わけのわからないことを言って笑って
誤魔化そうとしてますが嘘がバレた以上
君が取るべき手段は謝罪だと思います
- 232 ：
- ぷｗ オレはオレがしたいようにするよｗ
だから謝罪したいと思ったら、謝罪しますーｗ
- 233 ：
- >>230
半角きもい
構造化プログラミングの話をしているなら構造化プログラミングの話で論破すれば？
他の話を持ち出すということは自分に自信がないってことでしょ？
- 234 ：
- 自分にあまく他人にはとことん厳しい
- 235 ：
- それが僕らの生きる道
- 236 ：
- 週も変わったことだし今週は Monadaisuki を重点的に査定して行く方向で
- 237 ：
- お前ら遠慮すんなよ
- 238 ：
- 構造化定理と構造化ﾌﾟﾛｸﾞﾗﾐﾝｸﾞは
英語版同様きっちり分けて記述したほうががいい
ｵﾚが収束のために提案できることはｺﾚ以外ない
- 239 ：
- >>238
それを拒否しているのが>>211に書いた人でして
- 240 ：
- >>230
>>233さんの言う通りだと思います
RPLの話を持ち出しても構造化プログラミングの話とは無関係
- 241 ：
- プログラムに関する知識が皆無なんじゃないか疑惑だろ
構造化プログラミングと大いに関係ある
免許持ってない医者が腹かっさばいてたら殺人罪だろうが
事の重大さを考えろ
- 242 ：
- ｷﾐﾗはな自省というもんがない
そこが問題なﾜｹ
自分たちがいかに無能でｺﾞﾐでｸｽﾞなのか
という自覚がないﾜｹ
だからいつまでたってもまともな人間になれないﾜｹ
わかる？
はやく人間になりなさい
- 243 ：
- >>242
あなたが荒らしってことは理解できた
- 244 ：
- >>243
おいゴミ
- 245 ：
- Monadaisuki に反発している人は、どうして Monadaisuki がノートに書いたことについて具体的に反論できないのだろうか？
構造化プログラミングと無関係のところを必死に叩いているだけ
>>242 と >>241 を読むだけで ID:wSgDz8cK と ID:zX+eejgv が荒らしだとよく分かる
ここを荒らしたいだけ
- 246 ：
- このスレWikipedia観察日記じゃないからな
Wikipediaのこと書いてる時点で全員荒らしだろ
バカヤロウが
- 247 ：
- >>246
論点ずらして逃げ出すんなら自由だぞｗ
＞Wikipediaのこと書いてる時点で全員荒らしだろ
＞バカヤロウが
なるほどWikipediaの記事関連で20件ほども１人で投稿してるお前が最悪のスレ荒らしということだな
- 248 ：
- >>247
アラスナカス
- 249 ：
- >>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 が東大の教授と断言できる根拠が全然ない。
自画自賛と解釈すれば納得できるが。
- 250 ：
- >>249
思い込み激しすぎ、落ち着きなよ
- 251 ：
- >>245
>>247
全くその通り
>>249の言うことが正しいのかどうか不明だが、ここまで荒らすと言うことは何か目的があるんだろう
もっとも Monadaisuki に嫉妬しているだけという2ちゃんねるにありがちなことかもしれないが
- 252 ：
- 嫉妬するね唇に本能
- 253 ：
- やば
ﾏｼﾞｷﾁが発作おこしてる
ｺﾚはﾎﾝﾓﾉさんがきてるわ。。。
分かりやすい。。。
- 254 ：
- 荒らしのせいで荒廃したな
- 255 ：
- 正直にいってみ
ﾓﾅﾀﾞｲｽｷきてるだろ
- 256 ：
- その話は既に終わったんだから、いつまでも続けるな
- 257 ：
- 荒らしの勝ちだな
誰も来なくなった
- 258 ：
- >>255
>>67がそうだろな
- 259 ：
- >>257
>>67のせいだな
- 260 ：
- ぜんぶ電卓オタクのせい
- 261 ：
- >>258-260
荒らしが速攻で来た！
- 262 ：
- >>261
ちなみにこいつは >>67 ではない
>>67 が電卓オタクだということに気づかず
擁護したただの痛いやつ
- 263 ：
- 論破されても荒らしに来る鋼のメンタル
- 264 ：
- >>263
論破されたのはお前だろ
その電卓オタクやらのどこが間違えているのか書いてみろ
- 265 ：
- >>264
うわこいつも荒らしかよ
- 266 ：
- まだやっているのか？
結論は >>245 >>247 >>249 で出ている
- 267 ：
- 一応言うておくと、２０２０年プログラミング教育はじまるやろ。
構造化プログラミングを知らない教師教えてるの怖いっていうと思うぜ。
本屋に構造化プログラミングの本は売ってないけど基本だとは知ってるだろう。
自分の子供に跳ね返ることをやるのはよくないと思うぜ。
- 268 ：
- ははーん、なるほどな
- 269 ：
- >>267
それでも日本は強行するんだよね、、
つまり、基本的な事をないがしろにして教育進めると言う
- 270 ：
- でもお前らろくに教育受けてない分際でよく頑張ってるじゃん
それを教育受けられるようにしたらもっと良くなるだろ
- 271 ：
- >>267
そもそも教師ごときがプログラミングを教えるな！！！
- 272 ：
- っていうか、学校で教えるほどのプログラミングが
どれだけ使えるんだって話だな。
そしてそれと同様に、学校で教える算数（数学）も
理科も、役に立たんだろ？
内容のレベルには期待しないのがデフォやで？
- 273 ：
- >>272
そもそも学校って何のためにあるの？って気がするよね
- 274 ：
- >>273
朝早く起きて学校に通学して、同級生とともに年上の人の話を休憩を挟みつつ
黙って聞くというところに慣れるためのところだと思う。すごい役に立つ。
そういう枠組みがあると社会に出たときに上司も統制しやすいからだろう。
騒ぐ奴には小学校出たのかって言っておけば抑え込めるし。
無意味に良い教育とか言い出してその枠組み壊しちゃうから統制できなくなる。
不良学生押さえ込むために体育教師が空手を真剣にやりだしたんで部活で空手を
うまく教えることができていました、というのが昔の実態だと思う。
- 275 ：
- 潜在能力のある子ども達をもれなく発掘するために全員に知識を授けている
結果として上位何パーセントかのエリートに抜けなく教育を施せるならなんでもいいのだけど
無差別に教育して試験で選ぶより確実な方法がないのが現状なので学校がある
他の無才の子ども達は本当は教育は要らないんだけどエリート発掘のための必要経費と割り切る
遺伝子解析の精度が向上して最初から才能がわかるようになったら義務教育はなくなるだろうね
エリート以外の人達は知識がないほうがコントロールしやすいから逆に教育しないほうが搾取しやすくなる
- 276 ：
- >>275
それは別に構わないのだけど、AIの理論で言う所の評価関数一つしか設定してなくない？
金融工学に、卵は一つのカゴに入れるなという格言あるし、各評価関数の相関性ばらけ
させたほうがよくない？これサブプライムローンと構造同じじゃない。
- 277 ：
- >>276
評価関数は複数ある
学科目や部活動のことね
- 278 ：
- >>277
なるほど。ちゃんと考えているなら安心だ。
- 279 ：
- >>275
なるほど、船頭多くして船山に登るってやつだな
- 280 ：
- >>275
なるほど、働きアリの法則ってやつだな
よく働いてる働きアリだけをあつめても、
なぜか2割はサボるようになるというやつ
- 281 ：
- >>274
ほとんどのガキには機能していない
>>275の言うように大半のガキに教育は不要
>>277
それは無理なくね？
評価関数は受験だけだと思うのだが？
- 282 ：
- 学科目や部活動が評価関数になるなら
ビデオゲームの上手さも評価関数になって良いはずだ
- 283 ：
- >>282
評価関数にできるだろうけど、多様な解釈を許す開かれになるので、
ただ一つの評価関数には落とし込めないと思う。ゲームにもよると思うが。
- 284 ：
- >>281
>評価関数は受験だけだと思うのだが？
ほんこれ
- 285 ：
- つまり、受験の点数が高い人ほど
評価も高いという評価関数を作れば良いんだな
- 286 ：
- ステータスオープンって叫んだら
評価値が表示されればいいのにね
- 287 ：
- 値（数字）である必要はないな、自分なら比較可能なformを導入して
極小formみたいなものを安定解とするな。
- 288 ：
- >>285
日本の世の中はそれで回っているのが実情
- 289 ：
- 偉い人は頭がいいからな。サマータイムとか
- 290 ：
- >>280
なかなか考え深い理論だね
「働いたら負け」と考える自宅警備員はフリーライダーなのかな？それともサボってるだけなのかな？
そしてこの2-6-2の理論が構造化にも関係してるところがまた凄い
自宅警備員が構造化の大切な要素とは思ってもみなかった
(構造化プログラムとは無関係だろうけどさ)
- 291 ：
- >>290
そこまで考えているなら本当に安心だ。
- 292 ：
- 構造化プログラミングでは
イベント駆動のハンドラが実装できない。
- 293 ：
- 例えばC言語は構造化プログラミングだから
イベント駆動という概念が存在しない
- 294 ：
- X windowsでも Windowsでも
普通にｲﾍﾞﾝﾄﾙｰﾌﾟもってる
そのｲﾍﾞﾝﾄを受け取ったときの処理を記述すれば
それはよく巷でいうところのｲﾍﾞﾝﾄﾊﾝﾄﾞﾗの一種になる
ちまたでは
そのそれぞれのｲﾍﾞﾝﾄの処理関数をｲﾍﾞﾝﾄﾊﾝﾄﾞﾗと呼称してることが多い
で、それとほんの少し別の話で
ｼｸﾞﾅﾙになると通常割込ﾍﾞｸﾀの制御はOSで隠ぺい化されてる
ｼｸﾞﾅﾙが発生したときの動作を記述した処理を
ﾕｰｻﾞｰがﾚｼﾞｽﾄしておけばその処理をOSが呼びだすようになってる
当然、ｺﾚもｲﾍﾞﾝﾄﾊﾝﾄﾞﾗの一種といえる
- 295 ：
- はい。知ってます。
- 296 ：
- FORTRAN 66でイベントハンドラ書いたことあるよ
コンパイラオプションでなんか指定してたと思う
汎用機に繋げたジョイスティックによるUI処理で
だからCだって、出来るんじゃないの？
- 297 ：
- >>296
Cの場合、関数のポインタをイベントハンドラとして登録するような仕組みにすればできる
- 298 ：
- オブジェクト指向は機能をオブジェクト同士の関係性でしか
記述できないからわかりにくいんだよな
構造化プログラムは機能が独立してるから分かりやすいんだよな
- 299 ：
- >>298
オブジェクト指向と構造化プログラミングは相反するものなのかねえ？
構造化プログラミングにもクラスの概念に似たものはあるはずだが
- 300 ：
- >>299
構造化プログラミングにもクラスの概念に似たものはあるはずだが
これが構造化プログラミングが廃れた原因だろ
これ使うならオブジェクト指向で記述したほうがいい
オブジェクト指向はわかりにくいとかいたが、世の中には
「わかりにくく」表現するしかないものある
- 301 ：
- >>300
抽象化データ構造+その上で動作する抽象化文がオブジェクトやクラスに相当するのだが、ダイクストラ氏はもっと大きな単位で考えていたみたい。
しかし、オブジェクト指向言語のオブジェクトはかなり細かい単位になってしまった。
- 302 ：
- 機能ってのはほんらいモノではコトなわけだ
それを無理やり関数って形でモノにするのが構造化プログラム
だからまくいった構造化プログラムは断然わかりやすい
まあ構造化プログラムは頭いいやつにしかできない
凡人はオブジェクトが一番だよ
- 303 ：
- >>302
日本で(略
- 304 ：
- >>303
日本語でだろ？
- 305 ：
- 学校がフィルタリングの機能程度くらいしか果たしていないから
もう少し技能を見に付け入られる場にする必要が有る
小学生からやる必要は無いと思うけど
中学生くらいからどういう職業に就くか?
という視点で組みなおした方が良い
- 306 ：
- ちょっと煽られたことがあるからって排除したらダメだって。
哲学者がやっと生業を得られたもんで、今までの業界に対する
不遇を怨念のようにぶつけているだけじゃないか？
構造化がどうだのオブジェクトがどうだのということではなくて、
僕らは歴史的に言えば哲学者に相当する人種です、と区分けしたい
だけでしょ。
- 307 ：
- 哲学者というのは語弊があった訂正。脳筋多い人。
- 308 ：
- こんなページを見つけた。
翻訳：構造化プログラミングを最初に提唱した文書
http://calculator-cafe.com/readings/Structured_programming/Structured_programming.html
この最初の文章と書籍 "Structured programming"（1972年）とは違いがあるのかな？
同じ考え？
- 309 ：
- 構造化プログラミングとオブジェクト指向って、
どっちか一方だけを残すようなもんじゃないだろ。
- 310 ：
- >>309
現実には組み合わさっているよね
- 311 ：
- >>308
第２章を書いたホーアが誰からアドバイスを受けたか。
たぶんホーア経由でダイクストラは何を聞いたか。
- 312 ：
- 興味深いなぁ
元々プログラミング専門でやってきてなくて転向してきたから
理屈は分かってるつもりだが本質を問われると自信ないんだよなー
- 313 ：
- >>312
大丈夫だ。日本のプログラマーのほとんどはプログラミングの本質なんて理解していない。
- 314 ：
- >>313
だが気になるんです
- 315 ：
- タワシ、木に成ります
- 316 ：
- つーか、プログラミングの本質ってなんだ？
それをダイクストラが作ろうとしたけど、ミルズに妨害されてうやむやになったのでは？
- 317 ：
- アルゴリズム+データ構造=プログラミングって本があったろ。
まさにタイトルが真実ついてるなと。
検索とか出来る様になってもテキストファイルや、WinAPIが標準でサポートするbmpファイルは弄れても、世の中で求められてるのはjpegや各種カメラのRAWファイルの編集。
データ構造が分からないと触れもしない。
解析とか勉強しないとかね。
- 318 ：
- >>317
>アルゴリズム+データ構造=プログラミングって本があったろ。
>まさにタイトルが真実ついてるなと。
それってクラスのことじゃね？
結局、オブジェクト指向で全部いいやってなってしまった
- 319 ：
- アセンブラだってアルゴリズムとデータ構造じゃん
それをどう扱いやすくするかが問題なわけで
- 320 ：
- >>318
言われてみればそうなんだけど、実際にはクラスは型の側面が強くて、クラス作ったら手続き(アルゴリズム)を内包するデータ構造になってしまった。
- 321 ：
- STLが最初に登場した時はデータ構造から切り離されたアルゴリズムに対してOOPな方々からフルボッコだったらしいよ
最終的には勝利したのは歴史が示すとおり
- 322 ：
- 何を持って勝利なのかわからんが、
STLに相当するものが他の言語にないのはなぜか？
その答えはわかっていて、C++のオブジェクト指向は貧弱だったんだよ。
機能も貧弱だし、なにより標準のオブジェクト指向ライブラリが存在しなかった。
あとC++にGCがないから仕方なくSTLを使ってるっていうのがもう一つの大きな理由だな
- 323 ：
- GCデフォだと困る場面もある
仮想マシン使うならGCデフォでも良いがそーじゃないでしょ
- 324 ：
- >>323
それが本当の理由。構造化がとかアルゴリズムがうんたらじゃなくて
GCでは困る場合に対応しようとしたためにSTLが必要になった
- 325 ：
- pythonはSTL相当の機能を備えてると言える？
- 326 ：
- >>322
いわゆる instantiate なる語が C++ 界隈以外ではほとんど聞かれない、のと同値なのではないでしょうか？
- 327 ：
- instantiateでぐぐったらUnityしかでてこんのだがｗ
- 328 ：
- >>325
STLが不要と言える機能は搭載してますね。
1. GCを備えてるから、STLのなんたら_ptrが不要
2. コンテナデータ型を備えてるから、STLのコンテナ型およびイテレータが不要
- 329 ：
- STLの肝かつ叩かれた部分はアルゴリズムをコンテナのメソッドにせずに外出ししているところで
コンテナ部分が言語組込みかライブラリ実装かはどうでもいい
pythonに関して言えば(今は違うが)変数に型が付かないので特に意識しなくても
関数を異なる型に使いまわせるのだから同じようなもんだ
- 330 ：
- 英語版の Structured programming も構造化定理と構造化プログラミングを混同しているようだぜ
https://en.wikipedia.org/wiki/Structured_programming#Structured_programming_languages
やれやれ
- 331 ：
- 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
これこそが構造化プログラミングなんだよね。
- 332 ：
- これ読むとなんらオブジェクト指向と相反しないなw
というか現在に至るプログラミングの基礎を提唱しただけに見えるわ
- 333 ：
- はい。私が書き換えました。ほめてほめて
- 334 ：
- >>333
よーしよしよしよしよし( ＾∀＾)ノシ
- 335 ：
- >>331
分かりやすくなったと言うよりは以前の記事の構成が悪すぎて歴史のところ以外は意味不明だった。
しかも I.hidekazu とか言う構造化定理と構造化プログラミングの区別のできないアホがさらに酷くなりそうになったところをここの住民が元に戻した。
- 336 ：
- >>335
正 区別のできないアホがさらに酷くしてしまった
誤 区別のできないアホがさらに酷くなりそうになった
- 337 ：
- >>332
オブジェクト指向と相反はしないけど一緒でもないんだよね。
- 338 ：
- そりゃ構造化プログラミングに足りないものを
補ったのがオブジェクト指向なんだから当然だろう
- 339 ：
- >>338
Simulaがまさにそんな感じ
ALGOL+Classだったからなあ
- 340 ：
- 値だけで論理演算する機能ってほしいと思ってるんだけどなかなかないのかな
例えば
if(value == (1 || 2 || 3) )
だったらvalueが1~3のあいだならtureになるとか。
if(value == (1 || '1' || true) )
みたいに型を飛び越えられたらなお便利。
OR演算が書きやすくなるな。
- 341 ：
- UnkoValues.contains(value)
- 342 ：
- >>340
値だけで論理演算してないじゃん
それ、論理演算子 == とか || に
そういう意味をもたせてるだけでしょ？
- 343 ：
- value in [1, 2, 3] のように書ける言語はたくさんある
こういうのは論理演算じゃなく集合演算
値の論理演算のニュアンスに近いのはJavaScriptの x = y || -1 みたいな式
- 344 ：
- >>331
やっとまともな記事になった。
構造化プログラミングは構造化定理と別物なんだよ。
- 345 ：
- 自演臭い
- 346 ：
- I.hidekazuさん降臨
- 347 ：
- >>343
inみたいな演算子が無くても関数はあるよな
- 348 ：
- ﾓﾅﾀﾞｲｽｷきてるだろ
- 349 ：
- 構造化プログラミングって
１９８０年頃はやはったなー
- 350 ：
- ダイキストラも懐かしいー
95年頃に銀行で顧客サービスの最短パスもとめるのに
つかったわ〜
- 351 ：
- >>349
たいてい構造化定理のことを指しているけどな
- 352 ：
- >>340
true|falseを返す関数とか作れば良いんじゃね
- 353 ：
- 関数で切り出すとか構造体にまとめるとか当たり前のことをやらん馬鹿があまりに多すぎる。
- 354 ：
- >>353
言えてる
- 355 ：
- もうやめようぜ。
これだけじゃエスパーじゃないとわからんか
- 356 ：
- もう気が済んだんじゃないか？
こういう世界になって本当に満足なのか？
理由まだ残っているのか？
俺はなんとか頑張ったぜ
- 357 ：
- 上で荒らし行為を行っていた 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の記事として無料で図まで含めて作成した記事だったんです。
こいつアホすぎるわ。
構造化定理と構造化プログラミングの区別もできないくせに数十万円使って調査ってバカ丸出し。
金かけても内容がクソなら意味ないだろうに。
- 358 ：
- >>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 票、無効票なし。ガイドラインに基づき、今回は見送りとなります。
こんな人が管理者になったらやばすぎる
- 359 ：
- なんだと！本人降臨だぞ！
○ビー・エムか○ロックスか知らないけど操作しすぎなんだよ！
アラン・ケイのオブジェクト指向なんてマイケル・ジャクソンの
JSD法のパクりじゃねえか。
商業戦略上業界あげて黙ってたから混乱してるんじゃねえか‼
- 360 ：
- 憶測混じりでもうこの際だ言ってやる
JSD法の分析パートの用語「実体」を「オブジェクト」に置き換えたのがいわゆるオブジェクト指向の哲学
実装パートの言語をsmalltalkとかにしてマルチスレッドなGUI開発させるためのバズワードが
オブジェクト指向プログラミング
- 361 ：
- JSDっていつ考案された？
ジャクソンシステム開発で検索してもあまり良い情報が出てこないんだよね
- 362 ：
- すまん。システム開発の出版は1983年で年代的に後だったわ。
- 363 ：
- Simula の登場が1967年
Smalltalk の登場が1980年
- 364 ：
- >>363
> Smalltalk の登場が1980年
“登場”をどうとるかによるけど
Smalltalk（というかメッセージングのオブジェクト指向のコンセプト）自体は
Smalltalk-72の時点、つまり1972年にはもう実証されていて
コンセプトも同年のダイナブック構想の論文で言及済みということはある
- 365 ：
- パルアルトでは70年代初頭から開発されてきたと言われるがほとんど秘密で
1981年8月号のBYTE誌の特集として突如大公開された。
いまから見直してみるとmachOSのディストリビューションの開発者の
ゲイツ氏とジョブズ氏にGUIシステムとそのプログラミング手法として
オブジェクト指向プログラミングを公開する必要があったから
なのかもしれない。
クラウドもそうだがパルアルトは未だに生きていると考えるべきだと思う
- 366 ：
- ネットワークプログラミングを含めオブジェクト指向は成功を納めたが
時代はハードウェア制御と機械学習に進んでいるし、人間から十分な
学習データを取得してしまえばそれもやることなくなる
- 367 ：
- >>366
なんだか、その辺から拾ってきたバズワード並べただけで、
意味が見出せないんだが
- 368 ：
- >>366
日本語
- 369 ：
- https://ja.wikipedia.org/wiki/%E3%83%8E%E3%83%BC%E3%83%88:%E6%A7%8B%E9%80%A0%E5%8C%96%E5%AE%9A%E7%90%86
ウィキペディアの構造化定理のページに基地外来襲！！！
「構造化定理」を「構造化プログラム原則」という訳のわからない言葉に変えようとしている。
(((( ；゜Д゜)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
- 370 ：
- >>369
> ウィキペディアの構造化定理のページに基地外来襲！！！
> 「構造化定理」を「構造化プログラム原則」という訳のわからない言葉に変えようとしている。
誰かウィキペディアを書ける人は、このGoldensundown2の提案に反対しているのに対する反論としての
＞・・・。「Structure theorem」＝構造化定理は数学分野のものと重複してる紛らわしい言葉という点も御考慮ください。--Goldensundown2（会話） 2019年9月9日 (月) 13:56 (UTC)
に対して、
「Structure theorem」は数学の定理と同じ意味（幾つかの公理から演繹的に証明される命題）としての定理だから、「構造化定理」と呼ぶのが適切で
「原理」という言葉を使うのは不適切どころか完全な間違い
と反論を書いて下さると嬉しい
- 371 ：
- 自分でやれや
- 372 ：
- 今に始まったことじゃないけど日本のwikipediaってクソばかりだな。
Windowsとかアンチが多そうな記事は悪意が感じられる
- 373 ：
- >>372
構造化定理の記事は比較的ちゃんと書かれているのでは？
しかし、>>369のようにおかしな人が来て悪化させてしまうこともある
- 374 ：
- >>369
https://ja.wikipedia.org/wiki/Wikipedia:%E6%8A%95%E7%A8%BF%E3%83%96%E3%83%AD%E3%83%83%E3%82%AF%E4%BE%9D%E9%A0%BC/Goldensundown2
そいつブロックされてるやん、ワロスｗｗ
- 375 ：
- ちゃんとファイル分割して関数切り分けして構造体切り出すだけで
ほとんどのプログラムはまっとうになる。
問題はそれをできてないバカが圧倒的に多いだけ。
- 376 ：
- 出来る人が少ないと仕事がこなせない
だからわざわざ構造化プログラムだとか言って教える必要が有るんでしょ
ただ罵詈雑言を言う事の方こそにこそ意味がない
自分が凄いって自慢したいだけ
- 377 ：
- >>376
関数切り出しだとか当たり前のこともできずに
無駄に動的なポリモルフィズム入れたり
そんな輩にまともな話は通じないんだよ。
自慢じゃなくて普通のことを普通にやれというだけの話。
糞機能よりも大事なことは山ほどあるってのに。
- 378 ：
- ぶっ（笑）
構造化プログラミングなんて1985年頃から雑誌で話題だったわ（笑）
- 379 ：
- はいバカ1人ご来店
- 380 ：
- >>378
> 構造化プログラミングなんて1985年頃から雑誌で話題だったわ（笑）
1985年頃って、お前、10年近く遅れてるぞ（爆笑）
- 381 ：
- >>378
しかし、構造化プログラミングを理解していないプログラマーは多いぞ
- 382 ：
- ＞構造化プログラミングはまだ必要ではないのか？
まだそんなこといってんのかｗ
その昔グリースの「プログラミングの科学」を読んだ自分
プログラム検証の時代はまだ来ないのか？！
- 383 ：
- ジャクソンの構造化プログラミングというものもあるがそっちのほうが重要じゃね?
- 384 ：
- >>383
データ構造がうまくできていれば、制御は必ず書けるからねえ
- 385 ：
- ダヨネ
- 386 ：
- そやな
- 387 ：
- ソイヤ！
- 388 ：2020/04/26
- お前らが追い出したせいで圏論に戻ってきやがった
受取拒否させろ
【えっ】Perlに未来はあるのか？【終わり？】
サウンドプログラミング5
HSP総合スレ【part 10】 [無断転載禁止](c)2ch.net
【アンチ】関数型言語は使えない【玩具】 ２
BASICの宿題はお前にまかせた
AI AI って夢見すぎてない？
集合論に基づいた言語を作りたい
Lisp Scheme Part41
OpenCLプログラミング#1
【日本語不自由】Eclipse Pleiades プラグイン
--------------------
【速報】一流落語家「右翼を揶揄するパヨク、左翼をバカにするネトウヨ。そんな翼達への監視人をウイングマンと呼ぶのはどうだろう」 [875949894]
【朝日新聞】 中国人を排除するより、ともに手を洗おう[1/25]★２
崎元仁とベイシスケイプの仲間たち-TRACK:14
魔法少女まどか☆マジカっての面白いの？アニメスレで良く名前みるんだが？ [914113366]
【アンジュルム】佐々木莉佳子ちゃんが気になる Part155
【ラブライブ！】園田海未アンチスレその7【 μ'sの膿 】
どうでもいいことばかり報告するスレ∞
【ありふれた職業で世界最強】厨二好き/白米良10
明日の日経平均をちゃんと予想するスレッド〜225〜
【祖父は横綱】 琴鎌谷将且part2 【父は琴ノ若】
【仰天】日テレ 久野静香 Part6【NFL倶楽部】
武田信虎は過大評価されすぎ！！part1
【韓国】日本との通貨スワップ再開に向け努力 韓国中銀総裁が意向表明[05/06]
【恋活】pairs(ペアーズ) Part227【婚活】
test
【画像】羽生結弦さんとイチャつく 4038
色んなジュニアアイドル画像13
【アクロス】バーサス★54【VERSUS】
PMS（月経前症候群）って甘えだよね
【大原オーナー】MAHARAJA六本木【日本都市】
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
