オブジェクト指向はオワコン？ part2

前スレ
オブジェクト指向はオワコン？
https://mevius.5ch.io/test/read.cgi/tech/1721393540/

オブジェクト指向じゃないほうがシンプルに作れるものを
オブジェクト指向で作ろうとするのは無駄でしかなく、オブジェクト指向の啓蒙にはならない

AI時代に最適な言語とは

>>348
英語、次点で日本語

日本語は文字圧縮率高いからAIに向いてるよな

>>350
向いてない

対AIの情報圧縮率は情報量/文字数じゃなくて情報量/トークン数なので日本語の情報圧縮率はむしろ低い
日本語に最適化された生成AIが出てきたとしても今の汎用生成AIで英語を使うのと同じレベルにはまずならない
ちなみに文字数ベースの情報圧縮率で言えば日本語より中国語のほうが上

言語ってやれることに縛りがないマシン語一択よ

バイナリなんて扱いが面倒で
しかもCPUやOSによって全く使い物にならないから
それだけは無い

>>345
余りで場合分けしたりGCD求めるより素直に判定する方がええんか

>>354
数値リテラルならな
>>346の様な(素数，表示文字列)のリストを受け取る形式にすると
3とか5が定数じゃなくなってコンパイラが>>345の最適化をしてくれない

「FizzBuzzのプログラム書いて」の指示だけで済むのになに前時代的なことやってんの?ｗｗｗ

>>355
コンパイラは賢いから最適化するだろ

>>348
仕様そのものを検証できるプログラミング言語じゃない？
今までは人間が実装を書いてコンパイラに文法や型を検証させてたけどAIの能力が上がってからは人間が契約をまとめた仕様をAIに掲示してAIが実装するようになったからね
言うなれば人間が契約を所有しAIが実装を所有し検証器が両者の関係を所有する言語かな
気になって調べてみたらRustとVerusによる言語の二層化とかあるみたいね

>>346
まあ、モナドではあるが、厳密なモナド則には従わない。
と、思ったのですが、この限定的な状況では、モナド則を満たしていました。

また、そりゃ、void main(String[])内で、ベタに手続き型で書けば速いわけですが、
15と固定でGCDを作ってみたら、同じ速さになりました。手動展開するとベタなものと同じです。
オブジェクト指向設計の形式は同じとして計測。

>>356
trait implをあえて使うとそうなるっていう説明用サンプルじゃないの

>>359
いやー俺も圏論詳しくないけど
君が言ってることはデタラメすぎる気がする
mapはただのファンクターじゃん
ファンクターとモナドは違うよね
モナドはflatMapの方だよ

圏論的構造のことをモナドと言ってる？
モナディックではなくてモナドチックってこと？
乙女チックみたいな話？
それならわかる

error: Unexpected symbol `['

>>361
モナドですけど何か？

>>362
SelectManyは他言語では単なるflatmapだぞ
誰でも日常的に使うものに過ぎない

>>361
flatMapがモナドじゃなくてflatMappableがモナドやで
>>362で言えばmsのほうやで

>>362の無能さは(1, 100)でよくわかる
100にするなら少なくともそこは105だろ

>>364
違うと思うけど明日AIに聞いてみるわ、お休みモナ

>>362
生成AI製か

>>368
引っかかってるのはIEnumerable<T>やStream<T>がモナドかどうかではなく
それらがモナドとして使われてない処理をモナディックと言うかどうかでしょ？
俺は言わないと思うけど言う人がいてもその違いが重要じゃない限りスルーする

>>364
> モナドですけど何か？

AIに聞いてみたけど >>320 は値オブジェクトでStreamを使ってるだけでモナドではないそうだよ

全文はこちら
https://chatgpt.com/share/6a87b6cf-2020-83ee-b07e-f2e91e706ada

>>359
> モナド則を満たしていました

これも偽だよ

>>370
どうでも良いといえばどうでも良いんだけどさ
暇だからモナドで何か話を広げてもらえない？

( ´∀｀)

>>372
Functor, Applicative は合成も Functor, Applicative になるけど, Monad は閉じてない.
他言語知らぬが, Haskell では少なくともそう.

>>371
モナドですけど何か？

>論破されても同じ主張を根拠無く延々と繰り返す
>それが複おじ!!

汚コードを披露したがるところといい精神構造が一緒だよね
二代目複おじと呼ばれるのも納得

flatMapすら使ってない方は論外として
こんな日常使うものを使っているだけでモナドと呼ぶかどうかという話だろ
flatMap: Stream<A> -> (A -> Stream<B>) -> Stream<B>

>>377
日常使うものかどうかと
モナドと呼ぶかどうかに
何の関係が？

リストってモナディックだぜっ!!

>>377
モナド則満たすしモナドでしょ
https://paiza.io/projects/vlUBccWkc0ctYRvsyFJJnw

モナド則もそりゃそうなるでしょってものだしモナドはそういうものってことでいんじゃないかな

>>374
わかりみが深い、むかしflatMapを自作しててわけわからんとなった経験がある、そういうことだったのね

もっと単純なMaybeやOptionもモナドだぞ

Finding the Reader Monad in FizzBuzz - Chat - PureScript Language Forum
ttps://discourse.purescript.org/t/finding-the-reader-monad-in-fizzbuzz/2460
Jul '21

FizzBuzz using Monad · GitHub
ttps://gist.github.com/maciejjaskowski/7f1734b33d5716c602db
(Scala)

結論
FizzBuzzでモナドを使うメリットはない

適当なお題としてはGraphQLの応答とか

>>385
どういうものにメリットがあると思う？

純粋関数縛りなHaskellで、モナド則を満たすデータ構造で副作用を表したのが肝であって
縛りのない言語でモナドを強調しても意味ない、ただ関数型チックな書き方がしたいだけの人

ま確かに興味本位だなｗ

普通の言語ならモナドに縛られずに書いた方が書きやすく見やすい
flatmapなどもモナドの観点なく使えばよい

https://paiza.io/projects/OHbT6kBvhYGdSm036ZGHCg
モナドプログラミングではなくMonadicプログラミング。
純粋ではないがMonadとみなせるものを扱う。

普通の言語でモナドにこだわらずにflatmapを使うメリットって逆に分からん
階層リストの一層平坦化変形にメリットがあるとかかい？

>>391
もしかして、正直者だけにMainの他にも見えるのかな？

generator().map(fb -> fb.toText()).forEach(System.out::println);
３つの部分をドットでつないで、1行で書くことができる。
generator()はStreamを発生させ、class FizzBuzz限定下でStream.ofはreturnに相当する。
flatMapはstreamに定義されておりbindに相当する。そのため、ドットでつなぐことができる。
mapはflatMapで定義されるが、この場合、flat化が不要なのでflatMapの限定版として使用する。
限定下で、モナド則を満たしている。
もちろん、class FizzBuzzはオブジェクト指向で操作されている。
ここまでが圏論的オブジェクト指向だが、
Stream<FizzBuzz>からStream<String>に変換されていて、
StringはFizzBuzzの性質を「受け継いでいる」。
この部分は場のオブジェクト指向に相当する。

>>392
flatmapは各種データを扱う時にいつも使う
どんな分野のデータにも同じ構造が出てくるけど
説明しやすい例だと
アーティストは複数のアルバムを出している
アルバムには複数の曲が入っている
アーティストが出している曲全てを得るにはflatmap

>>393
うむ、正直者にだけ見えます。

>>395
なるほどね
おれは普段祖いうのはアクセス演算子繋いでリテラルに書いてるわ

>>394
場のオブジェクト指向なんて用語は存在しない

>>397
普通にプログラミングしていたら一覧を遅延リスト(イテレータやストリーム)で欲しいからflatmapが良いね
わざわざ一覧のリスト生成するのは無駄

遅延リストの登場が必要なシーンて実践では意外と少ないんだよね。
使ってもいいんだろうけどもね。
データ構造は既にメモリ上にDOMみたいに展開されている場合が殆どだし

詳細は語らないが、Stream<String>が、class FizzBuzzの性質を受け継いでいることに気づいた。
これは本家 場の量子論や量子アルゴリズムに応用できるだろう。
（量子コンピューティングにおける）位相kickbackの正しい姿が見えた感じ。
くだらないことをやっていたら、かなりのお宝を発見した、と思う。

>>398
そりゃそうだ、お盆前におれが作ったやつだから。

もうご先祖様は帰ったぞ

>>394
Stream関手がListやMaybe/Optionなどと同じくモナド則を満たすのは良い

ただしFizzBuzz -> Stringの射を作れる段階で関手によるリフト(fmap)で
Stream<FizzBuzz> -> Stream<String>が得られるので
モナド則によるbind( >>= )はあえては必要ない

>>400
すでにメモリ上にあっても一覧にはなっていないでしょ
あなたの言うように階層構造になっているんてしょ
それならflatmapなどを使えばそのまま一覧を得られるでしょ
あなたはflatmapを使わずにどうコードを書いてるの？

>>405
深い方向に成長した階層構造ならループとアクセス演算子になっちゃうな

なんかオブジェクト指向と関係なくね？

>>404
ジェネリックをどう扱うかによって変わると思う。
ドットでつなぐというのはbindに相当する。
ともかく、純粋ではないので、「みなし」によってMonadとして扱い、
Monadの利便性を使う。圏論における自然変換っては（数学的な）「みなし」の一種なのかも。

>>406
ループなんか使ってお子様プログラミングしていたら一覧を他の関数に渡せないぞ
様々な一覧を共通の関数に渡せないダメなコードになる

>>407
Monadという対象（概念も含む）を扱っているのでオブジェクト指向でよいと思う。

とはいえ、おれの興味は量子コンピューティングへの応用（位相kickback）に移ってしまった。
わざわざ定数をclass FizzBuzzに押し込めたのは、それを場とみなすためだった。

局所的な実装方法をウダウダやってるのがオブジェクト指向？

動くコード書けないやつがウダウダ長文連レス書くクソスレがこちらです

まともなプログラミングをすると自然にオブジェクト指向になる
普通に関連データを構造体にまとめるとオブジェクト指向の第一歩
その構造体を用いる関数をそこに集めればオブジェクト指向の完成

言語によっては構造体に関連関数を紐付ける機能がある
構造体をクラスと呼ぶ言語もある

良し悪しの話ではないけど
クラス指向だと限界があるからOOP言語にはほぼAOP/DIな魔法がついてくる

そこは結局interfaceやtraitを使え！という結論になるよな

そもそもなんでこんなに沢山プログラム言語があるんだ
何個かでいいだろ

>>416
実用的な言語の観点だと
C言語は速いけど安全性と機能不足に難があった
そこで速さを犠牲にして安全で機能豊富な言語がたくさん生まれた
ところが

ところがC言語とほぼ同じ速さで動くRustが登場
これまでより高い安全性を満たしつつ機能も洗練されている
ただし習得に少しかかる問題があった

ところがAIにより学習問題は解決
コンパイルが通るだけで様々な安全性を満たしてくれるため
コード生成させる時もAIと相性が抜群に良い

でもコンパイルが遅くてプログラムの規模が大きくなると
コンパイルが終わらないんだろ、大変だな

>>414
クラス指向なんて言葉ないだろ

>>420
わかった
みなさんどっちも使われてるけどbasedをつかうね
プロトタイプベースと分けたかったのは伝わった？

モデリングすることが良いことだというバイアスが
オブジェクト指向の印象を良くないものにしているような気がする
シンプルな処理をシンプルに書くのが大事だ
Enterprise Hello Worldを見てそう思った

https://github.com/Wolfdp/Hello-World-Enterprise-Edition-CSharp

HelloWorldをのコードを見て結論を出してる人がいてワロタ

それなｗｗｗ

思ったんだけどさ
AIで全部書ける
AIで完全に書ける
のであればわざわメモリ安全の言語じゃなきてもよくない

完全に書けるのならAIが配列や動的に確保してくれた位置を考えてそれ以上にループとかが進まないように制限してくれるよね

後で自分で追記する時メモリ安全じゃないよ言うのだったら「AIで全てが書ける」わけではないと言うことになるし

>>425
これまで長い年月をかけて書かれたコードのメモリ安全性を証明する試みがいくつも行われてきた
しかしいずれも完成しておらず与えられたコードが安全かどうか確実に判定できない現実がある
これはAIが出力したコードが安全かどうか100%の判定ができないことを意味する

> AIで完全に書ける

Rustじゃないと確認できなくね？

プログラミング言語の中でRustだけがメモリ安全性からデータ競合安全性までRustの言語仕様により100%保証できるよ
つまりコンパイルが通れば100%保証される
AIはコンパイルエラーを見ながらコンパイルが通るまで頑張るだけで100%保証されるからAIとRustは相性が最高に良いんだよ

JavaScriptラインタイムのBunはAIで作られていて
プログラム言語をZigからRustに変えた
Zigだとメモリ管理のバグが頻発して開発コストが高かったからだ
いまのAIでは無理だな、Rustへのトランスパイラを定理証明器で作るとか
そういう方向が現実的なんじゃねえかな

コンパイルパスさせるために
端折ったりバグ埋め込んだり平気でやりそう

たしかに、人間だとそういうのあまり心配しなくて良いけど
それは人間の性格によるところがあるように思う
AIにも人格を芽生えさせてある程度の時間言動を追跡して
信頼できる人格か判定しないといけないのかのー

>>430
それはコンパイル関係なく
人間の指示にわずかな漏れがあればAIは何でもやる

だから穴を検知するためAIにテストを生成させる
テスト生成に漏れがないかだけに専念させるAIに漏れをチェックさせる
その生成されたテストをコンパイル頑張るAIに与えてテストも同時に通させる

>>425
AIで全部書けるのとAIが全部書くのとは違うよ
検証された既存のものを使えば楽ちんなのはAIも同じ
機械的な検証の責務を今までどおりにコンパイラに委譲するのはこれからも変わらない

>>425
現実のコードはそんな単純なパターンでないため安全なコードが書けたかどうかは悪魔の証明になっちゃうよ
だからAIがコード生成する時代になってもC/C++は捨てましょうのまま進んでるよ

AIはマシン語で書けばいいんだよ
チェックするときはそれを逆コンパイルして好きな言語で読めばいいのさ

C++はそのうちメモリ安全性も取り込むと思うけど

>>436
それC++11から15年間頑張って来たけど無理だった

>>382
flatMap自作できるの？

ソフトウエアとして実現されているものはすべからく自作可能である（ニーチェ）
ただし、それが面倒くさくて煩雑だったり、既にあるモノをわざわざ作る意義が乏しいことは多々ある（プラトン）

そしてオブジェクト指向を迂闊に導入すると
ソフトウエアはぐちゃぐちゃになる
ここまで得られた知見ということで一旦結論

処理単位を明確に分割するのがオブジェクト指向のメリットでもあるんだけど
どうやったらオブジェクト指向でプログラムがぐちゃぐちゃになるってんだか
それは単にクラス分けとか失敗してるだけだろうね

そういう局所の書き方話ではなくてソフトウエアシステム全体に影響を及ぼす話

というか「処理単位を明確に分割する」って何だよｗ

そういうおためごかしがどのくらい混乱を招いて来たか反省する脳は
たぶん君にはなさそうだな

さー、オブジェクト指向厨にけんかを売りましたｗ

オブジェクト指向って何でこんなカルト迷信みたいに広まったんだろうね
ほんと、人によるの物事の受け止め方や、それによって脳に生じたノイズって面白い
いや詰まらない

関数の切り分け方に比べるとメンバーやオブジェクトをどう設定するかは人によって相当分かれる。
その事実を明らかに無視したバカがオブジェクト厨になる

オブジェクト指向厨って結構、感覚的で
その方が直感的にわかりやすいと思ったからとか
平然と言ってくちゃくちゃしたコード書いて悦に入ったり不況活動した理り人を批判する
人畜無害じゃないんだよね。有害

オブジェクト指向が流行ったココ30年くらい、それは日本で丸投げ中抜き派遣作業が発展した時期と奇遇にも一致するんだけれど
この時代は、コンピューターサイエンス、ソフトウエア工学の暗黒時代だったと思っている