カプセル化は愚かな考え
レス数が1000を超えています。これ以上書き込みはできません。
■危険性
かつて偏差値の低い学校向けの情報処理系教科書において「カプセル化は大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心とした「インターネットを作った人たち」は「階層化の有害性（RFC 3439)」として「カプセル化は絶対にやめろ」としている。
大雑把にいうと、教科書の上では素晴らしく、開発を始めた最初のうちは良いが、将来的な改修の際に隠蔽されたデータにアクセスできないと解決できない問題が出てきて、非常に高確率でデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」などという概念はない。
ソースコードが存在し改修が可能であればカプセル化しても問題ない。ソースコードがあってもライセンス的に改修できない場合や、そもそもバイナリのライブラリしかない場合などは絶望的である。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0) ■ 実例
XNA（MonoGame）では標準で3Dモデルを手軽に扱えるModelクラスが用意されている。 １行で読み込み、１行で描画できる素晴らしいものだ。
ただしこのModelクラスを使うと頂点データは遮蔽されておりアクセスできない。 物理演算エンジンに食わせるのにどうしても頂点データが必要なのにだ。
世界中の誰もが同じ問題で悩んでいるようでstackoverflowに回避策が書いてあった。内部でGPUへ送信したときに使用したGPUにアクセスする関数ポインタは公開されているのでGetData関数でそのまま返してもらうトリッキーなコードでめでたく回避できた。
しかし、時は流れこの方法では動かない環境が登場した。iOSやAndroidだ。こいつらが採用するOpenGL ESはGPUとの通信が一方通行だ。そこで事前に3Dモデルから頂点データを抜き出し別ファイルに保存しておくという一段とトリッキーな方法で回避する。みごと1モデルのファイルが２個になりました。
さらに時は流れた。あるとき謎の不具合が発生。連日連夜のデバッグ作業。原因は片方のファイルの更新を忘れていただけでした。
カプセル化は恐ろしいね！！
https://github.com/MonoGame/MonoGame/blob/develop/MonoGame.Framework/Graphics/Model.cs 仕様変更
それは雲の上で決まったことなので底辺社畜のITドカタにはどうすることもできない。
意見を言おうにも雲の上にいる奴らの顔すら知らない。
それこそが階層化で起きることだ。
オブジェクト指向云々ではない。 シンプルなほうが解読しやすいよね
散逸して現物しか残ってない場合とか特に データベースに出し入れするだけの業務システムなんかは問題ない。
データベース上のデータなんてグローバル変数となんら変わらない。
クラスは構造体としてしか使わないから深い階層化も起きないし。 >>1
C++が流行りだしたころに、これ言ったら変な目で見られたわ。
設計能力と未来を見通す能力がある人限定なんだよ。
大人数だと低い方に合わされるから、大人数プロジェクトには不向き。優秀な少数精鋭プロジェクトなら良いんだけどね。 日本の場合はカプセル化されてようがいまいが基底クラスなんて弄ったら再テストしなきゃいけないから
同じ機能を持ったクラスを作るので意味が無い 昔作ったクラスを継承したり再利用したりなんて殆どない
データと関数数個だけで済むものを
無駄にクラス化して
ヘッダと実装にわけて無駄にコード追いにくくするのはあかん >>2
この実例は良くないよね
Modelクラスが何かにラップされてるならその元を探して改良すべきなのに、
それやらないでトリッキーな方法で回避するから余計面倒になってる >>10
その相手が壮大なオープンソースのフレームワークで
改変した修正パッチが開発チームから拒絶されたら死ぬ。
フォークしたとして誰がメンテナンスするんだよ オブジェクト指向で設計やるとしばしば手段が目的化してしまって不必要に複雑化する 想像を絶する馬鹿が想像を絶するカプセル化をしてしまうんだよなあ…… >>2
特定の事例はオブジェクト指向とかクラスが悪いわけじゃなくて
その設計が失敗してるだけですね >>15
XNAというマイクロソフトの天才たちが推し進めたプロジェクトでも失敗しているという事例だし、凡人だったらもっと悲惨なことになる。 オブジェクト原理主義者のコードを引き継ぐ事になった時の絶望感は異常 「カプセル化は悪」「カプセル化はオブジェクト指向ではない」というのがやっと広まりだした。 >>15
XNA作ったマイクロソフトの超エリートたちですら設計ミスをするくらいオブジェクト指向は難しい。 組み込みだと細分化し過ぎるんじゃね？
業務システムで細分化することはまずない。 業務システムだとDBいじくるだけだから深い階層構造に関わることはまずないだろ。
DBというグローバル変数をクラスという名の構造体にコピーして、編集して、書き戻すという単純作業の繰り返し。 結論：privateにしたら、必ずgetterを用意しておきましょう。 今一番勢いのある言語であるPythonは完全なプライベートじゃ無いんだよな RFC 3439では、インターネット構造に関して第3章の序文に"Layering Considered Harmful （階層化の有害性）"と題された節が有り、
「階層化」という考え方が概念的および構造的にさまざまな利点を持っているが、
実装面では層単位で同じような最適化が繰り返し発生することによる無駄な処理により効率的な実装を阻害し、複雑化を招くことがあり、
また低層部分のみに存在するデータにアクセスできない場面が発生するなど、
インターネット・プロトコルの目指す「単純化」という原則に反する
https://ja.m.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:UDP_encapsulation.svg メソッド全部staticにしてみろ
大半の問題が解決する > オブジェクト指向の発案者であるアラン・ケイもコーディング規約
> （頭文字にアンダースコアを付けるなどの命名規則）で縛る程度にすることを推奨しており、
それがprivateでは？ >>32
名前でprivate感を出すだけにしておくって話だと カプセル化が悪いというより、カプセル化にこだわる奴が不適切なカプセル化を認めないところが問題。 不適切なカプセル化とは？
アランケイも言っていた、privateはアンダースコアをつけるだけでいいと
つまりprivateでもアクセス可能にしておくのが良いということで
privateでもアクセスしていいということ
ならprivateにアクセスする手段がある言語であれば
アランケイの名前で明示するやり方よりも良い手段であるということだよ。 >>2
それをラップするモデルを作るんだよ。場当たり的な対応をするからそんなことになる。 >>38
その例だと低層からのデータを捨て去ってるわけで、
ラップしても破棄されたデータは復元できない。
破棄しないように作り直すしかない。 >>40
実例も糞もpythonにはprivateもpublicもない。
すべて暗黙でpublic 結局の所、privateはあってもいいけど
呼び出したらエラーになるんじゃなくて
ワーニングレベルで良かったって話よね？
テストコード以外から呼んだらワーニングにすればよかった。
そういう言語があると良いね。 キミ戦争を英語で何て言う？
え？ウォー？
warをウォーって読むのになんでwarnはワーンって読むのｗｗｗｳﾜｰﾝってかｗｗｗｗ
バカじゃないのｗｗｗｗｗ ばかはどんな言語機能を用意しても糞な変更したり、普通の変更がしずらい構造にしたりするんだから無意味。
言語機能の問題じゃない。 >>44
バカの問題と技術の問題は分けて考えましょう >>39
捨てられるデーターを保持しといて、それをカプセル化したらいいんではないの？ >>45
いつでも簡単に分けられると思ってるのはバカですね。 >>43
Rの発音はカタカナ表記できないから一概にどちらが正しいというものでもない
warのrの発音を無理やり表記するとウォァに近くこれを縮めてワーにしてるだけ
warningもウォーニングよりもゥォアーニングやゥワーニングのほうが実際の発音に近い
ワープやワランティも同じで日本語カタカナ表記として定着してる
「ワープww バカじゃないのw ウォープだろwww」って書いてるやつ見たら痛いよね？ >>48
「いつでも簡単に分けられる」なんて言ってないですね
そう思ったのはお前ですね >>43みたいなバカって義務教育終えてないんじゃないの >>49
英語音痴が恥の上塗りで口から出任せ乙ｗｗｗ
warnの発音調べてみろよｗ
会社でそんな恥ずかしい低学歴芸披露して恥かかないようになｗ
You were warned(警告はした)ｗｗｗｗｗ
わーんｗｗｗわーんどｗｗｗｗわーにんぐｗｗｗｗｗハラ痛いｗｗｗｗｗｗ ワープ
https://ja.m.wikipedia.org/wiki/%E3%83%AF%E3%83%BC%E3%83%97
英語の発音としては、「戦争」の「ウォー」と同じで、カタカナでは「ウォープ」とするのが近いが、日本の初期のSFで「ワープ」と書かれたうえ、『宇宙戦艦ヤマト』で一般にも広く「ワープ」で定着した。
ウォーニング
https://ja.m.wikipedia.org/wiki/%E3%82%A6%E3%82%A9%E3%83%BC%E3%83%8B%E3%83%B3%E3%82%B0
ウィキメディアの曖昧さ回避ページ
ウォーニング（英語: warning、英語発音: ['wɔːɹnɪŋ] ）
・警告、警戒
・警報
・訓戒、戒め
・ウォーニング (曲) - グリーン・デイの2000年のシングル曲。
・ウォーニング (アルバム) - グリーン・デイの6thアルバム。
・ウォーニング (競走馬) - イギリスの競走馬。
・WARNING (いしだ壱成の曲) - いしだ壱成の1994年のシングル曲。
・WARNING (アルバム) - mochAのアルバム。
ワーニング
https://mevius.5ch.net/test/read.cgi/tech/1596010678/42
英語の発音としては、「戦争」の「ウォー」と同じで、カタカナでは「ウォーニング」とするのが近いが、日本の低学歴のレスで「ワーニング」と書かれたうえ、恥の上塗りで『warのrの発音を無理やり表記するとウォァに近くこれを縮めてワーにしてるだけ
warningもウォーニングよりもゥォアーニングやゥワーニングのほうが実際の発音に近い』と発音記号も読めない低脳を晒し、同調した低学歴に広く「ワーニング」で定着した。 ビニールテープは間違い
バイニルテープ、バイニル袋が正しい >>55
カタカナ英語にこだわるのは自分が発音できない裏返し
カタカナに頼ってたらwalking(ウォーキング)とwarning(ウォーニング)のウォーを使い分けられないよ
学歴コンプこじらせるのもほどほどにね カプセル化はいいとして
なんでもかんでもセッターゲッター作るバカの方が痛いわ セッターとゲッターは存在自体がカプセル化を否定してるよな
カプセルに閉じ込めて入口と出口をイベントに絞ったんじゃねーのかよと
オブジェクト指向の目指すものがよくわからない
はじめの思想はともかく矛盾を承知で次の形態へ変化したと言うならそれでもいいとは思うけどね
ただ、言語作ってる奴さ
どんな設計書からどんなソースを作成したいのか？またそれをどうやってテストするのか？そろそろシームレスに真面目に考えるときじゃね？
最近追加で増える機能に思想を感じない
控えめに言って俺よりバカが便所で思い付いたようなアイデアを検証も無しに追加してる気がする カプセル化はデータと処理を分離させないためのものなのに、昔の説明をいまだに信じ込んで、データの参照もメソッド経由でないとカプセル化になっていないと言う30代、40代がいる。オラクル社のJavaの資格でも取り直した方がいい。一部は考え方が誤っていたから、いまは変な理想や思想は教えていない。むしろ、いまでは失敗だったとして否定されている部分も多い。 不具合が起こる根本的な要因を理解していないとカプセル化の効果を得る事は出来ないと思う
解らない人はゲッターセッターを使ってやるほうが有る意味おかしくならないからそれはそれで良いと思う
効果が有るようにオブジェクト指向でプログラムするのは難しいから
中途半端にカプセルかするより従来みたいにしているほうが良い
解らない人は無理せずに行制御basicでもやったほうが良いかも
そんな感じ まあ、設計的にはイベントというかメッセージ以外のアクセスを許さないためのカプセル化だろ？
セッターとかゲッターで横紙破りしちゃったらカプセルにならねーじゃん
だからセッターとかゲッター、プロパティまたそれを宛てにした機能全般は初期の思想からは大分ズレてんなと思う
カプセルなってねぇじゃんと
俺自体はpublic、staticメソッドのみが正義なのでカプセル化なんてどうでもいいし意識することもないけど カプセルはまとめるという意味だったのに、中に閉じ飲めるという意味だと誤解したんだよね。 > セッターとかゲッターで横紙破りしちゃったらカプセルにならねーじゃん
ならねーとまでではないんだろうし
実際教科書ではむしろカプセル化のためにアクセッサ書かせるくらいなんじゃないのかな
でもね、そのアナタの感性はすごくいいと思う
俺もアクセッサ前提の設計はまちがってると思う
カプセル化として間違ってるというより
インタフェースとして型を決めていくのが前提で
内部の実装に引きずられてアクセッサつくっちゃうのは
ホンマまじで脳腐ってると思う まあ、思想的にはそうではあるけど
機能的に書かねぇとそもそも実装できないようなのあるから
ここ今更主張してもしょうがないんだけどね
でも、方向としておかしいのはおかしいのだと思う >>57
warn
[wˈɔɚn] (米国英語)
[wˈɔːn] (英国英語)
war
[wˈɔɚ] (米国英語)
[wˈɔː] (英国英語)
同じ発音 [ɔ] なのにwarnではア、warではオと使い分けてしまう低学歴ｗｗｗ >>60
> セッターとゲッターは存在自体がカプセル化を否定してるよな
> カプセルに閉じ込めて入口と出口をイベントに絞ったんじゃねーのかよと
お前が、すべてのprivateフィールドにセッターとゲッターを作り、
そのセッターとゲッターにははただ値を転送するだけにしてるってのはわかった
お前が間違ってる >>64
セッターとゲッターは必要なものだけ作るんだよ？
ちょっと頭悪すぎないかｗ >>71
あ、いや、そもそも汎用的な出入り口を作っちゃ駄目っしょ
って話
だからどのプロパティがじゃなくて
イベントに対して引数からアクセスさせる以外の方法はそもそもカプセル化じゃないよねってだけ
別に原理主義者出ないのでそれで回らなくなったんじゃない？ってならそれも時代の流れだと思うよ俺は 医者が出すのは処方箋
薬💊の調合は薬剤師
患者は中身を弄る必要無いってだけ >>72
> イベントに対して引数からアクセスさせる以外の方法はそもそもカプセル化じゃないよねってだけ
どういう理屈？ｗ
引数があるメソッドはすべてカプセル化じゃないって言ってるの？
引数があるメソッドは、セッターとゲッターだけじゃないよ クラスの中のすべてのprivateフィールドは間接的に値を代入することが出来る
setFoo(int foo) {
_foo=foo;
}
というセッターはカプセル化じゃないというのなら
setFooBar(int foo, int bar) {
_foo=foo;
_bar=bar;
}
というメソッドであればカプセル化になってるとでも言うつもりだろうか？
それとも名前が行けないとでも言うつもりだろうかね
initialize(int foo, int bar) {
_foo=foo;
_bar=bar;
}
これならOKとか？ｗ
カプセル化の本質がわかってないから、セッターとゲッター（だけ）に問題があると思ってしまっている。
「問題」はそこではなく、その「問題」の影響がなければセッターやゲッターがだめな理由はない >>74
え？ちょっとお前頭悪いから話したくないわｗ >>72のように
メソッド単位で「このメソッドはカプセル化じゃない」というような
言い方をしている人はカプセル化を理解してない
カプセル化はオブジェクト単位で考えるもの
何か（薬など）を包んでいる入れ物がカプセルなのであって
入れ物に出し入れする穴がカプセルなのではない カプセルにどれだけ穴（メソッド）が空いていようが、カプセルの意味がある
メソッド経由でしかアクセスできないことが保証されているからだ 全面穴だらけのカプセルならもうそれ粉薬で良いんちゃうw 値の参照についてはメソッドでの値の取得にはしないともう結論は出ていて、いまは不毛なメソッドは作らない。 >>80
はい。そういうことなんですがなにか？
「全面穴だらけ」
これこそがカプセル化の否定の条件だろ
間違い ゲッターセッターがある（穴がある） 故にカプセルじゃない
正しい 全面穴だらけ。故にカプセルじゃない
「アクセスしてはいけないもの」に「アクセスできる」なら
それはカプセル化を破壊していることになる。条件はこの2つでしかない。
この2つの条件を両方同時に満たしていないならカプセル化の破壊にはならない
ゲッターセッター関係ないんですよ どんな値でも代入していいし取得してもいいのに
それをpublicにしたらカプセル化破壊とか
ゲッターセッターを作ったらカプセル化破壊とか
ちゃんちゃらおかしいわけですよ
インターフェースの定義が「どんな値でも代入していいし取得してもいい」なんだから
どんな値でも代入していいし取得してもいいんです。 初期化の時点で定数扱いするとか、stateパターンみたいなことやるとか、
今時はセッター用意しない方向だわな。
テスト作成がめんどい時はセッターもありだと思ってるけど。 参照渡しで配列の中身が勝手に書き換えられるのも
気持ち悪いと言えば気持ち悪い
カプセル化ではあるけれども こういう認識の齟齬を生みやすいこと自体が
オブジェクト指向の欠陥
まず分かりにくい思想があって
その思想の解釈が人によってバラバラで
コードで表現すると思想と辻褄が合わない部分が出てきて
その辻褄の帳尻を合わせるためにコーディング仕様追加して
コードがやたら汚くなっていく
そしてそもそもの思想を何も知らない初心者が
帳尻合わせの部分だけを真似して覚える
なんのためなのかも分からずに
じゃそもそもそんな思想要らなかったよね。
って言いたくなってくる。 じゃあOOPを捨てて何使ったらいいの？
もしくは、OOPを排除した人は具体的にどんな言語で書いてるの？ >>89
OOPで作られたライブラリをインストールして使うが
自分たちはOOPでコードを書かない
基本自作のコードは使い捨てるものとして
資産になるなんて考えは捨てる
構造化と純粋な関数型プログラミングの
考えに徹する >>90
素人が手を出したら
OOPの恩恵に預かるよりもむしろ糞の山を量産するからね
これは素人が悪いとか
あるいは誰かの力量を疑うようなことを言いたいんじゃなくて
クラス設計インタフェース設計の根本的な難しさを問題にしてる >>86
エラーハンドリングが必要だから現実のコードだと影響与えるような気がしないでもない
それは良いとしてこのコードを見るとJavaって大変だなぁって感じる
構造体がない
0~255を表現できる標準の型がない
オプショナルパラメータがない
オブジェクト指向への不満度の高さと使ってる主な言語には相関関係ありそう 現実問題としてオブジェクト指向は避けられない
ライブラリがオブジェクト指向前提なってるから…
数十個のメソッド継承したデブっちょクラスを前に
わけわかんねーってなる（←ポンコツですみません） >>94
ぶっちゃけ使うのはいいがお前は作るな！が言いたいことだよ。 このメソッドはこのクラスから継承と
書き出してみればわかると思うよ
たくさんのライブラリがあって
どのライブラリのどの関数を使うというのと
本質的に同じ問題だから >>88
んなの、オブジェクト指向以前の問題だろ。 staticおじさんを全面肯定するわけではないが擁護するわ
インスタンスを生成するタイプのクラスは
本当はかなり作るのが難しくて
高度な設計技術と計画性を要すると思う
そういう意味ではstaticおじさんは自分の力量を弁えていて
賢明だと思う
インスタンスを作るタイプのクラスをそうそう
乱発製造すべきではないと思う >>103
自分の力量？
同僚の力量も考慮に入れろよ オブジェクト指向の考え
オブジェクト内に状態(フィールド)を持ったり
オブジェクト内の状態を内部で操作するような
処理は外部から勝手に操作されると
不具合の元だから隠蔽しないといけない
(でも操作したくなることもあるから
ゲッターやセッターを作る)
しかし、オブジェクト指向の一番の問題点は
隠蔽さえすれば、状態をもつたり、
内部状態を操作する行為自体は許容してるという点。
staticおじさんや純粋関数型プログラミングの考え方
そもそもオブジェクト内に状態を持つこと、
内部状態を操作すること自体がシステムがめんどくさくなったり
不具合の原因なんだから、そんなこと自体極力やめた
方がいい。という考え方。
クラスにやたらめったらフィールドを定義するから
それらの管理が大変になるんでしょ？
じゃあそもそも不必要にフィールドをたくさん定義するのは
やめようってこと。 >>105
結局グローバル変数の弊害と変わらないってわけだ
イベント駆動プログラムにはオブジェクト指向が向くとされてるから
現在主流の言語はほぼオブジェクト指向になってしまった
オブジェクト指向を避けてイベント駆動を実現できればなあ… >>103
static変数を使わないつくりにすることがstatic変数使う場合に比べて難しいというのは
あんまり納得しないがな。
確かに既存コードがどこで変更が起こってるのか全く分からん場合には仕方ない時もあるが。
>>108
同じようなところもあるがさすがに数百万行のコードになってくると、グローバルとメンバ変数じゃ
負担はだいぶ違うよ。 staticなら何の問題も起きないのにバカがメンバに持つ カプセル化が不十分というだけ。
XNA は使い方を間違えている。 そもそも処理を仕方がない理由もなく
入力→処理→出力
で入力と出力でチェックできない形にしてしまうのは悪手 >>109
static変数なんてものももちろん使わない
staticおじさんへの批判が的外れになるのもこれが原因
「staticメソッドしか定義しない」 そもそもJavaScriptや
python使ってると
「あれ？クラスって必要なくね？」
って思うことが多いよ
(クラスというかフィールドやコンストラクタや
インスタンス化の必要性)
複数種のデータをセットで持ちたいなら
連想配列や辞書で持てばいい話で
クラス型なんて無名で言いじゃん。
JSONやローカルストレージやDBなど
格納方法には色々選択肢があるわけで
連想配列を引数に与えてやりとりすればいい
もちろんJavaだとMapのキーと値にも
型の宣言が必要で不便だから
JavaScriptやPyを使ったほうがいいね Hooks API来てから皆Function Component。誰もClass Componentつかわなくなった@React privateとかpublicじゃなくて775とかパーミッション設定したい。 >>114
もともとの議論知らんのならだまってりゃいいのに。
あきらかに元ネタはstatic変数を使ってシングルトンやることをマンセーしとるわ。
クラス使えばいいってもんじゃないが、結合時のバグを気にしすぎてテストしずらい構造つくってるってのが
この手の問題なわけよ。 別に論破はされてないなぁ
要するにデータをどう持つかの話で
データが必要なものはオブジェクトに持たせたほうがいいし
データが必要ない（引数程度）ならstaticにすると言うだけの話
この「引数」はシンプルな値型に限る。
いやだってstaticにするために引数にしてデータを持たないオブジェクトにしたのに
データを持つオブジェクトを渡すとか本末転倒やろ？ｗ
ようはデータが有るかどうかって話で、ないならstaticでいいけど
あるなら普通にオブジェクトにしましょうってだけ
データが有るのに頑張ってstaticにするとか無駄 ケースバイケース、適材適所で設計すれば良いというだけの話なのにね。
教条主義、原理主義の奴らは必ず◯◯すべし！◯◯すべからず！と声高に叫んでるだけでまともな議論にはならないし、スルーするのが一番かと思われる。 >>123
お前が言ってるのはjavaのstaticの方な。
もともとのstaticおじさんはcの話をしてる。 >>125
staticおじさんはjavaのstaticな >>119
chmodとかで設定するパーミッションな。
↓こんなイメージ。
664： // 基底クラスと派生クラスが読み書き可能。その他はよむことだけＯＫ。
int a;
640： // 基底クラス読み書き可能。派生クラス読み込み可能。その他はアクセス不能。
int b; >>127
純粋関数は並列性が高い。
GPUシェーダーとかもろに純粋関数だし。 そもそもフィールドで持つ必要がある
データってこのブログで紹介されてるような
キャラHP,MPや貯水量、現金残高
みたいな上下限をもった数値の増減みたいな
ものだけだと思う。
境界値バグに関係しうるパラメータね。
こればっかりはstaticおじさんはやりにくいと思うわ。
カプセル化とはなにか？超わかりやすく解説します！
https://jpazamu.com/encapsulation/
あと考えられるのは 装備品みたいな
魔法使いジョブには剣を装備させてはいけないなど
特有の細かなルールがあるときはカプセル化が必要か。
それ以外の人名とかIDとかメモリ内で変動しないような値を
わざわざフィールドを用意する必要もなければ
privateで保護する必要もないしstaticおじさんで
なんの問題もないよね。
基本的に「演算」がないデータだから
連想配列やJSONでまとめてやり取りすればいいと思う。
あとバグを引き起こすのは値の変更で
あって参照って無害なのでは？ バカじゃね
最近のソシャゲなんて全部DBのテーブルに入れなきゃいけないのにクラスの階層構造なんてテーブルに格納するときやりにくくて死ぬだろ >>135
バカじゃね
最近のソシャゲなんてRDB使う方がレアなのにテーブルに格納する前提でコード書いてたらやりにくくて死ぬだろw その界隈はスケールアウト重視でRDBよりさらにフラットなのが主流だからな。
それこそ学校で教えるデータベース正規化の真逆、「逆正規化こそ正義」という世界だし。
「正規化は愚かな考え」というスレを立てようぜ 最近気が付いたんだけど。
STLならどうなるか？と考えるのも、一つの分析手法だな。 カプセル化が悪いんじゃなくて設計ミスってるだけじゃん
経験積んで未来予知の精度上げるしかないかな あとgetter、setterてカプセル化の思想とは関係なく、
便宜上の何かしらの理由(フレームワーク都合、トレースしやすい)で
慣用的に使われてるイメージある その未来予知や
設計ミスで後悔する要素とか
フレームワーク依存要素を排除したいから
純粋関数型で余計な状態を持たずに
機械的にプログラミングする方が
いいと言ってるじゃないか。 > 純粋関数型で余計な状態を持たずに
> 機械的にプログラミングする方が
> いいと言ってるじゃないか。
↑間違い
状態を持たないものは
純粋関数型で簡単に作れるが
世の中には状態を持っているものがたくさんある
純粋関数型は状態を持たないものは簡単に作れるが
状態を持つものは簡単に作れない
状態を排除することは不可能なので
結局状態を持つものを管理しやすい
オブジェクト指向を併用することになる 状態を多用する場面で純粋関数型は向かないってことかな？ 純粋関数型言語を使えば状態を持たなくて良くなるわけじゃないんだよ
状態があるのとないのであれば、状態がない場合は
テストも簡単でシンプルに作れることが出来るだろう
しかし実際のシステムは状態があるんだよ
状態がないもの（つまり簡単なもの）を簡単に作れることを目指しても有り難みがない
状態があるもの（複雑なもの）を簡単に作れるもののほうがありがたい 関数型言語のエッセンス（イミュータビリティ）を部分的に取り入れると
いい感じだけど全部置き換えたら破綻するね 状態を持つ必要が有るとしても
極力少なめに厳選すべき
データベースのカラムは
全部オブジェクトのフィールドとして保持して
コンストラクタ経由で引数をフィールドに移し替えて
全部ゲッターセッター用意して
見ればわかるメソッドに全部Javadoc記述して
とかどう考えても馬鹿でしょ
personオブジェクトの
人名、年齢、身長、体重
とかがプログラムが動いてる短い期間に目まぐるしく
変動するんですか？
オブジェクト指向の教科書見るとそうやって教えてるんだぜ？ >>147
別に破綻しないよ
状態が必要なら、状態ごと受け取って状態を含めた出力をするような関数を作る
データとそれを使う関数を1つの単位(クラス)にまとめたほうがいいのか
それともデータはデータ、関数は関数で分けて管理したほうがいいのかという違い
(関数型でも必要ならある種のデータ型とそれに密接に関係する関数群をモジュールとしてまとめる)
どちらかが常にいいというわけじゃなくトレードオフだから
それを理解してドメインに応じて使い分ければいい > 状態が必要なら、状態ごと受け取って状態を含めた出力をするような関数を作る
んで、その最終形態が
メモリの内容を全部渡して、書き換え済みのメモリを返す
それを永続化する。
つまりはグローバル変数と同じ状態になるわけだ 結局書き方の違いでしか無いんだよね
状態 = 関数（状態）にするか
状態.関数() にするかという書き方が違うだけ そして行き着く先は
状態 = 関数（状態）の形で
大規模なものを人間が統治管理できるのか？って話
人間がってのが重要な所
理論的には出来る。コンピュータにも出来る。
だが人間がそれをやれなきゃ意味がない
簡単な足し算でも、それが何万個もあれば人間はミスをする >>150
プログラミングモデルの話だからそういうのは関係ないんよね
言語が保証してくれるレイヤーから上でプログラムをどういうスタイルで書くかという話だから
>>144の最初の例ならCounterが状態
incはCounterとIntを受け取ってCounterを返す関数
inc :: Counter -> Int -> Counter
inc (MkCounter c) n = MkCounter (c + n) >>152
>状態 = 関数（状態）の形で
>大規模なものを人間が統治管理できるのか？って話
オブジェクト指向のコア概念メッセージングがなぜ提唱されたか察するに
このあたり関係ありそう 昔のC言語は状態なんか持たなくても動いてたよｗ
前提が間違ってるじゃん >ソースコードが存在し改修が可能であればカプセル化しても問題ない。
>ソースコードがあってもライセンス的に改修できない場合や、そもそもバイナリのライブラリしかない場合などは絶望的である。
ライブラリが担うべき要件でもないし他の探すか自分で作るか改修依頼するかしかないでしょ
なんでカプセル化が悪の権化みたいなことになってんのｗ 純粋でなければ、利点として宣伝されるものの多くが実現されなくなるからな。
もっとも、純粋であっても、現時点では実現されていないのだが。 その状態の管理方法がオブジェクト指向でも純粋関数型でもないだけで >>140
getter/setterはJavaBeansの仕様だからね
JavaBeansはGUIツールでポトペタで操作できるようにするためのもの
GUIのツールでプロパティ書き換えたりイベントリスナー書いたりするのが目的
だからJavaBeansの情報を取得するBeanInfoにはgetIconメソッドがあったりする
JavaBeansではプロパティに値をセットしたら値が変更されましたイベントを発火したりするから
getter/setter経由でアクセスすることは理に適っていた
それがいつの間にかオブジェクト指向のプログラムではgetter/setterを書くんだーになってしまった
JavaBeansのようなコンポネントの作法はライブラリ内部で使われるようなオブジェクトには必要ない
デスクトップアプリの開発が衰退したおかげかいまはだいぶその認識が広まってる 単にそのクラスに必要な操作のみ公開するという思想は良いと思うが
頭の硬いやつがいると理解出来ないからか文句を言ってくる >>162
結局入力と出力を
メンバ変数に入力や出力を内包されると単純に動作が把握し難いだけで
全くメリットがない
内包されたデータを見ないで修正してもいいのか？
お前の会社はそれでいいとは言わないだろう
だとしたら入力や出力を隠蔽するのは誰にとっても迷惑にしかならない そのクラスの責務（入力に対する出力の仕様）がわかっていれば
具体的な内部の動きを把握する必要がそもそもない
把握する必要ないから楽 >>163
システムの規模が大きくなった時
どう管理するかって話だからその理屈は全く関係ないんだよな
内包されたデータを見ないで修正してもいいか？
オブジェクト指向であれば、それがある単位で分割されているから
そこだけを見ればいい >>164
お前が作ったクラスの動作がおかしいときどうすればいいの？
中身みんでええの？ >>165
お前が作ったクラスの動作がおかしいときどうすればいいの？ >>166
お前が作った関数の動作がおかしいときどうすればいいの？
中身みんでええの？
どちらも中身を見るなら
管理しやすいオブジェクト指向の方が良い 適切な単位で分割されてると修正も楽
それこそ「そのクラスの責務（入力に対する出力の仕様）」だけ
満たすことを考えればいい 内部で関係する変数とかを閉じててくれないと
そのクラスに値を設定する部分を見て回らないといけなくなる クラスに値を設定する部分は、そのクラスを見るだけでいい
引数として独立していると、その引数を使ってる部分を全部調べなければいけなくなる
戻り値が変わると、その戻り値を使ってる部分全てだ >>170
中身を見るとどうやらメンバ変数statesの値がnoneにならないとメソッドの処理が最後まで流れない処理になってるみたいなんだけど
こういうときどうしたらいいの？ メンバ変数statesがprivateだったらそのクラス内に閉じた問題だから
単純にそのクラスのメソッド内でstatesとnoneを比較するようなとこを
洗い出せばいいんじゃないの？ >>170
その責務って奴が言葉だけは聞こえがいいが
現実論として関わるプログラマや関係者の間で
認識がバラバラになる最大のポイントなんだわ。
プログラムやコンピュータを計算機として見てないんだわ。
「この処理を果たしてこの場所で書いていいものか…」
なんて余計な事で頭を悩ます最大の原因なんだわ。
それよりももっとシンプルに、
任意の場所に、受け取った引数を使って
結果を返す関数を作って関数に要求させた演算を
投げて結果だけ受け取った方が生産的だよね？
関数を連鎖的に組み合わせればどんな複雑な演算も
成し遂げることが出来る。 それはチーム編成とか統制の問題では
レベルが低い集団だと統制とれずク○の山が積み上がって
収集つかなくなるんだろうな >>175
privateメンバ変数は見なくていいって話じゃなかったん？ クラス外からは気にしなくていいけどクラスを修正するときは見なきゃだめでしょ
privateなら見るべき範囲はクラス内って絞ることができる まあ理解できもしないのに真似事みたいなことするのが一番迷惑だから
やりたいようにやりなさい そもそも>>173の質問がバカ丸出しなのに自覚ないとか >>161
プロパティって、どういうプロパティが存在するかを実行時にインスペクトできるというのも重要な性質だな。
BeansはJavaのリフレクションでそれを実現していたけど、単なるgette/setterではそういうのも忘れられている。 >>179
さらにpublic staticならグローバル変数不使用なら引数と戻り値（入力と出力）の確認だけじゃん
絶対こっちのがクラスより優秀だろ >>176
それって、ちゃんと考えて設計するの面倒だから全部グローバル変数でやります、生産性高いよね！といってるのと変わらないじゃないかw >>186
比較するものがグローバル変数使用のソースしか無くなった？ >>185
> さらにpublic staticならグローバル変数不使用なら
どうせその前提だとそれはクラス内部に状態を持つ必要ない単なるUtilityクラス
内のメソッドだろ？
状態をどうやって管理するかの話だったのに、状態を排除した前提を持ち出してきて
何を認めさせたいの？反論することだけが目的？ >>188
だからグローバル変数不使用のc言語と同じでいいよ
っていうかこれで完璧なんだよ 御託はいいからお前の書いたコード見てみたいわ
グローバル変数を使わないCコードが書けるんだろ？（失笑）
C言語ならグローバル変数はある程度使うべきなんだけどね >>190
普通に書きゃいいじゃんｗ
作れないものがあったと思ってるの？ｗバカ？ｗ 下手なりにかけるとは思うよ下手なりに
ただその方法じゃスケールしない
ここまで言ってわからないならもう相手にしてあげないよ Information Hidingの意味でカプセル化と言ってるやつと
データとメソッドをオブジェクトという構造にひとまとめにすることをカプセル化と言ってるやつがいるから
話が噛み合ってない
前者はオブジェクト指向に関係なくあらゆるプログラミングスタイルで使われてる
規模に関係して重要になってくるのはInformation Hidingの意味でのカプセル化
CでもHaskellでもそれが重要なのは変わらない
後者はオブジェクト指向特有のもの
これはソフトウェアの規模の大小とは関係なく
どういう方向の変化に対して高い柔軟性を確保しておくのがいいかという問題なので
デメリットも考慮しつつ状況に合わせて採用するかどうか判断すべきもの Ha0cLvqC ← こいつに関しては
・情報隠蔽
・関心事の局所化
いずれの意味も明らかに理解できていないし、日本語も通じてないから話が噛み合わない お前らのコミュニケーション能力が劣ってるだけだろ
良い大人なんだからきちんと伝わる語彙と文法、論理を示せばわかりあえる
コミュ障のお前らに俺が手本を見せてやるよ >>191
>>193
ちんちんが痒いときってキンカン塗っとけば良いですよね？ >>200
まあ、この世のどのサイトも説明できてないから気にするなよｗ
ってアレ？ということはメリットない技術なんじゃない？ｗ 技術的な関心があってこんなスレ開いてるんだろ？
にしては程度が低すぎる お前が今まで信じてきたものやってきたことって意味あったの？ >>203
お前の方が顕著だろ
じゃあ、お前と主張が同じサイト持ってきてメリット説明してみろよｗ オブジェクト指向の理解にすら躓いてるやつと話しても時間の無駄だから >>205
ああ、そう？ｗ
メリットを解説できてるサイトないけどなｗ >>206
メリットを解説してるけど、解説になってないというサイトを言える？
お前が一番まともだと思うやつね。全てまともじゃないというのなら其の中でいちばん有名なやつ
それをお前が言えるのであれば、俺らはそれがちゃんとした解説になってることを証明するのは簡単だろう >>208
いいや、ゴミクズ過ぎて違いなんかわからん
オブジェクト指向が役に立つって書いてあるだけで俺にとっては全く役にたたんサイトなわけだし もう「お前はオブジェクト指向理解してない」
に結論づけるのやめにしようや。
かならずそこに収束するやん。
理解してない奴が悪いんじゃなくて
理解し難い概念であるオブジェクト指向が悪い
っていう発想の転換してんだよ だいたい言ってることキチガイじゃん
オブジェクトの中身は隠蔽されてるから気にしなくていいって言った口で
修正するときはprivateのメンバ変数使用箇所全部確認して直せって言ってるんだぜ
なんのために誰に隠蔽してたんだよｗ
完全に無意味じゃんｗｗｗ
こんなくだらないことやってるんだったら、public staticにするべきだぜ いや、一クラス一メソッドの原則に基づいて設計すればじゅうぶん可能。 >>209
そういう言い訳をしたからお前の説得力ゼロになったな
結局何も知らなずにろくなサイトも見ずに
ダメダメ言ってるだけだろ？
言い返したいなら、ちゃんと解説してるサイトの一つでも上げてみろって >>211
> オブジェクトの中身は隠蔽されてるから気にしなくていいって言った口で
それは使う場合の話。つまり開発（担当）者とは別の人は気にしなくていい
> 修正するときはprivateのメンバ変数使用箇所全部確認して直せって言ってるんだぜ
それは開発（担当）者の話
この区別ぐらい基本だろ >>214
じゃあ、開発者しか触らない環境でクラスなんて作るのは無駄ってことでおｋ？
お前、完全にそう言っちゃってるよな？
それでええの？ >>215
お前バカなのか？
例え自分が開発したとしても、それを使うだけの場合と開発する場合は違うだろ
苦労して頑張ってライブラリを作りました。
そのライブラリを使うときに、ライブラリのソースコードの中身を見ないと使い方がわかりません
ってそれ、作り方しっぱいしてるじゃん
お前はいちいち中身を見てるんだろうけどな >>213
ハイハイ、オブジェクト指向にメリットが全く無いのはメリットを感じ取れないやつがバカなんだよなｗ
誰も証明できないけどなｗ
バーカ、一生やってろｗ そのライブラリ使ってるブログ検索して
真似するだけなんだよなぁ…
隠蔽要らんやん >>219
隠蔽っていうのはな、コードとデータの両方の話なんだよ
ライブラリにすれば中身を見なくてすむようになるんだよ
知ってるか？ 頑張ってクイックソートライブラリを作ったおっさんは
これでもうソートするときに中身をいちいち見なくてすむ
って安堵してるわけだ >>220
でも修正するとき見ないと駄目なんだろｗ
つまり作る側と使う側が完全に別れてないときにクラスなんか無意味なんじゃない？ >>222
オブジェクト指向
修正しない時・・・見ない（メリット）
修正する時・・・見る
関数型言語
修正しない時・・・見る（デメリット）
修正する時・・・見る
理解できますか？ >>195
そうそう。
カプセル化っていってんだから、オブジェクト指向は関係ない。
Cの構造体でメンバを公開したり非公開にしたりできまっせ。っていうだけのこと。
それを愚かというなら、その程度の規模のプログラムしか作ったことないんだろうね。 >>222
君って情報学部の学生さんなんか？
それとも、どっかの会社でプログラマーの卵として頑張ってるのか？
プログラミングの素養が絶望的にないから、他の道で頑張ったほうがいいよ。 >>223
は？意味不明
なんの説明してんの？
恥の上塗りの達人かよ >>226
理解できないのか？
お前が○○の時に限っては見るんだから意味ないっていうから
○○の時だけ見るというのはメリットだって言ってるんだが >>225
年収1000万超えのカリスマプログラマー（笑）さんですか？ > でも修正するとき見ないと駄目なんだろｗ
でも風呂に入るとき脱がないと駄目なんだろｗ
じゃあ服着る意味がないじゃない
といっているのがお前 >>227
「見る」の一人称が机に座ってモニターを眺めてる>>226なんだよ。
こんなのが新卒として入ってきたら、速攻で人事に掛け合ってクビにさせる。 >>227
は？だってメンバ変数ってクラス内限定のグローバル変数だぜ
このときのお前のメソッドは俺の作るpublic staticなメソッドより遥かに
不出来で読みにくい
どこでいきなり編集されるかわからないメンバ変数に気を配りながら
メソッドを読むのはぶっちゃけ苦痛でしかない >>229
たとえ話が適切であることを証明してからしろよそういうのは > メンバ変数がクラス内限定のグローバル変数
その通りなんだが、声を出して笑ったわ。
君と働く人たちは大変だなw >>232
> は？だってメンバ変数ってクラス内限定のグローバル変数だぜ
お前の場合、ローカル変数は関数内限定のグローバル変数って言うだろｗ 条件付きで何かを主張し始めたら、
それはもう主張が破綻してるってことなんですよ。
Macユーザー限定だとMacのシェア100%だ！みたいにね >>234-235
俺の作るpublic staticのが遥かに厳密に管理されてて
お前らのはしっかりやってるようでいて
わりかしドンブリだってわかっただろ？
俺はオブジェクト指向のここが特に嫌でメンバ変数がグローバル変数的な問題を起こすところが
クラスが大きくなったときに本当に嫌
つまり俺が嫌いなのはグローバル変数的な動きをするメンバ変数なんだよ
クラスでもちゃんと引数通してアクセスするような造りにしてるときは別にいいぜ
ただそれやるならpublic staticのがいいしやっぱりバカだね > わりかしドンブリだってわかっただろ？
なにか証明した？
それがわかるというレスを（明示できるなら）やってみてよｗ >>237
関数内ローカル変数が、グローバル変数だっていうのなら
関数を小さく保てばいいだけでは？ｗ
あ、クラスの話でしたっけ？
同じですがね >>238
だってpublic static でグローバル変数無しなら
入力に対する出力が絶対一定だぜ
これ以上の安心感ってあるの？ まあ、デバイス絡むとそいつの状態次第だけど
そこに限定できるじゃん？ >>240
引数が大量になるじゃんｗ
クラスの中にある変数を全部引数で渡すとしたら
何十個にもなるからな
それとも構造体で渡すのか？
そうすると構造体のうちどこを弄るかわからないから
結局グローバル変数と変わらなくなるなｗ たしかにベテランになるにつれ、パブリックスタティック関数でやりきる方がすっきりするかもしれん
整理の上手さで
利点はソースがシンプルで早く作れるのと、可読性が良い
ただし整理が上手い場合
もっとも、整理が下手ならクラスもうじゃーっとなるｗ
無駄にやたらオーバーロードしてたり いやオーバーロードはパブリックスタティックでもできるか >>243
もともと小さいプログラムならどっちでやってもすっきり書ける
問題はある程度大きくなると状態とかを取り回す必要が生じてその場合は
毎回staticな関数を呼ぶときにそれらを引数として渡さなきゃいけない
そこまで想像して発言してるか？ 小さいプログラムに対してはオブジェクト指向なんて記述が大げさすぎるのは事実だ
でもプログラムが大きくなってくるとその恩恵に預かれる 例えばボタンを描画する関数があったとする
そのスタイルとはボタンの色、サイズ、座標
面倒くさいからリンクを貼るけど
https://docs.microsoft.com/ja-jp/dotnet/api/system.windows.forms.button?view=netcore-3.1
AccessibilityObject, AccessibleDefaultActionDescription, AccessibleDescription, AccessibleName,
AccessibleRole, AllowDrop., Anchor, AutoEllipsis, AutoScrollOffset, AutoSize, AutoSizeMode,
BackColor, BackgroundImage, BackgroundImageLayout, ImageLayout, BindingContext,
Bottom, Bounds, CanEnableIme, CanFocus, CanRaiseEvents, CanSelect, Capture,
CausesValidation, ClientRectangle, ClientSize, CompanyName, Container, ContainsFocus,
ContextMenu , ContextMenuStrip, Controls, Created, CreateParams, Cursor
飽きたがこれぐらい渡せばボタンが実現でっきるやろ >>242
どっちでもいいよ
そこで見た目にビビってやめちゃうのが一番の害
それだけ複雑な処理だから仕方ないんだよ
逆にそれだけのもんをグローバル変数で空中戦なんかするから手に負えなくなる
どんなにでかくなっても引数と戻り値に打ち込めや
逆にそこの検閲を徹底するから楽になるんや >>247
必要なら全部持っとけや
それらをグローバル変数で空中戦やられる地獄を味わうよりずっといい >メンバ変数ってクラス内限定のグローバル変数だぜ
最強の迷言 >>250
でもそうだろ？
俺のpublic staticグローバル変数無しのメソッドのが遥かにキッチリ作ってあるというわけ お前がコーディングしたプログラム貼れよ。
一つのメソッドで1000行とかそれ以上書いてそうなんだよな。 >>250
君は引数やローカル変数、戻り値の代わりにインスタンス変数使ってるプログラムを見たことがない幸せな人
オブジェクト指向こじらせたバカは想像を超えてくるぞ 要するにゴミのような想像を絶する現場で使われてる言語がJavaだった、と
すると袈裟が憎い理論も成り立つ
が、どんなパラダイムのどんな言語を使っても底辺ドカタはゴミを作り出す
とすると、一定水準以下の知能の物体は習得できない、面倒な言語を作った方がいい >>254
だからってその解決方法がグローバル変数じゃ駄目なわけよ
引数外してグローバル変数や突然取得できる何らかの手法例えばメンバ変数に逃げるのはやってはいけないこと
最低限にするのであって本来必要な引数までカットしていいわけではない >>257
処理を分けるかそれができなければ
その引数はそのメソッドに必要なものなので潔く引数にズラズラ並べる
こうすることで
引数を通した時点で型チェック
メソッドを呼び出した頭で値のチェックができ、適切なエラーが出せるし出しやすい
無くしてしまっては何にもわからない
呼び出した側はその変数がそのメソッドに使われているかどうかすらわからない
エラーを出してもそれが内包されてるメンバ変数では一体何が起こったのかさっぱりわからない >>258
俺はお前が何をやってるのかさっぱりわからないよw
結局のところ、お前はお前の言うやり方で、現実的に意味のある動作をするそれなりの規模のプログラムを書いたことはあるの？
実際のスケール感を無視して、頭の中の小さなサンプルだけをイメージしながら机上の空論を並べ立ててるだけでないの？
そりゃ自分に都合のいいモデルだけをイメージしてれば、サイキョーのカンペキな理論ができるわな >>258
メンバ変数は型チェックされるよ？
その型しか入らないからね >>258
> エラーを出してもそれが内包されてるメンバ変数では一体何が起こったのかさっぱりわからない
意味不。どの変数を参照してるかなんてコード見ればわかるだろ >>260
おもちゃを取り上げないでくれないかな？ｗ >>262
いきなりメソッドの中身を見る話になってんじゃん
見る必要ないんだろ？ｗ >>264
だから修正するときと使う時の話をごっちゃにするな
使うときはメソッドの中身なんか見ない 何度言っても理解できない。アホなのか？本当のアホなのか？ 引数で渡すと、この値なんなんですか？ってなる
「内部で使用するフラグです。」
初期化関数を呼んだら内部で必要なデータを返しますので
次呼ぶときに渡してください。
ファイルハンドルっていうんです。
みたいなね。
内部情報が一つだけならいいが
複数あったらどうするのか？
ファイルハンドルは内部に確保したメモリに
シーク位置を紐付けて保存してるんですよ
なんてことになるｗ >>247
ボタンごときに膨大なプロパティがあるのがおかしい
整理できてないｗ
さておき、実際にはほとんどデフォルトで使うから、「クラスなら面倒がない」と言いたいのかな
関数でも名前付き引数、あるいはコレクション渡しで未設定ならデフォルト、で省略できると思うが
まあコレクションはオブジェクト指向の基礎なので、これを使えば既にオブジェクト指向なんだろうけど
WinAPIもスタティック関数でオブジェクトを動かすので、スタティック関数は別にオブジェクト指向の対立概念ではないが >>267
内部で～はお前が出してるメッセージの問題だよね？ >>265
じゃあ、エラーもトレースも外に出すなよ
お前が作ったモノは、ただ、ただ、わけもわからず落ちろ >>268
> ボタンごときに膨大なプロパティがあるのがおかしい
現実見ろよ
お前が言う方法で、create_button関数作ってみ
ボタンの属性として、ボタンの値、無効ボタンかどうか、
位置x、y、z座標、文字の色、ボタンの色、枠のスタイル、
ボタンの余白、文字の右寄せ・左寄せ、フォント、
まだまだあるが、これぐらいでいいだろう？
ボタンを作ったらこれだけの属性が初期設定として
設定される
はい、引数で作ってみてください
あと将来の拡張性も考えてね。
増えるかもしれない >>272
構造体はグローバル変数やろ？
どこを書き換えるのかわからんのだから
それとも一つのクラスになってるから
それは一つの引数だ！っていうつもりか？
あ、間違った一つの構造体だったｗ 結局、引数で複数の情報を与えるのはずらずら何十個の並べれば
また可能だとしても、戻り値が一つしかないから現実的じゃないんだよね
クラスを使うのは、一つのメソッドで
複数のプロパティを操作することがあるからなわけ
例えばcreate_buttonだったら複数のプロパティを初期化する
戻り値で複数の値を返せないし、戻り値を構造体とかクラスにして返すとしたら
結局それはお前の言うクラス内のグローバル変数と同じになってしまう
引数の構造体（クラス）のうちどこを変更するかわからないからね 引数で渡すと将来の修正時の拡張性と互換性が犠牲になる
これはいい知見だ 変数のスコープと型の違いも区別できてないようだと
どういうやり方しても泥スパゲッティしか出来上がらない 関数型は否定してないよ
少数の引数と一つの戻り値だけで実現できることなら関数型でやればいい
それができないことまで無理してやろうとするのはデメリットしか無いという話
引数で渡せばメリットが有る、だから引数で渡すようにしよう！
これは間違いで
引数で渡せる場合は、関数型にメリットが有るが
そうでない場合にはむしろろデメリットになる
条件に応じて関数型にするかに分岐するのであって
関数型にするために条件を無理やり歪めてはいけないということ 構造体でまとめることによって引数で渡せるようになるのなら、そうした方が関数型的な考え方に親和的ということはない？
戻り値が引数以外に依存するのはできるだけ避けるというのが関数形的な発想かと思っていたが、 >>279
そうすると結局、クラス内のメンバ変数のどこがいじられるかわからないというのが
引数の構造体のどこがいじられるかわからないという問題に変わるだけで
関数型を使うメリットが無くなる
じゃあもうクラスでいいじゃんとなる
何度も言うように、関数型が優れてるから関数型に移行するのではなく
関数型が優れてる場合は限られてるので、そこだけ関数型にすればいい
関数型にメリットがないならオブジェクト指向にすればいい
その例が、ボタンの生成のように一つの関数で
複数のメンバ変数を初期化するような例 × 戻り値が引数以外に依存するのはできるだけ避ける
○ 戻り値が引数以外に依存するのが "避けられる場合に限って" 関数型を使いましょう 関数型を実践したこともないのに
知ったかして関数型関数型と連呼しちゃうのは
日本を出たこともなく日本のことしか知らないのに
欧米では～欧米では～と連呼してるのと同じ じゃあグローバル変数を使って大規模なプログラムを組み上げたことがない人はグローバル変数を批判してはいけないのか
実践せずともわかるだろうが、関数型も欧米も想像で十分 だから多数のプロパティを持つcreate_buttonを関数型で実装してほしい 1クラス1メソッドの原則なんて言葉はお前が考え出したものだろ？ｗ ボタン自体は状態を持つものだから、オブジェクト指向で実装するのが自然でしょ？（関数型でも抜け道があるのかもしれないが、自分は関数型には詳しくないのでわからない）
しかし、上でされていた議論はそういう話ではなくて、関数の戻り値が依存する情報を、①全て引数として与えることも、②一部はメンバ変数から引っ張ってくることもできるという状況の場合に、どちらを選択するかという問題設定だと思っていたんだが。 >>290
関数型の主張が「どんな場合でも引数で渡して戻り値で戻したほうがいい」だから
オブジェクト指向の主張は元から、内部にプロパティが多数ある場合の話をしてる グローバル変数未使用で関数のみを使って状態にも対処できる！
オブジェクト指向なんて選択肢はない！
と言い張る子の霊圧が消えた．．． >>252
ぉ？Javaディスってんのか？
>>290
> ボタン自体は状態を持つものだから、オブジェクト指向で実装するのが自然でしょ？
いや、別にオブジェクト指向で実装するのが自然っていうのは乱暴だろ。
ほんと、ソース貼れよ。引きこもりのアマグラマーがw もう死んでね？ｗ
ボタンを関数型で作れなかったんだから >>271
たしかC++ってそういうもんだがｗ
しかも同じく嫌いだよｗ
整理できてない
で、なんでクラスだとそれが楽になるのかね
＞さておき、実際にはほとんどデフォルトで使うから、「クラスなら面倒がない」と言いたいのかな
こういうことかね、て先回りして聞いてるんだが そんなにうじゃっとしてないか
https://bituse.info/winapi/5
//ボタンコントロール作成
hwnd_button=CreateWindowA("button","ボタン",WS_VISIBLE | WS_CHILD | BS_PUSHBUTTON,
50,50,100,100,hwnd,(HMENU)CHILD_ID,hInstance,NULL);
親ウィンドウの準備がイラっとするのかな そんなお膳立てされたAPI使っていいって誰が言った？ ちなみに多くの人が、「クラスオブジェクト指向な記述で」を「オブジェクト指向で」と言ってるようだね
スタティック関数で動かすオブジェクト指向もあるので（C++、WinAPI）
略すなら「クラスで」と言った方がいい（これも不正確だが） システムワイドでReduxのような仕組みを適用するのは無理だろうか？ 思うに、このスレに集まってる人らの
業務内容が違うんから議論がズレるんじゃないか？
Web系の場合メモリ上の
オブジェクトは一瞬で役目を終えるから
正直カプセル化とかいらない
node.jsやPHPでデータベースのへselect文投げると
連想配列オブジェクトの配列が帰ってくるから
つまりテーブルから動的にクラスののオブジェクトが
生成するから正直クラス定義もいらない
staticでなんの問題もないと思う。
状態管理は特有のセッションに保持するだろう。
でもゲーム系だとキャラのHPみたいなゲージ管理や
持ち物、装備品などいつまでもメモリ上に
居座って状態管理が必要だからオブジェクト指向
とカプセル化は大切。 うーん。
職業プログラマが5chで情報交換してたら、ちょっとひどすぎない？
俺は自分の職業の板なんて行かない。
見たことはもちろんあるけど、素人が玄人のフリしてうんちく述べてるだけで、俺らが何か書き込むことは無いと思うよ。
それとも職業プログラマってそんなに程度低い？
素人とうんちく語り合うほど？ プロが匿名掲示板で情報交換して得るものなんてないでしょ。
あったら怖いわｗ >>309
常駐プログラム云々いっちゃうと、GCが優れてる！いや、C++のデストラクタの方が！
とか、そういう話にもなっちゃうからオブジェクト指向云々は関係ないような。
優秀なCプログラマならCでもリークしないプログラム書くでしょ。
static云々言ってるバカは、オブジェクト指向でもリーク起こすと思うわ。 オブジェクトのライフサイクルとカプセル化がなんの関係あるんだ？ 素人が玄人のフリしてうんちく述べてるのがうざいから消えてほしいとは思ってる
でも中にはプロっぽい人も紛れてる いや、無いない。
素人が適当なこと書いてるから訂正するか？
無い無い。
レベルが違いすぎるのよ。
それとも何か？
プログラマという職業に限ってそんなにレベルが低いか？
素人と言い争うほどか？ 自分が素人って認めたんかpublic staticくん >>304
誰もWinAPIの話とは言ってないが、それボタンはウインドウハンドルを返すのよ
つまりクラスのメンバ変数に状態を持ってインスタンスのポインタを返してるのと同じ
オブジェクト指向なんだよね
こういうのって本質的に複数の状態を持ってるわけだから
関数型で作るの大変でしょ？ Windows自体がオブジェクト指向だから、関数型と相性悪いのかもしれないな。
もしかすると、それが原因でWindowsが無くなるのかもしれないな。 >>319
だからWindowsの話はしてないんだって
勝手にWin32の話にしておいてWindowsのせいにするなよ
なんでもいいから関数型で複数のプロパティを持つボタンのようなもの作ってみろって
一つの関数で複数のプロパティを操作することもある
そして将来の拡張性も考えないといけない
関数型でできるんか？ ホビーの奴と話し合うことなど、一ミリたりとも無いけどな。
レベルが全く違う。
プログラマに限っては、そんなにレベルが低いか？
アマチュアと話し合うことがあるのか？ >>321
ウェブ界では、状態をすべて外に追い出すのが流行ってるようだけどな。 関数型っていうのは結局ガイドラインみたいなもんやろ
引数だけから戻り値が決定する関数はテストがしやすいから
可能であればそうするようにしましょう
実際には可能でない場合が多い
何十個の引数と専用の戻り値型でも作れば
理論上は可能かもしれないが使いづらくなる >>323
それって結局グローバル変数なんだけどねｗ あおりではなく
カプセル化をうまく説明してあるサイトを長い間探しているんだが
決定版はどこ? いや俺は状態をすべて外に追い出すというのが目からうろこよ。
最終的にどうなるのか知らんけど、これは突き詰めて結果を導いてほしいな。 頑張ったけど駄目でしたという場合もあるだろうけどな。
その結果が納得できるところまで突き詰めてほしいな。 ウェブでは状態を全て追い出いたために、巨大な「状態オブジェクト」ができて
複数の関数から、共有の状態オブジェクトを変更するようになってしまってる
引数から戻り値が決まる関数型とは別のものだよ
分離された状態オブジェクトを読み書きして
状態オブジェクトが変更される >>309
ゲームの種類にもよるけどアクションやシューティングの場合
基本は以下3ステップの無限ループでTODO管理アプリみたいなものと核は同じ
1. 入力を処理
2. 状態を更新
3. 出力を生成
ReactでもElmでもRxでも関数型のパラダイムなら
直前の状態と入力(ユーザー操作やタイマーや衝突など)から
新しいバージョンの状態を作ってそれをもとに出力を生成して画面を更新する >>330
「状態」がオブジェクト、つまり配列と連想配列の組み合わせで
どこが必要なのかわからないから、テストが困難になる アマチュアと話し合ってるんじゃなくて
アマチュアがボケ倒してるからつっこんでるんだろｗ Reactなんかでいう「状態」というのはオブジェクトのこと >>332
逆かもしれんぞ？
状態が外に記録されているので、把握しやすくなる。
それどころか状態の圧縮など、自動化されやすくなり、テストが容易になる。 もともとC++のクラスっていうのは構造体の拡張なんだよね
この構造外がReactなんかでいう状態のこと
関数(状態=構造体へのポインタ, 引数1, 引数2, ...)
というのが
構造体へのポインタ->関数(引数1, 引数2, ...)
に変わったのがC++
この2つは書き方が違うだけで本質的には同じもの >>333
無い無い。
小学生がごっこ遊びしてるところにプロが違う違うと口挟むか？
自分の職業の板を見てもそんな感じよ。
突っ込もうなんて思わないし、実際突っ込んでるプロも見たことが無い。
素人同士でわいわい言い争ってる。
レベルが違いすぎんのよ。
輪に入るわけがない。
職業プログラマは素人の輪に入れるのか？ >>335
> 状態が外に記録されているので、把握しやすくなる。
状態が外にあっても中にあっても本質的には同じ
どちらにしろオブジェクト指向 考えてみろよ。
園児が模型の飛行機でブーンとやってるところに、職業パイロットが通りすがったら、違う違う対気速度が低下するからこうだなどと口をはさむか？
そのくらいのレベルの差があるわけよ。
それともなに？
職業プログラマは素人と大した変わらんとでも？ >>339
状態遷移表などは圧縮できるし、事前の検査も可能。
ここを否定せずに、研究してみてはどうか？
新しいモノは中国に期待するべきか？ >>341
そりゃオブジェクト指向でもそれは可能なんだから当たり前やろｗ >>151-152
ついにこのへんに言及したレスが出てきたな
状態がある問題をプログラミングする以上
どっちの方法がマシかを問うのが次に取るべき立場
状態は悪、関数型は神、みたいな話はもうみんな飽きたろ？ 俺は容赦なく模型飛行機で遊んでいる園児（お前）を空爆する >>344
だからお前はアマチュアとバレてるわけよ。 >>343
状態と計算を分離する結果、関数型の恩恵にあずかれるなら、分離する方向に行くのが正しいのではないか。 >>343
前から言ってるが、関数型は少数の値型と一つの戻り値で十分な関数としての要件を
満たしているときに便利なもので、そうでないものを無理やり対応させても不便なだけという話
関数型が優位なのは理論上の話で、理論上の話だと数十個の引数でもOKという扱いだから >>280
オブジェクトの内部状態が変わるのと戻り値だけが変わるのとでは影響範囲が違うだろう。
それこそグローバル変数とローカル変数のスコープの違いみたいに。 >>346
> 状態と計算を分離する結果、関数型の恩恵にあずかれるなら、分離する方向に行くのが正しいのではないか。
「関数型の恩恵にあずかれるなら」
結局そこ
「関数型の恩恵にあずかれるなら」関数型
「関数型の恩恵にあずかれないなら」オブジェクト指向
適切なものを組み合わせて使うべき
「関数型の恩恵にあずかれない」例の一つがボタン >>348
> オブジェクトの内部状態が変わるのと戻り値だけが変わるのとでは影響範囲が違うだろう。
今話をしてるのは
オブジェクトの内部状態 "すべて" を "一つの" 戻り値にしたとき
影響範囲はオブジェクトの内部状態を変えるのと同じことになってるという話をしてる
例えばボタンのスタイルは前景色、背景色、座標、フォント、余白などいろんなスタイルあるが
オブジェクト指向ではボタンのスタイルとしてオブジェクトの内部状態に組み込んでる
これらの前景色、背景色、座標、フォント、余白などをあわせてスタイルオブジェクトとして
関数からスタイルオブジェクトを返すからテストしやすい！といっても
何がテストしやすいのさっぱりわからない 色を変える関数を作るとするならば
スタイルオブジェクト = setColor(スタイルオブジェクト, 色）
これが関数型
この時、setColorがどの属性をいじるかなんてコードを見ないとわからない ボタンのスタイルオブジェクトの場合、関数型ではこうなるのだろうか？
ボタン.スタイル = setColor(ボタン.スタイル, 色）
本質的に関数型に適合しないようなものを
無理やり関数型にしても意味ないよ どこに状態持っとくかで状態管理のしやすさが変わるんだよな
あるComponentでそれと関係のない状態変数が無造作に置かれてるよりは
必要な場所からのみアクセスできるようになってるほうがありがたい
必要ない場所でその状態変数について気にしなくていいから >>353はドットでつないでるから関数型には見えないｗ
実際はこうなのだろうか？
ボタン = setStyleColor(ボタン, 色）
ボタンには色以外の複数のスタイル属性や
ボタンの有効無効などの属性を持っている
つまりsetStyleColorという関数は
ボタンという連想配列データの一部分をいじる関数になる
それはオブジェクト指向でボタン.スタイル.setColor(色）の場合に
色というメンバ変数を書き換えてるのと大差ない >>354
そうやってできたのがオブジェクト指向やなｗ 関数型Windowsが出せなければ、Windowsは無くなるだろな。 >>358
何年以内に？ｗ
ま、それを明言するだけの勇気はお前にないだろうね >>351
オブジェクトとして永続的に存在するものと単なる戻り値が同じわけないだろう。
戻り値として返されたオブジェクトをすぐに破棄するってんならまぁわかるが。 俺はこれはある意味何かが起きると思ってんだよ。
賢い奴ら数名は気が付いているようだが。
今頃オブジェクト最強とか言ってるようでは気づけんだろうけど。 >>362
いつまでに？
そのうち何かが起きるという予言は
宇宙の歴史から見ればそのうち当たるだろう
程度の話でしかないよ 30年かかると思うよ。
でもWindowsは3年でなくなるだろな。
Windowsが30年かけて地位を築いたように。
関数型ウィンドウも30年かけて地位を築く。 Microsoftは世界最大規模の研究所を持ってるから、Windows Fを出してくる可能性がある。
すでに待機中かもしれん。 >>367
いつまでに？ｗ
お前にどれだけ自信があるかわかるね
短くすればすぐに外れたのがわかる、長くすれば自信がないｗ >>369
ほんとバカだな。
それは技術の話か？
Microsoftの戦略次第だろうが。
Maicrosoftに聞け。 このスレにいくつかのアイデアが埋まっている。
気づいたものが次世代ウィンドウシステムを作るのだろう。
それが関数型ウィンドウだ。 >>370
ほらな、かってな予想を立てて、自分の予想に自信がないｗ 全て不変にすれば、パフォーマンス以外の問題点は解決する >>318
だから言ってるように、オブジェクト指向は否定してない
オブジェクトの操作を、クラスで書くか、関数で書くかっていう記述方法の違いでしか言ってない
関数はスカラー関数に限ってない
流れがプロパティ保持の話ばかりだけど、その程度ではクラスにする必要ない
クラスの特徴はメソッドと継承
そのメソッドが外に出てるのがスタティック関数
書く場所が違うだけで、機能は同じ
Oｂｊ.Close
Close（ Oｂｊ ）
の違い
で、実は後者の方が生産性が高い、ということもあるかもしれんねと（体感）
かといってWinAPLみたいに長い名前の膨大なグローバル関数がずらーっとあると、生産性低い
そこは子クラスでなくても、名前空間で分類するだけでも整理が付くので、工夫次第
さらに外人の「動詞＋目的語」じゃなく、「主語＋動詞」という命名なら分類ごとに並ぶ
× OpenObj、CloseObj
〇 ObjOpn、ObjClose
（クラスのメソッドなら後者の並びになるが、なら関数名自体もそのセンスでいいじゃんていう）
継承は、いろんなイベントで共通の処理があるフォームのバージョン違いだと、ごっそりソースは減る
でもイベント関数自体を共通にして、中で条件分岐の方が見通しがいいかもしれない
（エクセルでシートイベントに対するブックイベントみたいな）
クラス継承は、継承の様子は掘って掘ってしないと調べがつかないので >>374
>書く場所が違うだけで、機能は同じ
ポリモーフィズムの実現方法が異なるというのが本質的な違い
変更要求に対してコードの修正範囲が変わるのでどちらがいいのかというのは状況による
obj.close()はobjがclosableであればいい
close(obj)はcloseがobjの型をサポートしている必要がある
len([0,1,2,3]), len(“foo”)と[0,1,2].length, “foo”.lengthの違い
namespaceやmoduleのサポートが貧弱な言語だと前者は名前空間を汚染しやすい >>375
“foo”.length はまたややこしい話で
実装はスタティック関数ってこともある（C#の拡張関数）
これは間違いなく生産性高い
むしろそこからスタティック関数の方が生産性高いのではという発想
改めてメソッドを実装しなくても無限に連鎖できる
“foo”.length.text.length
関数は元々無限にネストできるが
length( text( length("foo") ) )
ただし括弧が見にくい、起点が後ろの方にある、組の引数が遠いとこに分かれる、ので眼精疲労が起きる > これは間違いなく生産性高い
それはどうやって計測したのか言ってみ 実装がスタティック関数 → スタティック関数は生産性が高い
ならば
実装がスタティック関数ではない → スタティック関数は生産性が低い >>338
16年この業界にいる現役だよ。
むしろ、一般人ががプログラム言語なんかに興味持つ方が驚き。
現場で使えない派遣のプログラマーをアマグラマーって馬鹿にしてるけど、アマチュアさんいるんやね。プログラムは好き勝手に書いてた方が楽しいよ。
囲碁とか将棋のプロがアマを見る気持ちがこのスレで分かった気がする。 >>376
おまえ、それ、マルチスレッド処理でも同じこと言えんの？
GUIの話してんのかわからんけど、異なる複数の処理がスタティック関数にアクセスすること考えてないだろ？
なんか、Cでmalloc使わない！って豪語して、スタックオーバーフロー起こしてどうしていいかわからなくなってたPG思い出したわ。 >>380
そりゃ、自分より年寄りはいるだろう。
すごい人もいっぱいいて、日々勉強だわな。 そりゃ恥ずかしいと思わないと。
この板は文法やライブラリの使い方を取り扱う板。
プロが欲するのはお客様の情報で、ここにいるべきではないだろ。 >>381
某大手メーカー系が何年も直せなかったマルチスレッドで起こしてるバグを小一時間で直してあげたことあるよｗ
（マルチスレッドで確率的に起きる事故はステップ実行で探せないから、勘が必要）
関数がスタティックかどうかと、処理がぶつかるどうかは無関係
組み込み関数を想像すれば分かるだろｗ
各スレッドがその関数に渡すインスタンスが別ならぶつからない
同じインスタンスの必要があるならシリアル化するだけ
そっちこそマルチスレッドの扱いが曖昧っぽいなｗ >“foo”.length はまたややこしい話で
>実装はスタティック関数ってこともある（C#の拡張関数）
>これは間違いなく生産性高い
>むしろそこからスタティック関数の方が生産性高いのではという発想
このあたり失笑なんだけど
こんなちっちゃい部分にクローズアップして生産性を語られても しかも"foo".length()が実装はスタティック関数なのは
C#が提供してる拡張方法がそうなってるだけで
データと処理を紐づけてるのはオブジェクト指向そのものじゃないか オブジェクト指向とはオーバーロードである。
ってことも無いのでは？ オブジェクト指向＝○○ではなくて、
オブジェクト指向はいろんな課題を解決するための
テクニックを詰め込んだ言語
イコールで何かと結びつくものではない
結びついたらオブジェクト指向という必要がないだろ いや、そもそもオブジェクト指向だろうが関数型だろうが便利ならなんでもいいけど
関数型のほうがすべてにおいて優れてるって言いたいという動機ありきで
都合のいい話をでっち上げてるとしか思えない
全体的に根拠がふわふわしてるんだよ こんなふわふわした論理を積み重ねちゃう感じで
本当にプログラムがかけるのかも疑問 >>392
そのとおり
私は状態がない世界に住んでいる
私の世界では引数と戻り値だけで表現できる
状態がない世界では関数型が一番
こういう理屈
現実はたくさんの状態がある世界
たくさんの状態をどうやって管理するか？が難しい
そこに架空の世界を持ってきたって意味がない >>386
プログラミングの生産性は地味でちっちゃいことの積み重ね
管理職やアプリコンサルやその他ペテン師は大きいことを言いたがるから、
多大なコストをかけてマイナンバーカードを作っておいて、未だに当たり前のデータ連携ができておらず、相変わらず無駄な申請
もしくは、ついでに出てきたものに対するついでの返信でしかないものを、「クローズアップ」とする解釈の方が大げさ
>>387
その機能は、あるクラスオブジェクト指向言語、が持ってるのだが、コーディングはスタティックなコストで済む
どの言語を選ぶべきかという話ではなく、どんなコーディングをすべきか、という話
または、いい機能なので他の言語にも付けてね、っていう願望
メソッド風に出てくるのは書式の違いであって、本質的に括弧と違わない
スタティックだと言ってるんだから仕様的にも裏切っちゃいけないし
宣言は length( this string s ) で普通の関数と同じく括弧の中に呼び出し元がある（ちょっと気持ち悪いが） 馬鹿はオブジェクト指向にかぶれるくらいなら関数型にかぶれてる方がまだ扱いが楽。
モジュール分割へたくそなくせにオブジェクト指向にかぶれるとほんま手に負えんモンスターになるから。 >>396
人間の話なんてどうでもいいんですよ
技術の話をしなさい staticが技術的な話なのか。
C++をbetter Cとして使ってくれてればいいよ。
C++使ってんのにどうしてOOPじゃないんだ、とか言わないからさ^^ スタティック関数っていってるの多分javaのスタティックメソッドの方だと思うよ オブジェクト指向から関数型へは、ある程度発想の転換が必要なんだろな。
スレの子たちは転換できてないな。
オブジェクト指向で設計できないから関数型では出来ないというが、そもそもオブジェクト指向の必要が無いのだが。 C++をbetter Cとか言う奴は
C++もCも両方ニワカである >>400
> オブジェクト指向から関数型へは、ある程度発想の転換が必要なんだろな。
必要なのは発想の転換じゃなくて実装サンプルだよ
多数の状態を持つボタンのようなものをどうすればシンプルに実装できるか
その実装サンプルがどこにもないから関数型には無理なんだなってことになってる そもそもオブジェクト指向について、関数型について
きちんと説明できる人っているんだろうか
みんな、なんとなくこういうもの、というイメージしか
持てないでいるんじゃなかろうか >>403
関数型についてはごく小さな例だけをあげて、だから関数型は素晴らしい、といってるのしか見たことないな
自分が書いたのでなくてもいいからだいきぼなプログラムを関数型でうまく書いたという事例があれば見てみたい カプセル化だけではなくオブジェクト指向自体が時代遅れ
スタートアップである弊社が全員ほぼ未経験でRuby on RailsをScalaに移行した理由、その効果と苦労点 - Qiita
https://qiita.com/sonken625/items/d5d0f3b8d794e06489bd >>402
>多数の状態を持つボタン
もう少し要件が明確にしてくれる？ >カプセル化だけではなくオブジェクト指向自体が時代遅れ
といいながらScalaを例に出してるけど
「Scala（スカラ、SKAH-lah）はオブジェクト指向言語と関数型言語の特徴を統合した
マルチパラダイムのプログラミング言語である。」by wikipedia
オブジェクト指向も含んでるしもう何が言いたいのか HaskellではMonadで状態というか状態遷移を表現するらしいけど
関数型推しにはそれがどういう実装になるのか例を示してほしいね そんな頼み方で教えてもらえると思ってることに驚いた。 関数型の利点を主張する割にここまで具体的な情報が一つもでてきてない
それともエアプだからわからないとか・・・？！ >>406
要件？HTML（DOM）のボタンでいいよ
https://www.w3schools.com/jsref/dom_obj_button.asp
プロパティ一覧
autofocus
defaultValue
disabled
form
name
type
value
ボタンを作ったら、これだけの情報が初期化されて
作ったボタンからこれだけの情報を取得することも出来る
本当はスタイルもあるからもっと多いけどね ベクトル化の概念が抜け落ちてるんだろうけど。
説明しろと言われても、自分で勉強しろとしか。 関数型言語
button = CreateButton({name: "名前", type: "submit"})
// buttonは連想配列 {name: "名前", type: "submit"}
print(button["name"])
オブジェクト指向
button = CreateButton({name: "名前", type: "submit"})
// buttonはオブジェクト
print(button.name)
こんな感じっすかね？ｗ ボタンの「作成」と言ってるところにセンスの悪さを感じるというか。
きちんと説明してやろうという気力が失せるんだよな。
どうせコイツじゃわかんねーだろうっていう。 じゃあボタンの「作成」以外でもいいよ
お前が好きなように言いたいことを言え
お前はまだ何も言ってない 関数型言語派は、「はぁ～お前らわかってないんだよな～」って言うのが目的なので
説明しろといわれたら、説明できなんだよなｗ
そのパターンばかり そもそもの前提からして意味分かんない
何がどうなることを目指してるの？
お互いに プログラミング言語の目的なんて
目的は動くものを（できるだけ簡潔に）作ることに決まってるだろ 俺今丁度、環境変数を扱うコード書いてるんだけどさ、
1. 環境変数を設定する
2. （確認のために）設定した環境変数を表示する
3. 環境変数を残したまま他のプログラムを実行する
これを関数型言語で書いてみて これすごく簡単なことだと思うんだが、こういうのすら関数型言語では実装コードが出ないというねｗ このスレの流れは関数型狂信者がしつこくオブジェクト指向では駄目だと
根拠の薄い主張を繰り返し、具体的なことを聞くと煙に巻く
今の所、関数型推しはやべえ奴という印象しかない >>420
動くもの？
正しく動くものでしょう？
この「正しく」ってのが重要になると思うんだけど >>424
言葉遊びして言い訳はいらんよ
さっさとやれ ソフトウェアというのは多数の「状態」をどうやって管理するかってことに尽きるんだが
関数型言語は「状態」が少ない場合はこれでうまくいくという話しかしない
多数の「状態」を管理する方法ではなくて、少数の「状態」を管理する方法しかいわない
多数の「状態」という問題の解決方法ではなく、問題をすり替えてる 正しく動くこととオブジェクト指向になんの繋がりがあるの？ 関数型言語にとっては正しく動くことが課題なので・・・
バグばかり まじでろくなやついないな
関数型を嫌う理由として十分だわ >>432
お前もコード見て何がどうなってることを確認したいの？ >>433
どれくらいの複雑さになるかを確認したい 簡単なコードなんだからぐずぐずせず
さっと出したほうが早いのに
言い訳してるってことはエアプか 結局、何もかも前提がない
いいソースとはどういうソースを言うの？
っていう単純な前提がないから
全てにおいて結論が出せない
十年以上もコード組んでるくせに
こんなこともわからない時点で
そんなに能力高くないんだよお前ら いい悪いを議論する前に、まずコードを出さないと意味がない
動くコードを出しましょう >いいソースとはどういうソースを言うの？
初心者みたいな質問出たぞ もし、コードで判断をするなら全く同じ処理を記述した
方式Aと方式Bの両方が必要になるはずなのにそれも用意しようとせず
片方だけ集めたってしょうがねぇだろバーカ
お前のソースなんてみる必要すらない >>444
> 1. 環境変数を設定する
> 2. （確認のために）設定した環境変数を表示する
> 3. 環境変数を残したまま他のプログラムを実行する
>
> これを関数型言語で書いてみて
ENV["FOO"]=123
print(ENV["FOO"])
system("bar.exe") そもそもまともな思考ができてねーじゃん
本当にその程度でプログラム組めてるのかよ
恥を知れバーカ >>444
>>447で関数型ではない状態を変更するコードを書いた
関数型はまだでないのか？ >>413
それら全部状態って呼ぶのかぁ
とりあえず言いたいことは理解した
elmのチュートリアル1ページ目のサンプルコードで
HTMLのボタンも作ってるから見てみるといいよ
https://guide.elm-lang.org/ インスタンスの代わりに、連想配列を受け取って連想配列を返す
それが関数型
状態はメンバ変数の代わりに、連想配列に入っている
連想配列.メソッド(); これがオブジェクト指向で
関数(連想配列); これが関数型
ということでOK？ そもそも、時間の流れがある≒刻一刻と状態が変わる、というパラダイムがある
例えば3Dアクションの全てが四次元プログラミングになる
x,y,z,tの四変数が必要になる
GUIは三次元プログラミングで、x,y,tの三変数が必要になる
未来がどーなるかは分からん、ってのがダイナミック、
一度決めたら未来永劫変わらない、ってのがスタティック >>456
違いません。
という反論で十分やなぁ
理由も言わないお前に対してはｗ いちいち理由を説明してもらえるのは小学生までやろな
自分で学ばないやつは数十年前にオブジェクト指向理解できなくて既存のパラダイムに囚われてた老害たちと同じ道を辿る >>459
俺なんかそれ怪しいと思ってるんだよね
オブジェクト指向ってどこをどう探してもメリットねぇよコレ
何でこんなもん広めたんだ？
俺これのおかげでソフトウェア業界何十年停滞したかわかんねぇぞって思ってる 一つのコンピュータ内に複数のプロセッサがある状況になって、俄然関数型が注目されるわけです。
しかし関数型には、数学的思考力が無いと使い方がわかりづらいという欠点があります。
オブジェクト指向でさえパターンを提唱した人たちがいるのです。
世間を侮ってはいけません。
あなたが思うよりずっと低能です。 コンピュータは電子計算機なので、関数型は非常に素直なアプローチです。 >>462
ずーっと昔はグローバル変数丸出しで
モジュール間の結合度が高すぎて、
既存コードの保守が難しくなった。
既存コードの保守をしやすくする為に、
モジュール間の結合度を下げよう、
カプセル化してモジュール間のインタフェイスを
最小限にしようという機運が高まった。
そこで出てきたのがオブジェクト指向。
計算機科学は発展途上だから完璧なものは未だ無いよ。
有るのは「よりマシなもの」だけ。
文句を言うのは自由だけど、賢い人はそれを
チャンスと捉える。 個人的には関数型に大いに興味があるし、勉強もしてみたいと思っているが、一般的には>>464とは逆の理解の方が一般的なのでは？
電子計算機であることと関数型のメリットがどう結び付くのかよくわからないが。 >>465
オブジェクト指向のビジネス的な成功理由は
メリットがないことで弱点がないってことかな
メリットがあればみんな当然そこを挫きに来るし
もっといいモノを見つけて来るだろう
メリットが無ければそのアプローチで挑むことはできない
そんなくだらないアプローチが通ってしまうほど技術者が劣化してしまっていたことも原因の一つだと思う
資本主義のセーフティが全く働いていない
より良いものを使用者が選択できる選択肢は無く
どこもかしこも全く余裕がなく世界中でMSの提供物を使うしかなかった
そこまで世界が劣化してしまった結果として生まれた悲劇だと思う
二十年？三十年近くプログラミング言語は何も進化しなかった
これは大き過ぎる失策だったと思う CでADT書いてみればオブジェクト指向の利便性がわかるよ
オブジェクトはADTの延長線にあるものだから
流行ったのはGUIを実現するにあたっての現実な解だったからだろうね >>459
オブジェクト指向の方が優れているよ
理由はいちいち説明しないよｗ >>462
お前がオブジェクト指向のメリットが理解できないだけじゃね？
お前自信に問題があるって自覚しよう 関数型言語の方が（ある点では）メリットが有るのは事実だが
オブジェクト指向にもメリットは有るわけで
それが理解できないのはセンスがない
オブジェクト指向にはメリットがあるが、関数型言語なら
それを上回るメリットが有るという言い方をするならわかるが
メリット自体がわからないんでしょう？ オブジェクト指向のメリットと謳われていたものはすべてデメリットだったんだよ。
暗殺組織が「両親を殺したのはあいつらだ」と言って子供に殺人させるが、本当は両親を殺したのは暗殺組織みたいな。
もっとも邪悪なのは階層化だろうな。 > オブジェクト指向のメリットと謳われていたものはすべてデメリットだったんだよ。
じゃあそのメリットというものをすべて言ってみてください
それがデメリットかどうか語るのはそれからですね Microsoftから関数型OSが出るかもしれんな。
出せなければMicrosoftは終わりだろ。 じゃあ俺はMicorosoftどころか、Apple、Googleも含めて
関数型OSなんてのは登場せず、終りもしない方に掛けるわｗ
少なくとも100年以上安泰だろうな
でお前はMicrosoftはいつまでに終わると思う？
終わると言っては見たものの、すぐには終わりそうもないから
100年後には終わってるはずだーとか言う？ｗ
なんかぐぐってみたらNixOSとかいうのが純関数型OSとか書いてあるの見つけて調べてみたら
たんにパッケージマネージャーが関数型（というより宣言的記述で使えるだけ？）みたいでワロタ
お前が言う関数型OSっていうのもこういう意味？ｗ
https://www.atmarkit.co.jp/news/200902/17/nixos.html
> もう1つ、最近私が気になっている実験的OSは“純関数型”を標榜する「NixOS」だ。
>これもLinux上に構築したシステムで、本来の意味でのOSとは違うのだが、
>ユーザーが利用するシステムが抱えている課題を解決しようとしているという意味では
>OSと呼んでもいいと思う。NixOSの公式ページには純関数型ディストリビューションと書いてある。 なんで「関数型」が「オブジェクト指向」の対義語になってるのか
「関数」なら分かるけど
「関数型」（宣言型）は「手続型」の対義語だよね（あまりにかけ離れてるので親階層で対義語）
「手続型」の「関数」は「関数指向」と言えばいいのかなｗ
・手続型（命令型）
・コマンド型
・関数指向
・オブジェクト指向
・メッセージ型 ←これも関数指向
・クラス型
・宣言型
・関数型
・構造型（SQL）
しかも「関数型」は反「カプセル化」でもないし
本来はループ処理しなきゃ実現できないものを、むしろ隠蔽しちゃうでしょ
SQLもそうだけど（SQLはループじゃなく並列処理だけど）
値１つ１つの変遷をステップ実行で確認できず、手続脳な人には意味が分かりにくい
「関数型」を希望した人はそれが邪魔だってわけだけど OSについては、SQLの発想はありだと思う
既にWMIで一部SQLのようなもので操作できるけど
フォルダやレジストリを全検索すると、物凄い時間かかるじゃん
DBなら一瞬なのに
なのでOS自体がDBでできてればなとは思う
縦横無尽に検索したり更新したりできる
メーカーの中の人も影響関係を瞬時に正確に把握でき、バグ率も下がると思う
システムログに物凄い書式のXML使ってるけど、無駄が多過ぎる
肝心な条件で絞れないし
DB形式の２次元では階層表現できないということなんだろうけど、
２次元でも複数のテーブルに分ければいくらでも多次元にできるし、
検索も速いし、分かりやすいし、二次加工しやすい
Webについては最近はJSONとか？
XMLよりはマシだけど、やはりDB形式より無駄が多い
「関数型OS」とかわけわからんけど、XMLと似た危険な香りがする
なぜ人はDB形式以外に挑戦するのか >>476
オブジェクト指向にとって関数型は対義語じゃないよ
だけど関数型にとってオブジェクト指向は対義語
なぜなら関数型は極めると純粋関数型言語に向かうから
オブジェクト指向にとって関数型は取り入れるもの。便利な部分をつまみ食い
だけど純粋関数型言語にとってオブジェクト指向は純粋関数型言語ではない >>477
> フォルダやレジストリを全検索すると、物凄い時間かかるじゃん
> DBなら一瞬なのに
インデックスが張られてないDBは検索がものすごく遅い
全件検索するから
つまり、速いか遅いかはインデックスがあるかどうかでしかない >>477
どうせあれの話をしてるんだろうけど、
Microsoftから学んだほうが良いよ
ファイル検索をSQLでできるようにしたと
大々的に発表したけど結局搭載するのをやめた
時間がなかったわけじゃない。だって随分と前の話で
本当にやる気があるなら、次期バージョンで搭載にしてたはず
つまりMicrosoftという技術力の高い会社が
「発想は面白かったが実際にやってみたら意味がなかった」
と判断したんだから >>479
インデックスなんて大したことないよ
（最近は結構差が出る場合があるけど、わざとじゃないかとｗ）
DBの速さはデータ形式の単純さ、全行並列処理、ハードディスクの自前管理 >>480
まあ一般ユーザーは使わんわな
じゃなくて、内部的な設計思想の話 Googleの検索がめちゃくちゃ速い理由
https://logmi.jp/business/articles/234684
Googleのコンピューターも膨大な時間と努力を投入して
インデックスを作っていますが、その努力の甲斐があるというものです。
インデックスによって劇的に検索スピードが上がり、毎秒、約40,000件もの検索にGoogleは答えているのです。 ここはオブジェクト指向すら理解できない老害の教育の場かな？ >>482
＞内部的な設計思想
それがWinFSだったんだけど
https://www.itmedia.co.jp/enterprise/articles/0607/18/news010.html
データは複数のデータベース(またはデータストア)に保存され、WinFSはこれらのストアとファイルシステム間でデータの同期を効率よく実行する。
また、連絡先や予定表アイテム、電子メールなど、一般的に使用される類のデータの標準のプロパティスキーマも提供する予定だった。
WinFSが実現されていれば、ファイルの検索や整理機能の向上、および特定の種類のデータ
(連絡先や予定表のイベントなど)の共有を共通スキーマにより簡素化する相互運用性の向上などが期待できた。 >>486
そして実験的に実装したけど、結局速い検索ならインデックス作るだけでよくね？となったんだよね 特定のプロパティで検索するのも、プロパティをインデックスすればいいだけだしね GUI用の概念を別用途に持ち込んだから今の混乱がある >>478
純粋関数型以外の関数型言語（関数型をベースにしつつオブジェクト指向の機能を付け加えた言語等）も人気があるから、「関数型は極めると純粋関数型に向かう」というのは語弊があるような。
結局今は、純粋なオブジェクト指向を出発点にするにせよ、純粋な関数型を出発点にするにせよ、他方の良い点ををうまく取り込み、バランスを取ることを目指すアプローチが多いんだろう。 結局、ドキュメント無くても把握できるにはどうすればいいか。あたりが一般的なメリットで、
それを推し進めると、制約や挙動が保証されるものになり
結果、オブジェクトの不完全さが目立って、
関数型がもてはやされるみたいな。
でも、できる人間なら言語の不完全さは乗り越えていくんだよな。 「純粋関数型に非ずんば関数型に非ず」という原理主義的な人は、決して多数派ではないと思うけどなぁ。
自分も関数型言語についての知識はあまりないが、たとえばF#（OCaml）は手続型ではなく、関数型言語として紹介されることの方が圧倒的に多いと思う。 >>493
ドキュメントなくても～から関数型に全く話がつながってない
関数型ならドキュメントなくても～とか言ってるやつは一人もいないだろ >>494
結局の所、みんな関数型には限界があるって知ってるんだよね
理論的な限界じゃなくて、理論的には可能なんだろうけど
手間が多くて面倒でとてもやってられなくなる場面が多い メッセージングとは、オブジェクト同士の二人称対話なのだ！
>>155
>オブジェクト指向のコア概念メッセージングがなぜ提唱されたか察するに
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く ところで「チンポがシコシコする」という日本語表現は、文法的に正しいのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ ttps://video.twimg.com/ext_tw_video/1296548685300396032/pu/vid/960x720/Tt9Hj_acNH_uHS6Y.mp4?tag=10 >>483
そういうペテン師に合わせて最近のバージョンはたまにインデックスが効く罠が仕込んであるのかなｗ
あるバージョン以降は、妙に遅いことがあって、解析すると、ここにインデックスを貼れと
貼ると、従来の速さに近付く
速くなるわけじゃなく、元に戻るだけｗ
（バッファオーバーラン防止のためにタイプセーフ対応したとの情報もちらっと見た気がするので、そのせいかもしれない）
にしてもその差はそれほど大きくない
インデックスの威力がメインなら、BULK INSERTや一時テーブルの速さを説明できない
これを使って、１時間の取り込みを数秒に短縮とか、あちこちで改善してきたので
この差はインデックスの有無を遥かに超える差 >>486
＞既存のツールで有用な結果が得られるのに、わざわざ追加情報を設定して
＞ファイルにタグを付ける必要があるだろうかという疑問が生まれることになった。
ああ現実主義でいいんじゃないかな
「発想は面白かったが実際にやってみたら意味がなかった」
ではないよ
＞データベース内のテーブルとファイルシステム内のファイルを同期する機能は、SQL Serverの次期バージョンに組み込まれる予定だ。
＞汎用OSサービスとなるはずだったものがSQL Serverの1機能として提供されることになる
いきなりスクラッチビルドな高い理想を目指すのではなく、徐々にってことだ
ここでは直近の現実について話してるわけじゃないから
実際Win１０でも「Windows へようこそ」をオフにしても出てくるとかｗ
俺が言ってるのは検索だけじゃなくて、中の人のバグ率や、機能整理の意味もある >>502
> インデックスの威力がメインなら、BULK INSERTや一時テーブルの速さを説明できない
え？説明できないの？それお前が無知なだけじゃん。
1. インデックスは検索に使うものでインサート時には関係ない
むしろインデックス作成のために逆に時間がかかる
BULK INSERTでは一件ごとにインデックスを貼る処理を行うと時間がかかるので
インデックスは貼らずにデータを挿入し、あとからインデックスをつけるのは常識レベルのテクニック
2. 一時テーブルだからといって速いことにはならないが、それで速くなったとするなら
一時テーブルによってデータ量が減った。複雑なクエリーで無駄にデータを参照しているとそれが減ることがある
一時テーブルによってインデックスを（有効に）使える条件が揃った
などの理由だろう
アナライズとかしたことないだろ？そういう風にデータを参照しているかちゃんと調べろ
常識レベルのことを知らんとかアウトや
お前はなんかやったら速くなったといってるだけで、その理由を調べてもいない >>484
グーグルとローカルのDBシステムでは規模が違い過ぎるし、「インデックス」の意味もだいぶ違う
いろんな角度からの検索を想定したキーワードを事前に生成し、単純な比較でヒットするようにしてある
逆にそのロジックが邪魔で余計なものがヒットし過ぎるが
言葉を厳密にしても全然絞れない > グーグルとローカルのDBシステムでは規模が違い過ぎるし、「インデックス」の意味もだいぶ違う
その根拠は？（間違った）主張だけをしても支持は得られない >>504
＞これを使って、１時間の取り込みを数秒に短縮とか、あちこちで改善してきたので
これが見えんのかねｗ
誰に向かって言ってるのか
「あちこちで」だ
さらに言うと「確実に」だ
まぐれではない
１．そんなことは知ってるが、ゆえに、インデックスがDBエンジンの速さの理由かね？
（言っとくが、ファイルコピーより遥かに速い）
２．何を言ってるのか分からんｗ
ちなみに説明を省略したが、１時間もかかる要件なので、一時テーブルから本テーブルへの
INSERT SELECTは、腕の悪いSEには無理な複雑さになることもある
そのFROM句が一時テーブルなのに速いと言ってるんだよ
というかその他のストアドでも多用するが、速い
あるいは言い方を変えると、インデックスの効いてない状態での速さでも十分速いと言ってる
普通のシングルタスク処理や、OS関連に比べると、とてつもなく速い
という意味 >>506
根拠はその後段に書いてあるはずだがｗ
まあ昔の記憶なので、ソースはないよ
雑談なので気楽に > そのFROM句が一時テーブルなのに速いと言ってるんだよ
だからちゃんとアナライズしてどのようにデータを参照しているか調べましょうって
なにもしてないくせに、やってみたら速かったとか遅かったと素人かよｗ > （言っとくが、ファイルコピーより遥かに速い）
他人が検証できる方法とベンチマーク結果よろしく
主張だけしても説得力はない だいたいインデックスは検索にときに使われるといってるのに
ファイルコピーとか言ってる時点で頭悪いがｗ >>511
頭悪いな
取込処理がファイルコピーより遥かに速いんだよ
その理由は？
インデックスがないから？アホかｗ
インデックスがあるよりはない方が速いのは当たり前だが、ファイルコピーより速い理由は？ >>510
それを言うならこのアホにだろｗ
483 名前：デフォルトの名無しさん 投稿日：2020/08/25(火) 08:15:35.41 qpVxWgT6
>>481
検索はインデックスが全てです >>512
まずファイルコピーより速いという証拠をだせと
話はそれからだろ
ウソを検証せずに話をすすめることで
事実であるかのように誤認させるテクニックは俺には通じない ストアドよりインデックスのほうが速いよってスレが無かったでしょうかね。 ありがちなインデックス教を説得するのは本題ではない
イベントログを解析したことあるか？
特にファイル監査
なんだあの大量のゴミ
不信なアクセスにどうやって気付くんだ
物凄い工夫して視認できるバッチ作ったけど
あれを単純なCSVにするだけでも各方面生産性が随分高くなる >>515
やってみるから、お前がやったことをいえ、
1. RDBMS
2. OS、バージョン
3. ファイルサイズ
4. 挿入先テーブルのスキーマ
お前が何も言ってないんだから、出来るわけなねーだろ > イベントログを解析したことあるか？
> 特にファイル監査
データベースの話なののこれだからなぁ
素人じゃんｗ > そしたら「ストアドよりインデックスのほうが速いよ」って。(ﾟДﾟ)ﾊｧ? >>519
ニワカか
「データベースの話」ではない>>477
勝手に変えるな
「関数型OS」とかいう話が多く出てたから、「DB型OSは？」という、OSの話 DB型OS？そんなことばどこから出てきたんだｗ
検索してもないな >>518
１．SQL Server
２．任意
３．数十MB
４．任意 >>522
>>477
> OSについては、SQLの発想はありだと思う
（中略）
> なのでOS自体がDBでできてればなとは思う イマジネーションの欠如が深刻なんですよ。
つまり、石頭です。
昔は頑固おやじに代表されるように、年よりが石頭だったんですが、最近は若者なんですよ。
頑固おやじというものは、経験に基づいて保守的になっていたものですが、若者の石頭は、イマジネーションの欠如によるものです。
教わったものしかわからない、新しいものを創造できない。 OSがデーターベースで出来てるって意味不明ｗ
プロセス管理はどうするんだ？
メモリ管理はどうするんだだ？ プログラマはよく「ggrks」と言いますが、ネットで検索して何がわかりますか？
私の職業では、ネットで検索してわかることなどありません。
出てくるのは宣伝文句だけです。
プログラマは検索してわかるほど簡単なお仕事ですか？
だとしたら、新しいものは生み出せません。
きっと中国人は、検索でわかることなどないと言うでしょう。
だから新しいものはすべて中国からやってくるのです。 最近はよく「エビデンスを示せ」なんて言いますよね。
彼らに示して理解できますか？
彼らが欲するのは文献ですが、文献の中身は一切理解できないでしょう。
違いますか？
それでも、文献を編纂する立場の者にでさえ、気軽にエビデンスを示せなどと言います。
あなたに示して何が変わると言うのでしょう？ 反論はありませんね。
DB型OSの良さが理解していただけたようで何よりです。 まだデータベースのほうが速いって証拠だせないの？
一体どの環境だったらそうなるのかサッサ言えよ
DB型OSの意味もいわないしｗ
ねぇねぇプロセス管理は？メモリ管理は？ >>155
>オブジェクト指向のコア概念メッセージングがなぜ提唱されたか察するに
オブジェクト同士は常に二人称で、「俺」←対話（メッセージング）→「チンポ」。
つまりチンポは独立し自ら考えて行動する別の生き物なのである。
この考え方に至ってからは、オブジェクト指向の理解もすんなり進みました。
上手くオブジェクトを定義して、上手く会話させてやるのがオブジェクト指向
での設計なんだなーと今でも思っています。
https://blog.mah-lab.com/2014/03/18/object-oriented/
チンコの随意筋と不随意筋
http://d.hatena.ne.jp/tottokotokoroten/20130516/1368716650
＜俺＞
「 部屋の英子がこちらを向いた気配に、彼は勃○した陰○を外から障子に突きたてた。障子は乾いた音をたてて破れ、
それを見た英子は読んでいた本を力一杯障子にぶつけたのだ。本は見事、的に当って畳に落ちた。 」
＜チンポ＞
「 その瞬間、竜哉は体中が引き締まるような快感を感じた。彼は今、リングで感じるあのギラギラした、
抵抗される人間の喜びを味わったのだ。 」
まさに独立した人格を有したチンポという、もう一人の俺がそこに現れるのである！
【藤子・F・不二雄】「みきおとミキオ」現在と未来、憧れの入れ替わり生活！
https://www.google.com/amp/s/middle-edge.jp/articles/0izbO.amp DB ベースOSは、BeOSなど失敗の歴史。Windowsでもその計画は頓挫してる。 ファイルシステムのデータ構造はB-Tree
B-TreeはDBのインデックスに使われるデータ構造
OSもDBも性能的には似たようなものじゃないかな
ファイル名にデータを格納するIsseiという伝説の検索システムを思い出した、DBより効率が良いとうたって叩かれていたなあ >>497
洋式トイレに座ってオシッコを出したり止めたりする時、チンポがどうなっているかを確かめる必要無い。
つまりカプセル化とはオブジェクトの独立性であり、チンポはそれ自体が独立した生き物なのであると。 オブジェクト指向とは、「繋がっているけれども独立している」という意味である！
オシッコを出したり止めたりする時のチンポは繋がっているが、勃起する時のチンポは独立している！
違うか？
>>18
>オブジェクト思考って何？
>誰か説明して
では「チンポがシコシコする」という日本語表現は、文法的に正しいのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ ちんぽがしこしこ、そんな言語表現あるのか？
クリントンの「不適切な関係」
https://eigo-kobako.blog.so-net.ne.jp/2008-06-21
不適切な関係、そんな言語表現あるのか？
クリントン大統領も、チンポがしこしこしてしまったのか？
ちんぽがしこしこしてしまったのが、不適切な関係なのか？ // おしっこルーチン
俺.パンツを脱ぐ()
while (俺.オシッコ残量 != 0) {
俺.オシッコ残量 -= 俺.チンポ.オシッコを出す()
}
do {
俺.チンポフリフリする()
} while(count < MAX && 俺.残尿感())
俺.パンツを履く() >>540
>俺.チンポフリフリする()
「フリフリ」しているのは、腰であってチンポでは無いぞ？
腰をフリフリすると、慣性の法則で腰とは逆方向にチンポが動くということ。違うか？ >>536
>ファイルシステムのデータ構造はB-Tree
その比較はDBのレコード数分だけ1ディレクトリ内にファイルを作成して
それぞれの性能を比較することが前提になるんだけど
意味のある性能比較じゃないよね データベースに1GBものISOや動画を入れるのは遅い
まあ普通馬鹿げていてやらんがね 「オブジェクト指向」について解説！
>>88
>こういう認識の齟齬を生みやすいこと自体が
>オブジェクト指向の欠陥
>まず分かりにくい思想があって
>その思想の解釈が人によってバラバラで
オブジェクト指向とは、繋がっているけれども独立しているということ。
例えばチンポは自分の体の一部であっても、チンポは自ら考え自分の意志で勃起してシコシコする。 >>491
>純粋関数型以外の関数型言語（関数型をベースにしつつオブジェクト指向の機能を付け加えた言語等）も人気
オシッコの時のチンポは関数型、勃起や射精のときのチンポはオブジェクト指向、違うか？ >>476
> ・オブジェクト指向
> ・メッセージ型 ←これも関数指向
オブジェクト指向のメッセージングは「関数指向」ということだが、オシッコはチンポの役割で、
オシッコを出したり止めたりするのはチンポ、チンポに力を入れたり力を抜いたりするのは俺。 >>105
>そもそもオブジェクト内に状態を持つこと、
チンポは随意筋であり不随意筋である！
>内部状態を操作すること自体がシステムがめんどくさくなったり
>不具合の原因なんだから、そんなこと自体極力やめた
>方がいい。という考え方。
ならばオシッコのチンポと勃起のチンポは別々に分けて考えることが大切だな！
511 デフォルトの名無しさん 2018/10/29(月) 23:32:40.68 ID:LL+W6ENh
随意筋←implements─チンポ─implements→不随意筋 40歳童貞「さーて今日も５ちゃんねるで、オシッコ！チンポ！しこしこ！書き込みっと」
こんな感じなんだろうなｗ 『シコシコ』という擬音はどうでもよい。問題は、
自我 チンポ
↑ ↑ チンポ＝自我
チンポ 自我
オブジェクト指向では、この三種類が考えられるということだ。
＞チンポ＝自我
散歩している時、自分もチンポも所在地は同一である。
https://i.imgur.com/j3uTk1K.jpg
夏目くんの場合は、チンポが自我を圧倒し、体が自然に滝川さんの股間に近づいていったのだ。
『笑ってごまかすな！！』
と言われても、夏目くんは何と言えば良かったのだろう？
チンポ≫自我
『チンポが自我を超えてしまった』を簡略化して、チンポがシコシコする！
チンポがシコシコしていると（チンポが自我を超越していると）、息もハァハァになる。
チンポがシコシコしている（チンポが自我を超越している）と、顔もアヘ顔になる。
つまりその顔は『チンポの一部』つまりチンポの皮と同じということ。
博士号の肩書きがあっても、STAP細胞のそれは間違いであり科学者として失格。
チンポと自我の関係について、それが間違いということなら、俺も科学者を自称するのを止めよう。
しかしながらあの夏目くんは、笑ってごまかす以外に何と申し上げたら良かったのか。 >>549
「オブジェクト指向」について、他にもっと解りやすい説明が有るというなら、ここに書いてくれよ！ >>551
俺が言ってるのは40にもなって
オシッコとかチンポとか、恥ずかしくないのかってことなんだがｗ >>543
そういうことなの？
僕はファイルシステム作ったことないし調べたことないから知らないけど
B-Treeはファイルシステムでファイル管理にだけ使われてるの？ ディレクトリの管理は別であるってわけ？
ディレクトリの検索はファイルの検索よりも遅いの？ どうなってるの？ >>552
>俺が言ってるのは40にもなって
>オシッコとかチンポとか、恥ずかしくないのかってことなんだがｗ
ならそういうあんたが、オブジェクト指向について解りやすく示せ！ カプセル化で困るときってトラブったときだよね
この内部のメソッド呼び出せたら調査やリカバリが簡単なのにって思うことはときどきある
副作用がないメソッドは原則公開でも良いかもわからんね
副作用がないようにメソッドを作る技術も大事 >>555
もう少し具体的な例を挙げられる（マジレスすると無理だと思ってるｗ）
内部のメソッドが呼び出せないことで調査ができない場合を聞いてます。
答えられますか？ いろんなことを思いつくことができる俺がないと言ってます。
反論があるなら受け付けますよ？ 副作用ないならそもそもインスタンス化可能なクラスにする必要もない（？）
必要あってクラス化してるなら副作用抑えるといっても限界があるんじゃね >>553
ディレクトリは直下のファイル名と内部IDとのマッピングリストをコンテンツに持つファイル
親ディレクトリから見れば他のファイルと同じ
NTFSだとMaster File Table(MFT)っていう固定長のデータ構造に
ファイル/ディレクトリごとに1レコードの情報が管理されていて
ファイルのレコードを見ればDiskのどこにアクセスすればのかがわかる
/foo/bar.txt にアクセスしたいなら
MFTのルートディレクトリのレコードにアクセスして
ルートディレクトリのインデックスからfooという名前のエントリを探してfooの内部IDを取得する
それを元にMFTのfooのレコードにアクセスしてそのインデックスからbar.txtの内部IDを取得
MFTのbar.txtのレコードにアクセスしてbar.txtの中身が保存されてるDiskの位置を把握して
そこからデータを読み込む
B-Treeはディレクトリの中に多くのファイルがあっても
O(log n)で検索(や追加や削除)ができるようにするため >>531
触ったこともないようだなｗ
ＤＢサーバーはサーバーゆえ、セッション管理は当たり前
メモリだけでなく一時テーブルも他セッションから見えない
アクセス権の設定もＯＳよりフレキシブルかつ堅牢
扱うものがファイルじゃなく重要な大量データなので、そこらへんはＯＳよりむしろ高性能 そもそも「オブジェクト指向」言いたがるのは開発系にはいない
使ってはいても
むしろ腕がいいほど言わない
言いたがるのは手配師やＰＭなどの「営業系」
または本格的に開発しない「保守系」 >>562
>そもそも「オブジェクト指向」言いたがるのは開発系にはいない
チンポは随意筋であると同時に不随意筋である！ アラン・ケイ？ SmallTalkってカプセル化てんこ盛りじゃなかったっけ？ 自己増殖していくんだから、カプセル化しなかったらまずいべ。 >>560
超詳しいですね、ありがとうございます！ >>543
面白い点だね
若い頃、ディレクトリ構造のようなマスタを発想したことがあった
階層が動的だと物凄く重くなる
泥臭いが有限、固定であることが速さの秘訣
型も可変長より固定長の方が速いのと同じ
ＤＢ内部では可変長も固定長のように扱うからファイルもメモリも容量がデカい
容量を犠牲に速度を上げてる
容量はさておき、固定の速さを利用する設計思想も「ＤＢ型ＯＳ」には重要
「ＤＢ型ＯＳ」では、「Ａ￥Ｂ￥Ｃ」まで一気に「パス」という名の列に入ってるのか
「Ａ」「Ｂ」「Ｃ」が「フォルダ１」「フォルダ２」「フォルダ３」という３列に入ってるのか
少なくとも、ＸＭＬのような階層表現や、リレーションで動的に無制限に階層を持つ構造にはしない方がいい
「フォルダ１」「フォルダ２」「フォルダ３」は泥臭いが、その方が速度も速く、実は可用性も高い >>134
>カプセル化とはなにか？超わかりやすく解説します！
俺が寝ている時も俺の知らない時に、パンツの中でチンポが勝手に夢精してましたということだな。
つまりオブジェクトは独立であり、チンポは独立した生き物であり、独立したオブジェクトカプセルなのだと。 >>541
オシッコ残量はチンポではなくて膀胱の働きだからな。それは膀胱からのメッセージングによる。 デルファイがクラス型オブジェクト指向だと知らんような素人が
「オブジェクト指向じゃないと駄目なんです！」とか力説するもの（某リクルートの姉ちゃん）
もっと言うと、「クラス型オブジェクト指向」でなく「オブジェクト指向」と言うならば、ＶＢＡだってそうだよｗ
ＶＢＡでも「クラス」を宣言できるので、「クラス型オブジェクト指向」としか言いようがないのだが、
継承機能がないので、百歩譲って「クラス型オブジェクト指向」からは除外する約束でもいいが ところでWindowsがオブジェクト指向なのかというと、設計思想はそうだと言い難い
それは別スレに書いたが、およそ「デスクトップにオブジェクトを置く」感覚ではない
それはＭａｃ
オブジェクト指向はいろんな角度で串刺しにできる機能（ポリモーフィズム）を持つが、
それは「串刺しにされても我が道を行く」というオブジェクトの主体性を意味するものであって、
できるからってごちゃごちゃ串刺しすると、物感がなくなる Ｍａｃが始めた、なんでもクリック、長押し、ドラッグ＆ドロップで表現するのはたしかに串刺しだが
物感を強調するための串刺し
だがWindowsはこれを真似するにあたり、「右クリック」を導入した
物を「右クリック」するとはなんぞや
ここにコマンド思想がある
それは些細なことだが、スタートメニュー、レジストリ、ＡｐｐＤａｔａなど、物感からの乖離が多い >>561
ねぇねぇプロセス管理は？
→お前「セッション管理は～」
レスしたのに質問に答えられない時点で、お前の負けだ（笑） >>571
> ところでWindowsがオブジェクト指向なのかというと
オブジェクト指向だね
例えばウインドウがそう。実はWindowsは
ボタンやインプットボックスなどあらゆるコンポーネントが
ウインドウとして作られていて、ウインドウハンドルを持っている
基本のウインドウがあってそれを拡張して
コンポーネントが作られてる
もちろん自分で拡張することも可能 一般人は、数学空間に現実の問題を写像して解きます。
直接計算できるようになるからです。
アウアウアーは、現実空間に数学の問題でさえ写像しようとします。
これがオブジェクト指向です。
当然直接計算できません。
天才は、数学空間に写像された問題を計算機に解かせようとします。
これが関数型です。 オブジェクト指向の功績は、アウアウアーでも理解できるモデルを提供したことです。
オブジェクト志向の罪は、一般人をアウアウアーのレベルで作業させることです。 このようにオブジェクト指向いう「技術」の問題と「人」の問題を
わざとごちゃまぜにするやつに話を聞いてはいけません インタフェイスと実装を区別せずに議論してるような気がするが、スレの趣旨にあっていないような気がするので他所でやって欲しいと思いました。 >>577
〈このようにオブジェクト指向いう「技術」の問題と「人」の問題を
チンポは繋がっているけど独立している！ >>405
>スタートアップである弊社が全員ほぼ未経験でRuby on RailsをScalaに移行した理由、
Rubyとかの所謂「オブジェクト指向言語プログラミング」がここ十年くらいで落ち目なのは、
オブジェクト指向の何たるかを理解しないプログラマーが、オブジェクト指向言語プログラミングと称して、
使い道の無いコードを沢山書いたからだと思うぞ。要らない書類ばかり増えると整理が大変。 オブジェクト指向とは何かが分からないのに、オブジェクト指向プログラミング言語だと言ったりすると、
何だかこの人頭がイイみたいな錯覚を抱かせてしまう。
パソコンが苦手な人から見れば、パソコンが使えて書類を沢山作る人は頭がイイと錯覚してしまう。
トヨタ式「整理整頓」使わない書類は1日、名刺は1年で処分
https://president.jp/articles/-/16215
どんなに見た目がキレイに書けていても、使い道の無い書類は百害あって一利無し！ オブジェクト指向とは何か、関数型とは何か
端的に一言で言える人はいないのか 何となくイメージはあるけど、例えば多重継承はオブジェクト指向かと言われると多重継承が無くてもオブジェクト指向は成立しうるよなとか思ってしまうし、
結構人によってイメージの持ち方に幅があるような気がするなあ。
教科書的な定義とか解釈とかは進化が止まって化石になってから出来上がるような気がするし。 >>586
オブジェクト指向とはオブジェクトを物事の中心に据えること
関数型とは引数によって結果が決まる数学的な関数を物事の中心に据えること プログラムを構成する各オブジェクトは
言わば人間を構成する各臓器
心臓も肝臓もその詳細を知らず命令せずとも
責務を果たしている >>587
前にどこかに書いたが、オブジェクト指向＝多重継承とかいう話ではなくて
オブジェクト指向を行うのに便利な多重継承などの機能を集めたものが
オブジェクト指向言語なんだよ
多重継承はオブジェクト指向か？という疑問は
for文は手続き型に必要か？なくてもwhileやloopで代用できると言ってるようなもん
多重継承はオブジェクト指向を行うのに便利な機能の１つ
機能の１つでしかないから、なくても成立するのは当たり前 オブジェクト指向の功罪の「罪」の部分って、
多重継承が原因じゃないかなと個人的には思う。
作るときは便利なんでついつい使っちゃうけど、
メンテナンスするのに非常にしんどくなる。 >>589
>心臓も肝臓もその詳細を知らず命令せずとも
人間の体のように個々のオブジェクトの有機的な相互作用によってシステム全体が構築されている場合
ある入力(食べ物/薬/ストレス/運動など)に対してどういう出力が得られるか
どういう副作用が発生しうるかを把握するのが困難
オブジェクト指向で作られたシステムも同じで
オブジェクト間にどういう相互作用があって、どういう風に副作用が連鎖していくかがわかりにくくなりがち
そうならないようにする対策の一つとして関数型の考え方が取り入れられてる >>591
多重継承はついつい使っちゃうもんじゃないですねぇ
最終手段として使えれば便利とは思うけど
いつ使うんですかそんなもの
あなた本当に使ってますか？
てきとーなこといってオブジェクト指向ディスってるようにしか見えません 例えば動物クラスを継承して、犬クラスを作るなら自然だけど
動物クラスを継承した猫クラスがあるとして、ペットショップクラスを犬クラスと猫クラスの多重継承で作れないの？というのが初心者
極端すぎるけどこの場合はペットショップクラス内に動物クラスのインスタンスを管理するように作るべきだと思う >>595
自然かどうかはドメイン次第
そもそもペットショップクラスが必要なアプリってどういうものを想定したの？ 動物とか架空の例ばかりで、
実際に多重継承を使った実例をいわないのが
お前使ってないでしょっていう理由なんだわｗ あれだな。多重継承をディスるためにわざわざ多重継承が
使えそうな「例」を持ち出してる感100%だ そのクラスに属するメソッドをいい意味でも悪い意味でも結合させてしまうわけで
馬鹿は使うなってことになるわけだよ。 バカが作ると、とりあえず動くかもしれないけど
動作効率や保守性悪くなりがち
となるのは言語・パラダイムを問わず起こり得ること そう。「バカが使うと～」と言い出すと何にでも当てはまるので
「人」と「技術」の話は分けて考えろといってる 本来の意味での多重継承は現在では使われて無い
メソッド集や関数集を本体にドッキングさせたいときに使ってる
Javaに実装の書けるインタフェイスが出来たのもその為
Rubyのmix-inはそれ
つまり、ただの構造体にどうやって関数を足すかが、C++での現在の多重継承 >>603
>本来の意味での多重継承は現在では使われて無い
随意筋 不随意筋
↖ ↗
チンポ >>586
結局はどっちも宣言的プログラミングをする為の手段と言う認識。
手続き型言語のままで宣言的プログラミングをしようとしてオブジェクト指向プログラミングが出来たんじゃないかな。
でも、関数やメソッドにするべき処理は無数(無限)にあるので全ての処理をメソッド呼び出しやメソッドチェーンで記述する事は不可能。
結果としてどんなにクラスやメソッドが増えても全てを宣言的に書けず、どこかに必ず手続き的な記述が必要。
関数型言語は基本的な記述からして宣言的なので全部を宣言的に書ける。
ただ、状態を持たないと言うことはなんでも一から計算するので手続き型言語より遅い処理がある。
(例えば文字列の長さはオブジェクト指向プログラミングでは文字列オブジェクトそのものが生成された時点で文字数を内部に持っているが、関数型言語は必ず数える処理が入る) >>605
バカかよ
win32apiだってウィンドウハンドル渡してるだろ >>606
？
GUIは副産物であって目的じゃないよ？ 状態を持たないから全部1から計算とかプログラマやめろってレベルじゃねーぞチンパン >>602
人と技術は結びついてるんだから仕方ないだろ。
気にしないでいいなら変数名なんて全部1最小文字数でよいし、全部グローバルにしても
人が克服すりゃいいって話になる。 > 人と技術は結びついてるんだから仕方ないだろ。
明確にすればいいだけ
つまり、技術的には○○の方が優れているが
うちの人材は技術力が低いので優れた技術を使えない
と認めた上で、○○を使わないっていうのはいいんだよ
〇〇は技術的にだめという嘘をつかなければいい
技術力が低いと認めればいいだけ 例
× ローカル変数？ありゃだめだ？意味がわからない
グローバル変数のほうがいい
↑
技術のせいにしてるからNG
○ ローカル変数のほうが良いようだが俺には使いこなせない。
俺の技術力が低いからグローバル変数を使っている。
↑
人の問題だと認めてるからOK >>589
本人が知らないうちに膵臓ガンが出来てましたというか自覚症状が無いのも、オブジェクトカプセルだから。 >>604
多重継承がなぜ必要かというと、オブジェクトの上位概念は時と場合によぅて変わる時があるからだ。
例えばオシッコのチンポは随意筋で、射精のチンポは不随意筋である。 has-aの関係とis-aの関係で
継承かコンポジションか判断するのが基本だと思うけど
随意筋とか不随意筋はチンポからしたらhas-aの関係なのか
is-aの関係なのか どっちだ？！ 831 デフォルトの名無しさん sage 2018/11/11(日) 10:00:59.18 ID:Tyd11AGx
たとえば、CycはFredという名前の男がドナルドダックのモノマネをするという話が理解できなかった。
Cycの推論エンジンは、この話の中に矛盾を見つけた。Cycは人間には羽がないことは知っているが、
アヒルのように歩き、アヒルのように鳴くものはアヒルに違いないと考えた。
したがって、CycはFredがドナルドダックのモノマネしている間、
Fredはそれでも人間なのかと尋ねた。
925 デフォルトの名無しさん 2018/11/21(水) 18:36:07.42 ID:8Yc2p7H1
>>919
＞そもそもアランケイの言う「実行中」は「起動中」であって
＞「使用中」じゃないんだろう。マルチユーザーで誰かが使用している最中に
チンポがシコシコしている間、俺はそれでも俺なのかと尋ねた。
829 デフォルトの名無しさん 2018/11/11(日) 09:52:59.70 ID:y84pWKv0
（第1章 はじめに 2頁）
たとえば、CycはFredという名前の男が朝にひげをそるという話が理解できなかった。
Cycの推論エンジンは、この話の中に矛盾を見つけた。Cycは人間には電気の部品がないことは知っているが、
Fredが電気カミソリを持っていたので、エンティティ「Fredがひげそり中(FredWhileShaving)」
には電気の部品が含まれていると考えた。したがって、CycはFredがひげをそっている間、
Fredはそれでも人間なのかと尋ねた。
『深層学習』
著者:
Ian Goodfellow, イアングッドフェロー,
Yoshua Bengio, ヨシュアベンジオ,
Aaron Courville, アーロンカービル >>533
医学的にチンポは不随意筋だけど、心臓のように常に恒常的に動いているわけではないし、
オシッコを出したり止めたりは随意筋として動かすことも出来てしまう。
>>616
自分の体の一部としてのコンポジションであるのと同時に、自分の意志とは無関係に勃起する継承クラス。
繋がっているコンポジションであり、かつ独立した主体として振る舞う。 >>539
クリントン大統領といえどもチンポは独立主体であり、かつチンポがシコシコしてしまうと、
チンポは大統領権限をも超えてチンポがホワイトハウスを支配してしまう。 >>539
>クリントンの「不適切な関係」
チンポがシコシコしてしまったのは、大統領に悪意があったわけではないが、所有者責任は免れない。
飼い犬が歩行人に噛み付いたら、飼い主に管理者責任が生じるというのと同じ。 >>550
夏目くんは何も悪いことはしていないセクハラではない、チンポが勝手にシコシコしまっただけ。 >>612
グローバル変数なら一行で済むとか言えば技術的にグローバル変数のが優れてることになるが？
グローバル変数を管理できないお前の技術がないといわれたらどうすんの？
少なくともCPUからしたらそうだが。
技術的ってのがそれこそ人間の認識能力の前提によってるってことに全く気付かない馬鹿なのかな？ >>622
頭悪そうｗ
ようするにね、優秀な人（Googleレベルでいいよ）が
優れた技術だって言っていれば、技術は優れてるってこと
その技術が使えない人がいたなら、それは技術じゃなくて
人間の問題だってこと 技術が優れてるかどうかの判断基準や観点の違いでしょ
その基準の一つに頭悪い人でも使いやすいかどうかというのがあっても何もおかしくない
物事を一面的にしか捉えられない人はソフトウェアの仕事には向かない >>605
関数型プログラミングで使われるデータ構造は
状態を持たないわけじゃなくて状態が不変なだけだと思うよ
状態を変えるときはオブジェクトを作り直す感じ
文字列のオブジェクトは関数型言語じゃなくても不変なのが一般的だと思うよ >>624
>技術が優れてるかどうかの判断基準や観点の違いでしょ
他所で広く使われているか、という指標はどうだろうか？
使われるコードは良いコード、使われないコードは悪いコード。デファクトスタンダードという言葉もある。 多重継承は曖昧だというが、自然言語処理はその曖昧さが大切になる。チンポは随意筋であり不随意筋である。
最終的に，クラス階層は最上位クラスを含めた
最大8 階層から構成され，「伝統的な日本の絵画」
に属する用語に対応する 55 クラスと解説文中か
ら抽出した139 クラスが配置された。ただし，そ
のうち 32 クラスが複数の上位クラスをもつとい
う多重継承が示された。例えば，「ngyc:絵巻物」
は「ngyc:伝統的な日本の絵画」と，「ngyc:表具の
形式」の下位クラスである「ngyc:巻子」の 2 つの
クラスを継承する（図 2）。こうした多重継承は，
本質属性をもつ基本概念と機能を表すロール概念
を分離することで，基本概念による属性継承に限
った階層関係に変更するという考え方もあり 10)，
「ngyc:伝統的な日本の絵画」がロール概念で，
「ngyc:表具の形式」が基本概念と捉えることもで
きる。しかし，本研究ではテキストからの情報抽
出に即して配置し，多重継承を許容した階層を導
き出した。
http://www.mslis.jp/am2019yoko/05_kobayashi.pdf 数人月の仕事なら何だって良いさ
時間貰えばコードの隅から隅まで読んで把握出来る
みずほのサグラダ・ファミリアがグローバル変数で完成するならそういう話をしてよ カプセル化とはオブジェクトの独立性でありオブジェクトカプセルのことだ！
>>64
>設計的にはイベントというかメッセージ以外のアクセスを許さないためのカプセル化だろ？
洋式便器に座ってオシッコを出したり止めたりするのに、チンポがどうなっているかを確かめる必要無いだろ？
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く ＿w 、... ｮ ┌┐ ｨ ′
￣＋ ﾍe、 j｢. .￢气￢''..~''~ ,．ﾙw、.ｰu、す
^^"~~l|~~^''' ｫ′ .,. l| ┐ .√ j| _~+,.、.
. .,/. ょ＿／ ､j｢ ｛ `￢.. 〃 .、l| ､
.. ~＾. ~ ` ~＾
. ；. ｮ ＿_
. j| ~ラ￢￢+ |. ￣. ￣..
. ｵ ｜.. ｫ ,､
k、 ,j〃. Ｌ＿. _ｪ ~'――'~. ^^^^^^￣´
￣′ ￣￣ ＞例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
当然ながら起きているときも、チンポがシコシコする！
風呂から出て体一杯に水を浴びながら竜哉は、この時始めて英子に対する心を決めた。裸の上半身にタオルをかけ、
離れに上ると彼は障子の外から声を掛けた。
「英子さん」
部屋の英子がこちらを向いた気配に、彼は勃○した陰○を外から障子に突きたてた。障子は乾いた音をたてて破れ、
それを見た英子は読んでいた本を力一杯障子にぶつけたのだ。本は見事、的に当って畳に落ちた。
その瞬間、竜哉は体中が引き締まるような快感を感じた。彼は今、リングで感じるあのギラギラした、
抵抗される人間の喜びを味わったのだ。
●これが衝撃の「障子破り」シーンだ！ （石原慎太郎 『太陽の季節』 （新潮文庫） より）
＞その瞬間、竜哉は体中が引き締まるような快感を感じた
チンポがシコシコする≠勃起、つまりそれはただチンポが勃起するのではなくて、
「体中が引き締まるような快感を感じた」ということなのである！！ >>624
> その基準の一つに頭悪い人でも使いやすいかどうかというのがあっても何もおかしくない
それが本当に 頭悪い人 "でも" 使いやすいのであれば
頭が良い人でも使いやすいんだよ
頭が良くなるにつれて、使いづらくなるものは
それは技術ではなく人の問題になってる >>623
>優秀な人（Googleレベルでいいよ）が優れた技術だって言っていれば
問『なぜ、人を殺してはいけないのか？』
答『この社会の法律でそういうことになっているから』
問『トランプ大統領は原爆素晴らしいと言ってるぞ？』
答『アメリカ大統領に日本の法律は通じない』 >>634
関係ない話ですね。
技術の話をしましょう 優れた技術とやらが常に新しいシステムのことだとすれば、
>>611
>うちの人材は技術力が低いので優れた技術を使えない
Windows 7の2023年までの延長サポート、あらゆる企業が購入可能に Microsoftが方針転換
https://www.itmedia.co.jp/news/spv/1910/03/news091.html
古いシステムを使っている企業は、技術力低いということになるのか？ 優れた技術が常に新しいシステムなんて言ってませんね
言ってない話を前提にしてるので
レスするだけ無駄ですね >>635
偉い人が言うことだから正しいってのはお里が知れてるってことなんだが？ >>638
はい、それも言ってませんね
なんでいちいちデマ流すんですか？
こうやって俺がバラすから効果ないですよ？
偉い人じゃなくて、専門家の言うことだから正しい >>637
優れた技術とやらが、例えばナチスドイツの軍事技術だとすれば非常に馬鹿げていると思うぞ。
ソビエトのバグラチオン作戦でナチの精鋭は壊滅、ジェット機やミサイル兵器は役に立たなかった。 > 優れた技術とやらが、例えばナチスドイツの軍事技術だとすれば
それもいってませんねｗ
まいどまいど印象操作 >>639
>専門家の言うことだから正しい
STAP細胞論文の責任著者の一人である理化学研究所の笹井芳樹氏が8月5日、死亡した。52歳だった。
神戸市の先端医療センターの関連施設の階段5階の踊り場で、ひも状のもので首を吊っていたという。
遺書らしきものが見つかっており、兵庫県警では自殺を図ったとみている。
https://m.huffingtonpost.jp/2014/08/04/sasaiyoshiki-attempt-suicide_n_5649588.html
新井紀子教授のAIやコンピュータに関する知識は素人に毛が生えた程度
新井紀子教授の『AI vs. 教科書が読めない子どもたち』という本が大変売れているようです。
私も本を購入し精読させていただきました。
一言で感想を言うと、新井紀子教授のAI技術に関する知識はせいぜいAI関連ニュースに詳しい人レベルであり、
そのベースであるコンピュータに関する知識もほぼ素人だということがわかりました。
https://mywarstory.tokyo/inconvenient-truth/ 24 名無しさん＠ｺﾞｰｺﾞｰｺﾞｰｺﾞｰ！ (JP 0H82-LX7o [153.145.207.163]) 2019/11/23(土) 16:54:55.03 ID:l9637O/lH
https://i.imgur.com/1VuRIrP.jpg >>586
あんま難しく考えなくて良いと思う。
ただの解釈の違い。
オブジェクト指向は手続き型言語にグローバル変数を減らす為に、グローバル変数とそれ必要とする複数の関数をさらに包み込む物を用意した。
関数型言語は関数の引数や、関数の中でのみ変数を書き換えられると言う制約でグローバル変数の危険性を回避した。
手続き型言語(Python)
def fib( n):
temp = 0
a = 0
b = 1
for i in range( n):
temp = a
a = b
b += temp
return a
Haskell
fib n = fib’ n 0 1
where
fib’ 0 a _ = a
fib’ n a b = fib’ (n–1) b (b + a)
オブジェクト指向と関数型のどっちがどうと言うのは知らんけど、Haskellと言うか圏論の考え方は面白いとは思うよ。
視野を広げる意味でもHaskellは学んで損は無いと思う。
入出力も圏論的にはキーボードそのものを変数の様な物と捉える。
値が入ってくる方向が違うと言う意味では虚数と実数の関係に似ている。
readLn >>= \x -> (2 * x)
f x = (2 * x)
カリー化するとより似てる。
readLn >>= (2*)
f = (2*)
また、変数も引数の無い関数と捉えられる。
main関数はmain変数と言う見方も出来るし、x = 2は常に2を返す関数xとも捉えられる。 x readLn >>= \x -> (2 * x)
o readLn >>= \x -> print (2 * x)
x readLn >>= (2*)
o readLn >>= print.(2*) カプセル化が悪いんじゃなくてせっかくのカプセル化をぶち壊すのが悪いんだ 「内部には高電圧部があり感電する危険がありますから
サービスエンジニア以外は分解改造してはいけません」 >>653
ソースコード公開されていたからって素人が改造したらだめだよな
特にセキュリティ部分とか 詫びソースコード
アイミョン
[KS108-054]
テーマ：冒険者の広場・DQXショップ2020/02/17 16:22
今月になってから急にシステム障害が多発しており、運営としては説明責任を果たすべきと考えます。
https://hiroba.dqx.jp/sc/news/category/3/
不具合を出した個所とその修正箇所の両方を「詫びソースコード」として開示するのです。
ソースコードも企業の重要な著作物ですが、だからこそ開示して詫びることが大切です。
それと同時にシステムの不具合がなぜ多発しているのかを、プレイヤーも一緒に考えるのです。
バンダイナムコゲームスの『ドラゴンボールZ ドッカンバトル』を見習うべきです。
https://i.imgur.com/QHVwmj5.jpg >>586
>オブジェクト指向とは何か、関数型とは何か
勃起するときのチンポはオブジェクト指向、オシッコする時のチンポは関数型。
自らの意志で勃起し射精する独立型と、オシッコを出したり止めたりの制御型とを区別することが大切。 カプセル化って悪いことなのか？
俺にとってはメリットしかないと思ってるのだが。
>>2のような例はカプセル化が問題なのではなくて、設計の問題だろう。
必要なデータにアクセスできないような設計になっているのが悪い。
知られてはイケナイ情報は隠蔽すべきだろう。
カプセル化を否定するということは、自動販売機に向かって
「いくら銭が貯まってるのか見せろ」などと言ってるようなもん。
パソコンの電源ユニットも勝手に分解できないように封印がされてるし、
女の子のパンティーも隠蔽されている。 >>589
人体を扱う医学分野とか自然言語処理とかでは、ますますオブジェクト指向が大切になってくるよな。
機械的に統計取るだけならグローバル変数でもいいけど、人間科学生態科学は独立性を抜きには考えられない。 オブジェクト指向とは、Rubyのような所謂オブジェクト指向プログラミング言語のことではない！
つまりオブジェクト指向とは、俺の股間に付いているモノに他ならない！ いくら熱心に勉強しても
チンポの事しか話せないなら意味がないな
誰もいないスレに1人で連投してスレを汚すんじゃない >>660
ならオブジェクト指向とは何かを、自分の言葉で簡潔に述べてみろ！ 大規模システムを小さい多数のコンポーネントに分割することで
管理しやすくし、複数人での並行開発を行えるようにする技術かな >>662
では「オブジェクトの多重継承」とは何か？ そして多重継承はなぜ必要なのか？ >>633
> では「オブジェクトの多重継承」とは何か？
２つのオブジェクトを継承（実装を伴うもの）したいときに使うもの
> そして多重継承はなぜ必要なのか？
オブジェクト指向が提供する技術はどれも必須ではない
技術は必要かどうかではなく、何かを実現したい時（必要な時）に使うもの
言葉自体がおかしい オブジェクト指向がコンポーネント技術の需要から始まったことは周知のとおりだが、コンポーネント化のアイデアそのものが誤りだった可能性もあるな。 >>665
お前の意見は中身が無いので
コンポーネント化のアイデアは正しかった可能性もある
というふうに、簡単に言い返すことが出来る >>666
可能性があると言うより、正しいと信じて邁進してきた。
ところがどうも間違ってるような気がするんだよな。 オブジェクト指向の限界は皆が感じていて、これから学ぼうとする初心者たちがオブジェクト指向が良いものだと言ってる状況では？
間違っていた可能性があると言うだけで、ほとんどの人には十分だと思う。 なにが十分なのわからないが？
例えば推理もの小説でその人が犯人だという証拠があがってる中、
ヘボ探偵が、その人犯人じゃない可能性がある！と言った所で
その後に理由をいわなければ、何の意味もないことぐらいわかるでしょｗ 麻酔針犯人プッシュ!
コナン（ボイスチェンジャー）「私が犯人デス!」
コレ だからオブジェクト指向も理解できてない素人を真面目に相手にするなって 推理ものだと思うのはこれからオブジェクト指向を学ぶ初心者でしょ。
オブジェクト指向を使いこなしてきた人にとっては合意の取れた事実だから。
オブジェクト指向をこれから学ぼうとする初心者が話に加わろうとする気持ちはわからんでもないが、おまえにはまだ早いという人が居るのも無理からぬ話。 > おまえにはまだ早いという人が
また人の話にすり替えたｗ STLが非常に参考になる。
もちろん、これからの時代にSTLレベルでは話にならない。
思考の出発点として素晴らしい。 STLってなんだよ
Standard Template Languageか？
最近おぼえた単語を言いたくてしょうがないって感じだなｗ コンポーネントというのは、バベルの塔だったんじゃないかと思ってな。 コンポーネントって単語も最近覚えたんだね
よかったでちゅね～ >>672
>だからオブジェクト指向も理解できてない素人を
ならば「チンポがシコシコする」という日本語表現は、文法的に正しいのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ 例えば具体的にいかなる形で「分割」するかだが、
>>662
>大規模システムを小さい多数のコンポーネントに分割することで
まず自分とチンポを分割すること。チンポは独立した生き物で、チンポは自分の意志で勃起してシコシコする。 「画面上に4個のボタンがある」
ボタンのように見せかけてるだけで、ボタンじゃないんだよ。
だから、ボタンとして分割することはできない。 コンポーネントに分割することで管理しやすくするというだけなら、関数型や非オブジェクト指向の手続型でも共通のような。
コンポーネント化の単位として、オブジェクトを選択したことの優位性如何というのがポイントになってくるのでは。 4個のON/OFFボタンは4ビットで表せる。
HDグラフィックスは3MB程度。
ということは、4ビット入力して3MB出力するような関数があれば良いと考える。
ここが出発点じゃないか？ >>685
関数型がなんなのかわかってれば、そもそもそんなこと言えんわ。 C++のSTLはLispの超進化バージョンだから関数型への回帰に見える
要するに汎用的な関数を作りたいんだろう
テンプレートを使った万能な関数を作りたいワケだ
C++というかプログラミング言語の狙いはそこ（万能な関数）にある
例えばmax関数一つ作るだけで、どんな型でも最大値を出せる……てのが理想だ ジェネリック知らないのかな？
Lispは動的言語だからSTLとの比較で進化も退化もない 関数型が出せなければ、Windowsも終わるだろうな。 Haskellでコンパイラ作ったけど処理が遅かったからモナド使って
完成したものは手続き型言語で書いたものと変わらなかったみたいな話をみたことがある
関数型でOSは厳しいのじゃないかな
関数型は銀の弾丸ではないよ >>691
自然言語処理だと5万次元ベクトルとか普通にあるし。
何も不思議な話じゃない。
オブジェクト指向に毒されて、その殻の外を考えられなくなってるのでは？
殻を破れ。 冒頭の繰り返しになりますが、オントロジーは「情報の意味を定義するための概念」であり、その適用範囲は
広義なものです。更にオントロジーだけではなく、LDやRDFといった周辺技術の関連性を理解してないと
学習初期で混乱することになります。本記事がこれからオントロジーを学ぼうとする方の一助になれば幸いです。
https://qiita.com/mininobu/items/bce0e0ad97ed17e0aff2 中国の味の素と言えば李錦記。
オイスターソースを発明した会社だ。 カプセル化ってstaticの事じゃないの？ そう習ったような気が、、、 愚かなの？ C++ってガチのマルチパラダイムだよね
手続き型 オブジェクト指向
そしてテンプレートメタプログラミングは関数型 >>692
Haskellが遅いのは遅延評価だからだよ。(速度より表現力を取った)
モナドは関係無いし、モナドで解決するならとっくにHaskellは速くなってる。
モナドは順序の関係無い数学の世界(純粋関数型言語の世界)で逐次処理を再現する仕組み。
(重さの無い量子に重さを生み出すヒッグス粒子の様なもの)
HaskellでOSが作りにくいのは遅いのもだけど、Haskellのランタイムが大きいから。
C++が一定以上の規模じゃ無いと組み込みで使えないのと同じ。
Cみたいにランタイムが小さく無いとメモリに入りきらない。
C++よりランタイムが大きい上に遅いHaskellでOS作ろうと思うのは、余程の物好きだろう。 関数型プロセッサはSFだろう
無限の再帰に耐えれるCPUだがそんなものが出来るとは思えない スタックプロセッサ(だっけ？)とかLispに最適化したCPUが昔無かったっけ？
数の暴力でx86に潰されたけど。 関数OSの可能性が有るとすれば量子コンピュータかな。
純粋関数型言語はアーキテクチャに依存しないので、今でも紙と鉛筆で実行出来るし、理論上は文法そのまま量子コンピュータで動かせる。
まあ、今までの歴史振り返ればCなりをベースにした新言語を作って対応しそうだが。 それらの総称として、オイスタープロジェクトと呼ぶことにします。 いや、スタックプロセッサでは無限のスタックを用意すると数学的に正しい再帰が実現できる 文脈によって意味が変わる自然言語処理においては「多重継承」が大切。
状況によって、チンポは随意筋にも不随意筋にもなるし、自分自身にもなるし部下にも上司にもなる。
>>539
クリントンとチンポの関係は、部下と上司の関係が逆転してしまった例。 文系の人がプログラミングできるようにとの配慮からオブジェクト指向を推進してきたわけですが、理系には関数型のほうが思考しやすいと思います。
というのも、数式そのままに理解していけるからです。 ・多重継承
ものごとには唯一の本質があるとする存在論にお
いては多重継承が忌避されるかもしれない。しかし
現在の GUO では本質に関する議論を保留してお
り、多 重 継 承 を許 容 している。例 えば《人 間 》は
Agent と EnergyBearer を継 承 し、《パソコン》も
System と EnergyBearer、Artifact を継承する。また、
Agent は System を継承している（図 1）。
http://www.jaist.ac.jp/ks/labs/kbs-lab/sig-swo/papers/SIG-SWO-A602/SIG-SWO-A602-04.pdf オシッコするときのチンポは制御、
>>710
>理系には関数型のほうが思考しやすいと思います。
勃起するときのチンポは自律ね！
>数式そのままに理解していけるからです
ならばチンポが勃起する事象を「数式」で示せ！ >>710
How(どの様に =手続き)では無く、 What(それは何 =構造)で考えろも一緒に教えれば文系にも関数型言語は優しいと思うんだけどな。
lengthとはリストの中の値の個数分1を足した合計を返す関数である。
(要素1個1個を表すxは捨てて1を足すので_で使わない事を明記)
length [] = 0
length (_:xs) = 1 + length xs
リストの中の値の個数分1を足した合計なので、リスト内包表記でこうも書ける。
length xs = sum [ 1 | _ <- xs] オイスタープロジェクトでは、皆さんのご意見をお待ちしております。 「言葉の意味をどう定義するか」で、「概念ツリー」と「Has-aツリー」の話をしました。
どちらも、心のモデルを構成するものです。
「概念ツリー」とは、単語の意味の概念関係をツリーで表現したモデルです。
たとえば、「建物」概念の下には、「病院」「学校」「家」といった建物の下位概念が属します。
「学校」概念は、「小学校」や「中学校」、「大学」「東京大学」などの単語を持ちます。
このように、概念ツリーは、下位なほど具体的であり、上位なほど、抽象度が高くなります。
「Has-aツリー」は、「ＡはＢを持つ」という関係を表したものです。
たとえば、
「建物」は「ドア」、「窓」を持つ。
「学校」は、「先生」、「生徒」を持つ。
「病院」は、「医者」、「患者」、「看護師」を持つ。
といったデータモデルになっています。
「心のモデル」が、「概念ツリー」と「Has-aツリー」を持っていたとします。
そこから、このモデルに合致する単語をランダムに選び、文として出力させます。
たとえば、「建物は窓を持つ」といった風に。
特に、問題ないですよね。
こうやって、AIが出力する文を人間が判断していくわけです。
上位概念が持つものは、下位概念も持つので、
「学校は窓を持つ」
「小学校は窓を持つ」
といった文も出力されます。
https://robomind.co.jp/sizengengosyorihenoteigen4/
>>616
心のモデルの基礎はやはりチンポ！ そう言う意味じゃオブジェクト指向プログラミングも部品を組み合わせる様にプログラミングして行くので考え方としてはWhatだ。
でもクラスが用意されてない部分になると途端にHowになる。
そして>>605で書いた通りオブジェクト指向プログラミングではHow部分を駆逐出来ない。 オブジェクト指向プログラミング言語とオブジェクト指向は違う！
>>718
>オブジェクト指向プログラミングも部品を組み合わせる様にプログラミングして行くので
オブジェクト指向とは、繋がっているけれども独立しているという意味で、俺の股間に付いているモノだ！ オブジェクト指向とは、決してプログラミングの手法ではない！
>>718
>オブジェクト指向プログラミングも部品を組み合わせる様にプログラミングして行くので
オブジェクト指向とはまさに俺の股間に付いているのであって、それはプログラミングとは無関係である！ >>540
オシッコするときのチンポは「関数型」ね！ https://ja.wikipedia.org/wiki/関数型言語#関数型プログラミングの例
ＶＢＡで書くとこういうことですな
手続き型
Function fibona(num As Integer) As Integer
Dim x As Integer, y As Integer, tmp As Integer
x = 1: y = 1
For i = 2 To num
tmp = x: x = y: y = y + tmp
Next
fibona = y
End Function
関数型
Function fibona2(num As Integer) As Integer
If num < 2 Then fibona2 = 1 Else fibona2 = fibona2(num - 2) + fibona2(num - 1)
End Function
なるほど、「フィボナッチ数列は前２個を再帰的に足す」という要件が、下の方が見えやすいね
この場合は上の方が呪文
ただ下は要件は見えやすいが、なんとなくであって、動作に確証は持ちにくいわな
しかし引数が１０の時、上は９ループだけど下は１７７回！
それ専用の言語はうまくコンパイルするのかな フィボナッチはたぶんＳＱＬでは書けんね
ＳＱＬは全行同時処理するところに速さの秘訣があるので、逐次処理や再帰処理はその利点を生かせない
（Ｔ－ＳＱＬには制御文もあるので書くことは書けるが） 最低限SOLIDくらい理解してから語ってくれよ。。 Function fibona(num As Integer) As Integer
Dim i As Integer, x1 As Integer, x2 As Integer
x1 = 1: x2 = 1
For i = 2 To num
fibona = x1 + x2
x1 = x2
x2 = fibona
Next
End Function
（さっきのは i の宣言が抜けてた）
こう書けば「前の２個を足す」という意味が分かりやすいのでは？
何言語を使おうとセンスの問題だったり >>725
言われてググって思い出したが、昔ちらっと使ってみたことあったようななかったようなｗ
ＷＩＴＨって覚えてるな
遅いからやめたんだっけかな >>717
クリントン大統領もチンポがしこしこしてしまったのだが？ メッセージングとは「対話」ね！
>>155
>オブジェクト指向のコア概念メッセージングがなぜ提唱されたか察するに
オブジェクトは必ずオブジェクト同士の「対話」を伴う、これがメッセージングだ！
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く >>550
女子のブルマ姿に勃起してチンポがしこしこしてしまわないよう、あらかじめオナニーしとくことが大切。
それからチンポがしこしこしてしまった場合でも、急いでトイレに駆け込んでオナニーしておくことが大切。
オシッコが出るのか精液が出るのかは、本人にしかわからないことで「カプセル化」されている。 言葉の意味を追求しない統計的機械翻訳は、2010年のIBMワトソンでおしまい。
>現在の GUO では本質に関する議論を保留しており、多重継承を許容している。
自然言語のロゴスを徹底的に追求するには、オブジェクトの多重継承は必須！ とはいえ、これを with でどうやって書くのか、ちょっと思いつかん
（これは２個ずつ処理してるので変数でやった方がいい処理だが）
select n, f =1 into #n
from (
select n =1
union select n =2
) n;
while (select max(n) from #n)<=10
begin
insert #n
select n.n, f =isnull(n1.f+n2.f,1)
from (select n =max(n)+1 from #n) n
left join #n n1 on n1.n=n.n-1
left join #n n2 on n2.n=n.n-2
order by n.n desc;
end;
go_end:
select * from #n;
drop table #n; あれ、
order by n.n desc; ←これは余計 チンポがオシッコ出したり止めたり勃起したり射精したりするのは古今東西共通であり、
>>552
>俺が言ってるのは40にもなって
>オシッコとかチンポとか、恥ずかしくないのかってことなんだがｗ
恥ずかしがらずに「チンポがシコシコする」という新しい表現を受け入れることが大切！
「帽子」と言ってもいろんな帽子があるが、「チンポ」は一人につき一つであり、一対一の対話が可能！ クリントン大統領もチンポがシコシコしてしまったのであり、
>オントロジーは「情報の意味を定義するための概念」であり
官能小説はいくらでもあるし、アダルト映画もいくらでもある。チンポがシコシコという表現があれば、
アニメからホワイトハウスまであらゆるオントロジーを作成出来るはずだ！ >オントロジーは「情報の意味を定義するための概念」であり
977 デフォルトの名無しさん 2018/09/17(月) 07:24:42.74 ID:C7pw6n1T
自然言語処理の知識はゼロなのでわからないです。面白いアイデアだと思うので、Twitterの自然言語処理が専門の方々に聞いてみては？
https://peing.net/ja/q/417c9e29-35de-4c95-8323-afd6a50fcbc7
コンピューターのための自然言語理解シミュレ
ーターというのは可能ですか？
例えば第二次大戦の推移について、言葉ではな
くて動画で理解する方法もあります。
言葉で説明するよりもマインクラフトのような
創作ゲーム表現に変えたほうが分かりやすいで
す。
けれども自分が読み漁った人工知能や自然言語
処理の本にはそうしたアプローチは見つからな
かったです。
言語はただの記号の羅列で機械は現実世界を全
く知らない。でもそういうことなら、
テレビゲームのような仮想世界をインプットし
て、自然言語で操作したらいいと思います。
というか自然言語入力でときめきメモリアルみ
たいなゲームをやってみたいてす。 よくよく考えると、フィボナッチで「定義」通りにやってるのは手続き型
なので１０回の指定で９回計算し、途中経過を出力するとフィボナッチ数列になってる
関数型は最後のフィボナッチ数は出てくるが、１７７回も計算し、途中経過は意味不明な数字になってる
数列で欲しい場合、この関数を１０回使うか、手続き型の別の関数を用意することになる >>737
ループと同じにするならこうかと
Function Fibo(n, a, b)
If n = 1 Then
Fibo = b
Exit Function
End If
Fibo = Fibo(n - 1, b, a + b)
End Function ループの実装であっても
「関数は同じ引数を与えられた場合、同じ値を返す」
を満たすから参照透過性があると考えて
関数型プログラミングとみなしてもよいと僕は思います >>738
おお、これは
wiki は「関数っぽさ」の説明のためであって、ほんとはこうなのかな
共通テーブルは自己参照が１個しか書けないから、２個前が参照できず、
そのように前の加算結果も最新行に保持するしかないなと、思ったところで断念ｗ
declare @n int =0;
select n =@n into #n;
while @n<10 begin set @n =@n+1; insert #n select @n; end;
--↑整数マスタがあるとして
with nn(n, f, f1) as (
select n, f =1, f1 =0 from #n where n>=2 and n<=10
union all
select n.n, f =n1.f1, f1 =n1.f+n1.f1
from #n n inner join nn n1 on n1.n=n.n-1
)
select sum(f)+1 from nn;
drop table #n;
最後の＋１が逃げっぽいけどｗ
共通テーブルは１個の上に外部結合も許可されず（できたとろこでスマートになるかは不明）
しかし同じ発想のようで、そっちは途中経過が綺麗な数列
こっちは意味不明な４５レコード
その上、意味不明度が上がるのでやめた方がいいなｗ 共通テーブルのサンプルを見ると、２０年前の若気の至りを思い出すな
リレーショナルだから、２列のキーのみで可変階層がスマートじゃないかと
できるからって工事の積算なんかに使うと、えらいことになる
２０年前と今ではＰＣの性能違うだろうけど
現実には階層を固定で持っても十数列で済んだり、なんなら２５５列用意しても大したことない
泥臭くてもその方が圧倒的に速く、再利用性も高いのが現実 構造化プログラミングの再帰処理で階乗やディレクトリ探索しか例がない理由を考えたことあるのか。
逆に、分岐条件や判定が複雑に入り混じったいわゆる手続きを関数型で実現する例が少ない理由を考えたことがあるのか。
関数バカは死ね。 > 構造化プログラミングの再帰処理で階乗やディレクトリ探索しか例がない理由を考えたことあるのか。
再帰処理をしたことがない人でも知っているものだからだよ
> 逆に、分岐条件や判定が複雑に入り混じったいわゆる手続きを関数型で実現する例が
例として持ち出す時、手続き型でも分岐条件や判定が複雑に入り混じったっものは使わないよ
理由はこれでいいと思うけど、
なんで関数バカは死ねって最後に捨て台詞はいたの？ >>722
単純な再帰だと関数型言語でもスタック消費するけど、モナドのインスタンスになってる再帰関数や、末尾再帰はループにコンパイルされる。
(リストはモナドのインスタンスなので、リストを受け取ってリストを返す関数は再帰でもループになる。IOな関数も同じく)
手続き型言語でもC/C++とJavaScriptは末尾再帰のループ化は対応してる。 愚かな・・・なんて愚かな・・・
※戦場のピアニスト >>742
？
条件分岐や判定が複雑に入り混じった様なのは、むしろ関数型言語や論理型言語の得意分野だけど・・・。
今まで関数型言語が苦手と言うか、純粋さを捨てていた手続きってのは
putStrLn str
print n
みたいな戻り値が無い関数(voidな関数や戻り値を普段は使わない関数)が続く様な処理や入出力。
これを順番を保証するのが難しかった。
そこを圏論でプログラム丸ごと関数の様なものとして順番を保証しつつ参照透明性を確保する事で大きな意味での(個人的に純粋とは言わない気もするが)純粋関数型言語を実現した。
putStrLn str >>= \_ -> print n
上の糖衣構文
putStrLn str >> print n
do形式で手続き型言語っぽく(手続き型言語っぽいとはいえ、しっかり関数型言語なので一つの巨大な式に還元される)
do
putStrLn str
print n これからの時代、多態性よりポリリズムのほうが重要。 x,y,zをpos2d,zで持つことはないよねって100万回復唱しろ ネタスレのようだが
カプセル化は問題無い
隠蔽化が問題有る 単純に実行しないとインターフェースから先に飛ぶことができないのも読みにくい
更にそこから先の処理の可能性がインターフェースを持つクラス全部とかこれまた読みにくい
更にそのクラスのインスタンスの違いについても追わなきゃいけなくて結果としてゴミクズ カプセル化はいまいちメリットわからんよね
スコープの話なのに徹底できてない点がカプセル化の是非が定まらない原因 カプセル化したくせにSetterとかGetter作ってるやつ見ると
「オメェ、ここおかしんじゃねーのか？」
って言いたくなる
アクセスをイベントに限定したいのか？
誰でもいつでもアクセスしたいのかスタンスをハッキリさせろよｗ >>753
setterとgetterを準備するぐらいならいさぎよく
publicにした方が「私は」いいと思うけどな >>755
作るソース全部そんな感じの奴がいて邪魔くせぇ
wpfのINotifyPropertyChangedってさ関係ないイベントでも発火して制御できないよね
はじめはsetter、getterでやってたけどあかんわ
発火したいときとそうでないときと手動で分けられないとあかんわ
なんかこれ系のついでに何やらやっちゃおうシステムって開発終盤になると全部ゴミだな >>753
Java web appだと、lombock入れてカプセル化壊すのが当たり前になっちまった。
スマホアプリとか組み込み系とかでしっかりコーディングすればいいと諦めてる。
実際、Web アプリ界隈はバカばっかだし。割り切りも大切。 >>758
https://codezine.jp/article/detail/7274
> Javaは言語仕様上の制約により、ボイラープレートコード（自明だが省略できないお決まりのコード断片）が
> いくつかあります。例えば、メンバ変数を読み書きするだけのgetterメソッドやsetterメソッドがこれにあたります。
> Lombokを使えば、これらJava特有の冗長なコードを、見やすく簡潔なものにすることができます。
>
> LombokではEclipseのような自動生成ではなく、アノテーションを付与することにより
> ボイラープレートコードを実装したのと同じ効果を得ることができます。
単にプロパティをアノテーションで書けるってだけだよね？
これのどこがカプセル化破壊になるの？ >>760
それ、エラーチェックをしたいときはpublicメソッド呼び出しと
言ってるのと同じことだけど、何の関係があるの？ JavaBeansではセッタとメソッドは別の概念
セッタを通じて状態にアクセスすることでオブジェクトは
よりスマートになる 何がカプセル化だよ
settergetter使うなら丸出しと変わんねーよ これからの時代、多態性よりポリフェノールのほうが重要。 >>766
お前もしかしたら全てのメンバ変数に
setter/gette作ってんのか？
お前が丸出しにしてるだけだろｗ >>771
は？そもそもオブジェクト指向とか言うクソ使ってねーわ >>774
オブジェクト指向は既に俺の股間に付いているのだから、オブジェクト指向プログラミング言語は要らない！ だから適切なインターフェイス作成ができないなら素直に関数にしとけと。。
馬鹿に限って自分のクラス設計に自信持ってんだよな。。 CSSはJavascriptで実装されただけあって、仕様も混沌としてるな。
動的確保前提の設計なので、いちいちイラっとする。 教科書は「後で説明するので今はそういうものだと思ってください」というのは無い。
前から順番に読んでいくと、説明なく出てくるものが無いのである。
仕様を書くときは、教科書のように書くことを徹底する。
するとどうなるか？
相互参照が無くなるのである。
相互参照が無くなれば、変数の大きさは一意に決まる。
つまり不要不急の動的確保が無くなるのである。
これがC/C++の掟である。 >>779
1+1=2なんです。今はそういうものだと思ってください。
って最初からやってるぞｗ Javaのようなお猿さん言語はプリミティブ以外はすべて参照、つまり動的に確保される。
だからいつでもどこでも動的でいいのだなどと思わないでほしい。
あなた方はお猿さん。
そしてお猿さん用言語を使っている。
しかし、世の中には人間もいることを忘れないでほしい。
人間はもっと効率の良い設計を求めるものだ。 Javaのような人間用言語はプリミティブ以外はすべて参照、つまり動的に確保される。
というふうに入れ替えても問題ないんじゃね？ｗ 入れ替えた場合、C/C++は天才用言語になるからダメだ。 >>781
高校までの教科書は大学入ったら全部役に立たないよなω >>787
あれはただのwrapper以下だからなー MFCは30年前のライブラリだからな。
よくまあここまで生き残ったわ。 同じ時期かそれより前にあった OWL の方が10000倍マシだった >>779
Javaの教科書には
class Test {
public static void main(argv[]) {
System.out.println("Hello");
}
とりあえずこれで動きます。「あとで説明するので今はそういうものだと思ってください」
と堂々と書いてあるぞ。 >>794
× public static void main(argv[]) {
○ public static void main(String[] argv) { プロパティは、可変階層と同じく若気の興味本位系ではあるが
ベテランになってからも、いくつか使ったことはある
設定時処理のカプセル化
カプセル化と言っても隠したいわけじゃなく、設定する時に絶対にこの処理を通す、という便利機能
「発火」は未経験だが、下手な作りだとなり得る構造だね
ちゃんとできてたとしても、よほどの事情がない限り、普通の関数で書いた方がシンプルで理解もしやすいと思う
なぜ使ったのか、過去ソースを見てみたら、なるほどｗ
ＳＥＴ時だけでなくＧＥＴ時にも複雑な処理があるものがあり、これをそれぞれ関数で書くと、関数名が２倍に増える
少なくとも関数名の数を半分にする効能はある
言ってみれば１つの関数に２つの内部関数がある構造なので 関数でもできるな
引数が未設定ならＧＥＴ動作に切り替わると
実際そういう関数も作る
プロパティだと逆に２個になってしまう言語の場合 >>759
Lombok調べてきました感がw
お前が実務経験ないアマチュアってことはよくわかったから口出さないでくれ。 単純なValueオブジェクトはCとかだと
struct Color {
int r, g, b;
};
Color color;
int red = color.r;
みたいに書けるところをわざわざgetter/setter毎回作るの？
アホらしくない？ >>801
Valueオブジェクトって何か知ってる？ オブジェクト指向はフレームワーク実装者が意識すべきもの
フレームワーク利用者はその枠でただベタにアプリ実装すればよい
プロパティはフレームワーク実装側から見ると自分自身に対しては何も利益がないけど
フレームワーク利用者の行動をコントロールできるという点で利益がある ValueオブジェクトってDDD関連で出てくる単語だったのね
その意味では知らなかったけど、そんなこと聞きたいんじゃない >>801
必要なら作っていいし、必要ないならCみたいに書けばいい ホントかなぁJava触ってるやつらは
getter/setter使わず単にpublicフィールドにしたら
文句行ってきそうなイメージだったけど ValueObjectはReadOnlyが基本だからfinalにして変数をpublicにします オブジェクト指向に対する愚痴を延々と続ける人には主に2つのタイプがある。
1つはその人にとってオブジェクト指向が新しいパラダイムでありそれを受け入れる事が出来なかった老害タイプ。
もう1つはJavaを通してしかオブジェクト指向を理解しようとしないJava屋の土方タイプ。
両方の属性を持ったタイプが最もタチが悪い。 >>809
そもそも誰もメリット説明できてないけどねｗ >>810
メリットがわからないなら使わなければいいだけ メリットのつもりだけどちっともメリットになってないやつがいるよな
不必要な階層化が明らかにバグ増やしてるやつ
やめとけって >>779
ホントか？
https://ezoeryou.github.io/cpp-intro/
コレのHelloWorldには「コードの詳細な意味はさておくとして」とあるぞ C++のこれダサくない？
std::cout << "hello" ;
<<これダサくない？
イキりマンが設計したとしか思えない 明らかに (hoge)printf の方が使い易い C++でそれ使った事無かったなｗ
何故かhello worldではそのコードが書かれている事が多いけどｗ std::cout << "hello" << std::endl; ダサいけどprintfのセキュリティ的な問題がないから使っておる >>814
普段からLinuxを使ってないとその発想にならないと思う
PHPのほうが自然 >>809
「オブジェクト指向を妄信する人への揶揄」が「オブジェクト指向に対する愚痴」に見えている可能性 >>821
>「オブジェクト指向を妄信する人への揶揄」が
ならば「チンポがシコシコする」という日本語表現は、文法的に正しいのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ >>809
>1つはその人にとってオブジェクト指向が新しいパラダイムであり
俺の股間に付いているモノは「オブジェクト指向」とは違うのか？ >>804
フレームワーク作成者の
身の保身のために
無意味な作業何度もさせられるんか？
フレームワークだけやないで
大抵の既存クラスがそんなもんや >>811
老害のドカタに使わないという選択肢があると思うか？
選ぶ自由がない環境でしか生きられない上にリアルで相手にされないから5chで愚痴を言い続ける。
低脳低スキルを他者のせいにするメンタリティのやつには何言っても無駄よ。建設的議論にはなりえない。 >>810
「チンポがシコシコする」という日本語は、何かオカシイか？ >>825
イキってクソコード撒き散らす害悪よりかはマシだけどな。
お前のクソスキルはどうでもいいからとりあえず関数かけ馬鹿。 結局これ人間性の問題なのよ。
カプセル化を容認するような人間は、犯罪も容認するし、なにも守れない。 オポンティーヌと言えば、あわしろいくやを連想してしまうな。 オブジェクト指向否定する前に小学校の国語からやりなおせカス >>837
オブジェクト指向は俺の股間に付いているからな！ ズンドコベロンチョは至高！
ズンドコベロンチョ否定する前に小学校の国語からやりなおせカス
何にでも使える。 オブジェクト指向は設計を間違えるときついことが起こる。
C++みたいな純ではないのはその辺り、コードがわかりにくくなるだけでなんとか対応できる。 関数型言語は設計を間違えるときついことが起こる。
そして正しい設計の話は一切でない
ボタンを作るにはどうすればいいんだ？ >>842
GUI Toolkitしだいだと思うよ
F#ならnew Buttonで作れる >>839
「ズンドコベロンチョ」は、俺の股間に付いている！ >>843
> F#ならnew Buttonで作れる
そりゃオブジェクト指向の機能を使ってるからな >>845
関数型言語ではオブジェクト指向の機能を使います >>846
単に「オブジェクト指向の機能を使います」で十分でしょｗ >>848
どの言語でもオブジェクト指向を使うという話です。 >>849
つまり関数型言語ではオブジェクト指向の機能を使うってことですね > ボタンを作るにはどうすればいいんだ？
関数型言語だからといって悩む必要などないのです
ボタンはnew Buttonで作れます >>850
「関数型を名乗っている言語でも」っていうのが正確ですね
なので純粋な関数型では不可能なんです。 >>852
さっきも書いたように、それはオブジェクト指向の機能です。 F#はオブジェクト指向言語＋関数型言語
オブジェクト指向言語に関数型を取り入れた言語なんです。
純粋な関数型ではないんです。 >>854
関数型言語ではオブジェクト指向の機能を使います 結局の所、有用なものはすべてオブジェクト指向なんです。 関数型言語も有用なのでオブジェクト指向と言って良いでしょう オブジェクト指向関数型言語を省略したものが関数型言語なのでしょうね
オブジェクトを作れない、オブジェクトを操作できない関数型言語は存在しません >>849
オブジェクト指向は俺の股間に付いている！ >>657
どうにかして、そのパンティーに俺のおちんちんを突っ込みたい。 それも有用なのでオブジェクト指向と言って良いでしょう
結局、都合の良いことはすべてオブジェクト指向なんです オブジェクト指向の考え方が現れる以前も
有用なものは実はオブジェクト指向を使っていたんです そもそも関数型はオブジェクト指向の考え方から生まれた概念だったんです >>865
さすがあなたは分かっていらっしゃる
信じるものは救われる かも
ｻﾞｰﾒﾝ それは真理に対する冒涜です
オブジェクト指向は幻想だったのです 都市伝説、インチキ、ﾅﾝﾁｬｯﾃ工学モドキだったのです
でも、それを言っちゃー、お仕舞よ >>854
オシッコする時は制御型、勃起する時は自律型。 >>872
あらあら、隠蔽してるわね
これがカプセル化かしら >>814
思想的にはSICPに書いてるストリームそのものだ
ttps://sicp.iijlab.net/fulltext/x350.html なんでマキマはパワー殺したんや？
パワーちゃんを返せ！！(´；ω；｀)ﾌﾞﾜｯ 結局の所クローズドソース、外部ライブラリ全否定でしかないな
OS、ドライバ、アプリすべてを自分で作れが結論になってしまう歪んだ主張 関数型で、状態を持たせなければいい！じゃなくて
関数型で状態をどうやってもたせるかって話をしてくれ
状態っていうのはなくすのは不可能なものなんだ >>880
関数型言語一般の用語で言ってくれませんか？ 関数型にわかのうえに検索力も無い
関数型に憧れてるだけのアホ 関数型言語の「関数型」は
関数を変数として扱える＝関数型という変数の型を持っている
ということを表していて、
関数型言語を単純に定義すれば、関数型を持っている言語
ということでいいの？ 参照透過性があってメモ化が可能で状態の無いピュアな関数だけだから関数型だ >>887
それは関数型言語ないしは関数型言語によるプログラミングの理想形であって
関数型の定義というか要件ではないように思える
定義、要件、理想、本質、それによってもたらされた機能…
そういうのがごちゃ混ぜになって話がまとまらなくなってる気がする >>886
～型言語の「型」はdata typeの訳語ではなくて
ある特徴を持っているという意味だよ
最新型ノートパソコンの「型」と同じ働き >>880
レコードってタプルやコレクションと同列のただのデータ型じゃね？ 関数型プログラミングがわからない、
でも勉強したくないし、チュートリアル数ページすら読まない
こういう輩を相手に何言っても無駄
理解出来ないだけでなく、理解しようという気がないから privateがなくてpublicしかない構造体
内部データを持てない構造体 >>892
じゃあレコードでなければならない理由はないんだよな。 >>896
ないんじゃね、レコードしかないとは>>880さんは言ってないし ポインタ含む参照型がある言語は関数型ではない
関数型は参照型禁止、値型しか無い >>897
つまり>>880は「値作るだけじゃん」と読み替えても同じということ？ 状態が不変なら参照型も値型も扱い方は同じ
値のコピーを取る値型よりも参照型の方が効率的 >>900
違うんじゃね、>>880さんはレコードと言ってる
レコードと値は別のもの 関数型で状態管理するのは別にそんな複雑な話でもなくて、状態を戻り値にした関数作るだけだぞ。
コネクション管理だったりreduxの作りだったりで見かけたりはする。
別にいいとも悪いとも思わんが。 問題はその状態がpublicだから誰でも見れちゃうという所 >>904
いやそれがパブリックかどうかを気にするようなスコープで使ってることのが問題 >>902
>>880はレコード型の値を作ることを言っているかと思ったんだが？ >>906
>>880さんが言ってるのは「レコード作るだけじゃん」ってことだよ
読み直してごらん、それ以外のことを言ってない
>>906さんが「値作るだけじゃん」と言ったのであって
>>880さんはそんなこと言ってません >>880で作るといっていた「レコード」がレコード型の値のことでなければ何だったんだろうか。
まさかレコード型の方か？ >>908
レコードを作ると言ってるんだからレコードのことに決まってます マリオ「ドラキュラはにんにくが嫌いだ」
ルイージ「にんにくは野菜だからドラキュラはにんにくという野菜が嫌いなんだ」
ルイージ「ドラキュラは野菜が嫌いだとマリオが言っていたので
僕はとっておきのにんじんをドラキュラに投げつけてやるんです」 値でも型でもない「レコード」というと、はて…？
まさかデータベースとか円盤とかではあるまいが。 >>911
レコードは関数やオブジェクト、参照、ポインタって可能性もありますね
DBは正式にはタプルかな、CSVではフィールドの集まりと定義されてる いずれにしても>>880さんは「レコード作るだけじゃん」と言っておられるのだから
レコードを作るだけなんだなあと受け取るのが正しい理解 マリオ「ドラキュラはにんにくが嫌いだ」
正しいルイージ「ドラキュラはにんにくが嫌いなんだなあ」 おまえらはご飯論法とか藁人形論法ってやつから勉強しなおしだな >>913
つまり>>880は適当なことを言っていたので煙に巻こうとしていると。 >>916
>>880さんは正しいこと言ってると思いますよ ダルビッシュ → すごい
日本人 → すごい
レコード → 状態
値 → 状態
この論理展開が正しいと思ってる人はいるっぽい Haskellも当初はstreamで、それが何かしらの不都合が合ってmonadにしたんだろ >>919
書いてない。10個ぐらいの状態を保存するコードを書いてくれ >>921
引数を10個+αにしたり、10個の値の入ったリストなりタプルなりを渡す末尾再帰にすれば良いだけですが・・・。
もしくは>911の様な理解でも良い。
同様な物としてGUI部品そのもの(が確保してるメモリ領域)に保持させる。
Haskellから見れば外部から値を受け取って、外部に値を返すだけの「関数の様に振る舞う物(圏論で言う射)」になる。 > 引数を10個+αにしたり、10個の値の入ったリストなりタプルなりを渡す末尾再帰にすれば良いだけですが・・・。
その延長だとHTMLのボタンとかだと
引数が30個とかそれ以上になるんでしょうねｗ >>924
チュートリアル1ページくらい読めってw
https://guide.elm-lang.org/
button [ onClick Decrement ] [ text "-" ]
buttonに渡してるのはattributeのlistと子要素となるHTMLのlistの2つだけ
HTMLを理解してればこれで十分って分かるよね？ >>924
そう言うのんはHaskellの外側だから、ライブラリの初期化関数に読み込ませて、必要な関数に対応させるだけだお。
純粋関数型言語だから状態を持てないんじゃ無くて、状態をHaskellの外に置くのか、関数の引数にして引き回すのかの違いだけ。
副作用が無いとか、状態が無いとかは捉え方の問題で、状態も持つし副作用も有る。
参照透明性が崩れないのが普通の言語との違い。 キンタマはチンポに含まれるか否かだが、オシッコするときは含まないが射精するときは含む。 ハスケラーはまずモナドのわかり易い説明をここでしないとチン子さんとか納得しないんじゃないか モナドは入れ物から取り出して、なんかして、また入れ物に戻す動作。
そんな動作に付けられた名前がモナド。 >>930
その動作もモナドで表現出来る。
失敗する可能性のある処理に使うMaybe型もモナドなので、何も埋まってない穴を掘って何も埋まってない穴を埋め戻すのはNothing を受け取ってNothingを返すのと同じ。
(Nothing(答えが存在しない) がMaybe型の空っぽに相当する表現)
Nothing >>= f = Nothing
空っぽになったら無条件で空っぽを返すので、戻り値を捨てて新しい値を作らない限り、何度掘ってもNothing。
Nothing >>= f >>= f = Nothing 500円貯金をMaybe型で、fが500円入れる。gがx円取り出す。
Just 500 >>= f >>= f >>= g 1500
f x = Just (x + 500)
g x y | x >= y = Nothing
g x y = Just (y - x)
Out:
Nothing
Just 500 >>= f >>= f >>= g 500
f x = Just (x + 500)
g x y | x >= y = Nothing
g x y = Just (y - x)
Out:
Just 1000 繋がっているけれども独立している、単語と文章と文脈は、繋がっているけれどもそれぞれ独立している。
チンポは自分と繋がっているけれども独立している。 管理しきれればグローバル変数だろうがなんだろうがいいんだ >>937
テスト用のDBに切り替えられるようなコードにしとけよ。 >>937
データベースに頼る統計的機械翻訳はオシマイ、自然言語処理はオブジェクト指向で。
繋がっているけれども独立している、オシッコするときのチンポは制御型、勃起するときのチンポは自律型。 >>937
それは単にデータベースのデータの管理とデータベース製品の使い方を知らないだけ >>938
規模の拡大に伴って急激に管理しきれなくなるから問題なんだよ お前らアホはオブジェクト指向言語で階層構造にしちまうから
いざ、データベースヘ入れるぞってときにあたふたし始めて
作業にかかると大変な労力を使うことになる
っていうか今どきデータベースへ入れるかもしれないってところに頭がまわらないやつって使えなくね？ >>945
データベースに入れることとオブジェクト指向は何の関係もないですね グローバル変数が過去に問題視された原因は2つ
一つは名前の衝突、もう一つは更新可能な共有変数は利用する箇所が増えるほど扱いが煩雑になること
前者はnamespaceに類するものを使えば解決可能でほとんどの言語でそのアプローチを採用している
後者はできるだけimmutableにする、それができないなら利用箇所を限定して同時実行制御のイディオムを使うことで比較的容易に管理可能になる
データベースで考えると
前者はserver.database.schema.table.row.columnといった形でnamespace的に整理可能なので問題にならない
後者は可能な限りimmutableにできるかどうかや、mutableなら利用箇所を限定できるかどうかに依存しているので
開発者のアーキテクチャ設計能力が一定水準以下の場合のみ問題になってくる >>947
>一つは名前の衝突、もう一つは更新可能な共有変数は利用する箇所が増えるほど扱いが煩雑になること
「チンポ」は独立した生き物として考えないと、何故チンポは勃起したり射精したりするのかわからなくなる。 データベースを使うとカプセル化とは縁遠い作りになることが多い >>950
お前の理屈だと、ファイルを使うとカプセル化とは縁遠い作りになることが多いんだろ？ｗ カプセル化の意味を履き違えているのばかりだし、異様にこだわるのはもはやキチガイレベル。 オブジェクト指向に疑念を持って、関数型などにも浮気したが結局オブジェクト指向に戻ってきた
関数型だとインフラストラクチャのコントロール、外部APIコーディネートなどといった「現実の問題」に対象できない
また関数型が優れているとされる理由のエッセンスはイミュータビリティである、ということに気がついたからだ
結局のところオブジェクト指向にイミュータビリティを導入することが正解だった 全然関係ないこと横文字羅列することで畳み掛けるの流行ってるの？
少なくともそんなとこ考えてるときにオブジェクト指向言語じゃないと実装できませんねとか
意味不明なこと言い出した奴もういらんわ 何かに反論するときに、◯◯って流行ってるの？っていう入り方するのって流行ってるの？ オブジェクト指向でなければならないことはない
関数型ではダメなことは多い
手続き型のほうがうまくこなせることも現実世界には多い
それぞれ得手不得手がある
なのでそれらをいい感じに融合できるオブジェクト指向が正解ってわけ
融合する際にそれらの境界を上手く隔てるためにカプセル化が役に立つ
カプセル化を活用して、インフラストラクチャ、ステートフルリソース、手続き的な処理を隔離する
イミュータブルオブジェクトを導入して関数型の思想のもとで堅牢かつ柔軟なドメインモデルを構築する
このようにオブジェクト指向はなんでもそこそこ上手くできるからバランスがいいんだよ
現実を見据えたパラダイムだと思うよ
原理主義的にならずに旨味だけを享受すればいい
もちろんなんでもできるから使い方を間違えるとひどい目に合う
そこはしっかりと教育していくしかない
どんな道具でも学習は必要だ >>957
>関数型ではダメなことは多い
ダメな例を具体的に書けば自分のダメさがよく分かるよ
>どんな道具でも学習は必要だ
君自身がしっかりと教育されるしかない 関数型のクイックソートはクイックじゃねえからなｗｗｗｗｗ
ｗｗｗｗｗ使い物にならねえわｗｗｗｗ >>958
挙げてるじゃん
インフラストラクチャ、ステートフルリソース、外部APIコーディネート、などなど
数えたら枚挙に暇がない
関数型は所詮はインメモリの世界でしか通用しない道具だ
しかしインメモリに限れば強力なツールだ
なので関数型が苦手なことが得意な手続き型と組み合わせて使うのが正解
そして関数型と手続き型を密結合することなくうまく調和させるためにOOPのカプセル化や抽象化といった概念が役に立つ >>1
アランケイが提唱したオブジェクト指向と、クラスベースのオブジェクト指向を混同してる時点でな
いつものオブジェクト指向否定信者がスレ立てたんだろ 関数型に適応できる高速なソートのアルゴリズムってあるの？ >>961
>インフラストラクチャ、ステートフルリソース、外部APIコーディネート
これが具体的な例なんだねww
にしてもインフラストラクチャてwww
無知を自覚してしっかり教育されるか、無知を認められず老害化するかは君次第 「関数型はI/Oが苦手」
「関数型ではカプセル化できない」
と思っちゃってる個人の感想だよね >>968
いつまでに関数型OSが実用的に利用できると思う？
100年以内にでると言い切れる自信ないでしょ？ｗ 現実世界は副作用の塊なんだよ
関数型は現実問題を解決するには不向き
手続き型やOOPの力によって現実問題とうまく切り離された僅かな隙間であるインメモリ計算処理をうまくこなすことができる
関数型とはただそれだけの存在だ 数学の世界では無限という数値だって扱えるんです
しかしコンピュータでは扱えません インメモリ計算処理www
なんで理解できてないことをあたかも理解してるかのように語りたがるのかな？
知らない書けない理解してない無知な自分を認めたくないからって"あっちの水は苦い"と喧伝して自分を慰めても何にもならないぞ 悔しかったらOS実装してみろ
C言語ならできるぞ手続き型に負けて悔しくないのか お前が実装したわけじゃあるまいしｗ
Windows はオブジェクト指向OS >>973
ん～この中身の空っぽなレス
悔しかったら関数型で俺が上げた弱点をどう克服するのか示してみろよ
まあ理解してないことをあたかも理解してるように語る奴には克服方法なんて答えられんだろうけどｗ え？オブジェクト指向言語で解決できてる問題があると言っている？
恐怖を感じるほどのバカだな >>980
わかんない
>>976
そこの君い何がオブジェクト指向なのかね？ >>978
qmailのソースコード見たことある？
C言語なんだけどオブジェクト指向の極みなんだよ
https://github.com/amery/qmail
オブジェクト指向はqmailを解決したわけですね GitのソースコードもC言語なんだけどこれもオブジェクト指向の極み
https://github.com/git/git
コミットやリビジョン、リポジトリといった概念とソースコードが一致するようになってる
オブジェクト指向によるドメイン駆動設計
C言語すごい >>984
ソフトウェアコードの構造と言語（クラス名、クラスメソッド、クラス変数）がドメインと一致するようにするという考え方
ドメインは、コンピュータプログラムの対象物のこと >>986
おまえさん、ソフトウエア、あんまり作ったことなさそうだな… >>988
あんまりどころか僕はソフトウェアを何一つ作ったことがないが
プログラムにすごく詳しいんだ、わからないことがあったら聞いてくれ >>989
正直でよろしい。
そしたらY-cominatorを用いた動的計画法の解法についておよび
ラマヌジャンがノートに残したモジュラ関数を応用した超数近似の収束性とｶ･マーカー方への応用を
十実装したプログラムにたいして何か知見があったらその痴性をひけらかして演説書いてチョンマゲ
つか、ど素人はすっこんで定年までROMってろよ、ってかんじ >>991
Y-combinator
実装
な。ﾊｰﾄ。
しかしオブジェクト指向とかにつて、ホントたまにこういう基地外が湧くのは
宗教的なせいだんだろうか >>991
は、適当に思い付きをかいただけだから、
むきになって検索して気の効いたレス書こうとかしてないで、
いい子だからお薬飲んで、おしっこしてネンネしなさいよ おまえら、とりあえず動くものを作ってから雑談しろよ。 天文学者に宇宙行けと言ってるようなもんだろ
優れた頭脳は計算によって世界を知る ソフトウエアを作れない奴が、カプセル化だ、ゲッターセッターだ継承だ多態だ
薀蓄たれて開発者を惑わすのはやめる
足引っ張るだけだ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 48日 15時間 47分 4秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
