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

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

>>308
FizzBuzzは数値をあるルールで文字列に変換する問題だよね
そしてRustで文字列に変換する時はDisplayトレイトを実装するのがお約束
>>301のコード以外に適切な方法ある？

>>312
前者は数列処理にFizzBuzzのルールを与えたプログラム
後者はFizzBuzzの問題を解く為に構成されたプログラムという理解
メリットは…なんだろう

>>306
はよ
https://www.jdoodle.com/execute-freebasic-online

>>313
煽られただけだと思うよ

やるとしたらfmt::Displayの実装とFizzBuzz判定の実装を別々に分担するくらいか？
あと個人的にはifじゃなくてmatchでよくね？と

>>301は最小限のコードを書いたので
もう少しFizzBuzzオブジェクトに肉付けすると

#[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord)]
struct FizzBuzz(usize);

impl FizzBuzz {
fn is_fizz(&self) -> bool {
self.0 % 3 == 0
}
fn is_buzz(&self) -> bool {
self.0 % 5 == 0
}
fn iter() -> impl Iterator<Item = FizzBuzz> {
(1..).map(|x| FizzBuzz(x))
}
}

impl fmt::Display for FizzBuzz {
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
if self.is_fizz() {
write!(f, "Fizz")?;
}
if self.is_buzz() {
write!(f, "Buzz")?;
}
if !self.is_fizz() && !self.is_buzz() {
write!(f, "{}", self.0)?;
}
Ok(())
}
}

他の例のように20まで表示したい時は

fn main() {
for z in FizzBuzz::iter().take(20) {
println!("{z}");
}
}

>>317
FizzBuzzのルール
3で割り切れる時はFizzと言い
5で割り切れる時はBuzzと言い
結果として15で割り切れる時はFizzBuzzと言うことになる
これをそのまま実装したのが>>318

// java21, import略, rosettacodeの仕様による。3と5の倍数の場合、3や5のwordと関係ないものとみなして独立。改行詰め,、改行が多いだと！
public class FizzBuzz {
private static final int IntMin = 1;
private static final int IntMaxClosed = 100;
private static final String Fizz = "Fizz";
private static final String Buzz = "Buzz";
private static final String FizzBuzz = "FizzBuzz";
private static final BigInteger bigInteger15 = BigInteger.valueOf(15);
private final int value;
private FizzBuzz(int value) { this.value = value; }
static Stream<FizzBuzz> generator() {
return IntStream.rangeClosed(IntMin, IntMaxClosed).mapToObj(FizzBuzz::new);
}
int gcd15() {
return BigInteger.valueOf(value).gcd(bigInteger15).intValue();
}
String toText() {
return switch (gcd15()) {
case 3 -> Fizz;
case 5 -> Buzz;
case 15 -> FizzBuzz;
default -> toString();
};
}
@Override
public String toString() { return Integer.toString(value); }
public static void main(String[] args) { generator().map(fb -> fb.toText()).forEach(System.out::println); }
}

これは想定外の重症度
汚コード複製おじさん酷すぎだろ

immutableなclassとstreamでmonadicに、各methodは1行の式とした例。
改行制限と空白制限で、ちょっとおかしな表記になっている。

>>320
100までとか
main関数とか
なぜclass FizzBuzzの中にあるんだよ草

くすくす。仕様を満たすためだよ。

ここはオブジェクト指向でFizzBuzzを書くとどうなるかの話だよな
class FizzBuzzに属するものと外部のものを分けないとな

generator込みの完結したclassだがね。UnitTestにも対応してるし。
プログラム書いたことある？

>>318は改行しまくりスカスカでも収まってるのに
>>320は改行を詰めてぎっしりコード量が多くて見にくいのはなぜ？

糞言語ってことよ

>>320はgcd最大公約数を求めてるけど
その方が速いとか有利とか何かあるの？

https://paiza.io/projects/zW-QQAk1SV2qaU7Iv3Kqtw
FizzBuzz classがMain classになっちゃったけど、しかたない。
最大公約数で扱ったほうが楽だし、意味的にはGCD使ったほうが正しい。

generator().map(fb -> fb.toText()).forEach(System.out::println);
generator()で発生させたFizzBuzz(Main)オブジェクトをtoText()してprintlnの関手を与える。
ただそれだけ。
toText()は15とのGCD取って、結果でFizz,Buzz,FizzBuzz,その他の文字列を返すだけ。
return switch (gcd15()) {
case 3 -> Fizz;
case 5 -> Buzz;
case 15 -> FizzBuzz;
default -> toString();
};

>>330
class Mainとclass FizzBuzzに分けようぜ

plaza.ioは複数class書けるね。しばらくはこれを使おう。java18らしいし。
でも、本来はclass FizzBuzzひとつのオブジェクト指向の例なので、
MainはFizzBuzzに読み替えてほしい。

1文字でFizzBuzz解ける言語があるらしいな

>>330
意味的にGCDを使うのは間違っている
さらにGCDは計算時間がかかり不利だ
途中で除数が定数でなくなるためDIV命令が必要になるためだ
普通に3で割る余りと5で割る余りの計算ならDIV命令が不要で速い

定数で割った時の余りは掛け算とシフトと引き算で済むから速いんだよな

DIV命令？　あったっけ？

めんどくさいのでBigInteger#gcd(BigInteger)使ってるけど、
15とのGCDで3,5,15の判定だけなので自作すればもっと速いだろう。しかし、速さの指定は仕様にない。
意味的には15との最大公約数で振り分ける。保守しやすい。
if文が２つ以上あるとバグが出やすくなる笑。

CPUの割り算命令DIVは遅いんだよ
ただし定数での割り算は掛け算とシフトで代替できるから速い

その前にだな、
まともに見れるコードも書けんくせに
オブジェ指向で蘊蓄垂れていたのか君らは

GCDアルゴリズム実装ではなくCPUのDIVの話ね。
アルゴリズムならマルチコア上で速そうなのを考えてみよう。少しだけ思いついたので。

https://paiza.io/projects/BA7H5VNcMAbOvwmXRnPAmw

compactの前に.lazyわすれた
遅くなるけど概念的にそうしたい

FizzBuzzのように定数で割る時
商は魔法により掛け算とシフトで求まる
余りはさらに商に掛け直して元から引き算で求まる

ところがだ
FizzBuzzで余りを求める必要ないのだ
余りが0かどうか判ればいい
強力な魔法を使うと掛け算と比較で求まる

Fizz判定は x % 3 == 0 が真かどうか
xがeaxレジスタに入っている時
imul eax, -1431655765
cmp eax, 1431655766
この結果CFフラグ=1ならFizzだとわかる
強力な魔法のおかげで実は速い

>>320
Fizz、Buzzに加えてPop、Jazz、Rockに対応してください

3 → Fizz
5 → Buzz
7 → Pop
11 → Jazz
13 → Rock

>>322
> immutableなclassとstreamでmonadicに、各methodは1行の式とした例。

モナドを使ってないのにモナディック ( ⊙ω⊙ ) !!?

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

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に押し込めたのは、それを場とみなすためだった。

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

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