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

過去スレ
オブジェクト指向はオワコン (2023/08/26～)
https://mevius.5ch.io/test/read.cgi/tech/1721393540/
オブジェクト指向はオワコン？ (2024/07/19～)
https://mevius.5ch.io/test/read.cgi/tech/1721393540/
オブジェクト指向はオワコン？ part2 (2026/08/13～)
https://mevius.5ch.io/test/read.cgi/tech/1786599483/

use feature 'current_sub';
@a = map{[split]} <DATA>;
($m, $n) = (20, 1);
sub {
　$s = '';
　map{0 == $n % $$_[0] and $s .= $$_[1]} @a;
　$s ||= $n;
　print "$s\n";
　$n++, goto __SUB__ if $n < $m;
}->(1);
__DATA__
3 fizz
5 buzz
7 Pop
11 Jazz


注) Perl の「goto 関数」は continuation

>>https://mevius.5ch.io/test/read.cgi/tech/1786599483/599 ocaml
https://ideone.com/eaBULr
・Java版のRuby移植のOCaml移植
・連結済文字列じゃなくて、文字列のリストを返すようにしたのは単に気まぐれ
　"FizzBuzz"じゃなくて["Fizz"; "Buzz"]を返してる

>>https://mevius.5ch.io/test/read.cgi/tech/1786599483/599 ocaml
https://ideone.com/Q1I3uT
・Woofの303がFizzFizzFizz版
・String.fold_leftは4.13以降
・今のideoneは OCaml (ocamlopt 4.05.0)

>>5
}->(1);
は1ｲﾗﾈ
}->();
でおｋ

>>5
お題がFizzBuzzのバリエーション6種類に対応できるコードを実装に変わってるよ
バリエーションに対応できつつコードの共通化で6倍のコードになるのを防ぐ感じ

対応すべきバリエーションはこれらしい
https://xapn.github.io/fizz-buzz/#fizz-buzz-variations
従来の割れるか classic
文字列化して含むか digits
割れるか含むか boom
割れると含む回数 woof
7と11を加えた popwhack
7,8,11,13を加えた zingchop

最大公約数の人がピンチ

120120通りの表を作れば行けるはず

場のオブジェクト指向おじさん星になる

バリエーションと圏論は相性良さそうな気がするけど出て来ないね

最小限の射へ分解

なんだろうね、素数だから数学的におもしろかったのに、
割れると含むとか入ってきて、
さらに８ってのはどこからでてきたものなんだか、2^3ということかな？
「場のオブジェクト指向」では、すべが計算済の「場」とするので、
どうやるかは量子計算での加法の扱いにかかってくる。考え中。まあ、
できたらフィールズとかノーベルとかのレベルだから考えて楽しんでいるだけ笑。
問題は、場の量子論で「加法」をどのようなものとして扱うか、ということ。

>>15
zingchopで8で割り切れる時を扱わなければいけなくなって場のオブジェクト指向は破綻したのか～

場のオブジェクト指向は考え中のものだから、破綻はしていない、むしろ、
今回のようなルールが無限に増える場合に対応するものとして構想している。
ルールに割れるだけはなく、含むが加わった。
しかも、どうやら指数すらも含まれるような感じ。
自然数を表現可能なすべての表記が入るのだろう。n進数も。
自然数限定だが表現論の問題になっている。

>>17
「含む」は10進数で表現した時すなわち文字列化した時に含まれるかどうかが今回の仕様だね
人間が扱う自然な仕様は10進数だけだろうけど

>>9
ざっと縦読み目を通したけどmethoc chainで呼んだ場合の処理とカ書いてあって
結局、各方式ごとの関数なりmethodが要るってことになるし
昨日関数間でコードの共通化できるとことはあんまりない感じだな

今回の件は全体が見やすいように3つの部分に分けるとプログラムはこれだけだね
type Count = fn(usize, usize) -> usize;
const DIV: Count = |t, n| (t % n == 0) as usize;
const IN: Count = |t, n| t.to_string().contains(&n.to_string()) as usize;
const DIV_OR_IN: Count = |t, n| (t % n == 0 || t.to_string().contains(&n.to_string())) as usize;
const DIV_AND_MULTI_IN: Count = |t, n| (t % n == 0) as usize + t.to_string().split(&n.to_string()).count() - 1;

type Rule<'a> = (Count, &'a[(usize, &'a str)]);
const CLASSIC: Rule = (DIV, &[(3, "Fizz"), (5, "Buzz")]);
const DIGITS: Rule = (IN, &[(3, "Fizz"), (5, "Buzz")]);
const BOOM: Rule = (DIV_OR_IN, &[(3, "Fizz"), (5, "Buzz"), (7, "Boom")]);
const WOOF: Rule = (DIV_AND_MULTI_IN, &[(3, "Fizz"), (5, "Buzz"), (7, "Woof")]);
const POP_WHACK: Rule = (DIV, &[(3, "Fizz"), (5, "Buzz"), (7, "Pop"), (11, "Whack")]);
const ZING_CHOP: Rule = (DIV, &[(3, "Fizz"), (5, "Buzz"), (7, "Pop"), (8, "Zing"), (11, "Whack"), (13, "Chop")]);

struct FizzBuzz<'a>(usize, Rule<'a>);
impl<'a> std::fmt::Display for FizzBuzz<'a> {
fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
let FizzBuzz(target, (count, list)) = self;
let mut is_done = false;
for &(number, name) in *list {
for _ in 0..count(*target, number) {
f.write_str(name)?;
is_done = true;
}
}
if !is_done {
write!(f, "{target}")?;
}
Ok(())
}
}

>>20のプログラムの検証
他のプログラムが通してる事例を参考にしました

fn main() {
use itertools::Itertools;
assert_eq!((1..=15).map(|t| FizzBuzz(t, CLASSIC)).join(" "),
"1 2 Fizz 4 Buzz Fizz 7 8 Fizz Buzz 11 Fizz 13 14 FizzBuzz");
assert_eq!((1..=15).map(|t| FizzBuzz(t, DIGITS)).join(" "),
"1 2 Fizz 4 Buzz 6 7 8 9 10 11 12 Fizz 14 Buzz");
assert_eq!(FizzBuzz(35, DIGITS).to_string(), "FizzBuzz");
assert_eq!((1..=15).map(|t| FizzBuzz(t, BOOM)).join(" "),
"1 2 Fizz 4 Buzz Fizz Boom 8 Fizz Buzz 11 Fizz Fizz Boom FizzBuzz");
assert_eq!(FizzBuzz(7539, BOOM).to_string(), "FizzBuzzBoom");
assert_eq!((1..=15).map(|t| FizzBuzz(t, WOOF)).join(" "),
"1 2 FizzFizz 4 BuzzBuzz Fizz WoofWoof 8 Fizz Buzz 11 Fizz Fizz Woof FizzBuzzBuzz");
assert_eq!(FizzBuzz(35, WOOF).to_string(), "FizzBuzzBuzzWoof");
assert_eq!(FizzBuzz(303, WOOF).to_string(), "FizzFizzFizz");
assert_eq!((1..=15).map(|t| FizzBuzz(t, POP_WHACK)).join(" "),
"1 2 Fizz 4 Buzz Fizz Pop 8 Fizz Buzz Whack Fizz 13 Pop FizzBuzz");
assert_eq!(FizzBuzz(1155, POP_WHACK).to_string(), "FizzBuzzPopWhack");
assert_eq!((1..=15).map(|t| FizzBuzz(t, ZING_CHOP)).join(" "),
"1 2 Fizz 4 Buzz Fizz Pop Zing Fizz Buzz Whack Fizz Chop Pop FizzBuzz");
assert_eq!(FizzBuzz(120120, ZING_CHOP).to_string(), "FizzBuzzPopZingWhackChop");
}

なぜかIDが変わってるけど
>>20の検証部分が>>21ね

>>19
それは仕様を言葉で説明すると曖昧になりやすいからの理由でしょう
その通りのまま実装してる人は誰もいないから大丈夫だよ

結局ルール辞書作ってぶん回すだけ

>>24
ルール辞書の作り方や構造が難問
様々な問題に対して自動的に汎化させることは難しい

>>9 ocaml
https://ideone.com/iRLbSx
・>>6から若干の改善
・判定につかってたcontains,countの実装が簡易的だったので整数比較版に差し替え
・結果のリストに対するinspect関数つくっといた
　to_s関数を`List xsに対応させてみたりしたけどなんか使い勝手が悪かったのでこっちにした

もしやこのコードは

>>26
let count m n =
let m, n = abs m, abs n in
let d = if n = 0 then 10 else int_of_float (10. ** (1.0 +. (floor (log10 (float_of_int n))))) in
let rec aux acc = function
0 -> acc
| m -> aux (if m mod d = n then acc + 1 else acc) (m / 10)
in if m = n then 1 else aux 0 m
let contains m n = 0 < count m n

今のところ前スレ>>938が一番まともやな
変換辞書と変換ロジックのセットとして扱ってればなお良かった

にしても不必要なcount変数やflag変数を導入するやつとか
ToString()にドメインロジックを全部突っ込むやつとか
おかしなやつが多いな

938を見たら145行もあった
動作確認printしてるmain関数8行を除いても130行以上ある

行数が多いとその分稼げるから

>>28
これは文字列化する課題だよね
みんなが文字列化の関数にドメインロジックを書いているのは当たり前だと思いますが

>>20
これはRust? OCamlかと思った

>>31
神クラスならぬ神toStringか

>>28
その938もToStringする関数にメインロジックを書いてるけど938をお気に入りな理由は何？

文字列にする関数とドメインロジックを分けることがそもそも可能なのかね？

javaのtoString()はデバッガでも表示に使用されるため、
オブジェクトの区別がつけられるユニークな内容のみで使用するのが望ましい。
できればデバッグ用以外には使用しない。
デバッグで必要となるため、
すべてのオブジェクトは、toString()でオブジェクトの文字列表現を正しく返すように実装すべき。

唐突に何だろ
そんなレベルの問題を起こしてるコードはこのスレで見たことない

extends is evilの潜在的バグはtoString()用法の間違いが一番多いので。

それは文字列化とデバッグ用を混乱しているJavaの問題
オブジェクト指向プログラミングとは無関係

いつもJavaの仕様や方針が足を引っ張ってるような

javaは単純化しようとしてかえって初心者には扱えないものになってしまった。
toString()の例は、オブジェクト指向（設計）の例で、
設計や、実装の段階では、指示しているオブジェクトが正しいつもりでも、
実際に実行してみると、想定とは異なったオブジェクトにメッセージを投げていたりする。
相手だけではなく、自分自身も設計・実装時に想定していた自分(this)とは違う自分(this)
になっていたりする。
手続き型の現物プログラミングやスクリプト言語ばかりやっていたりすると、
オブジェクト指向の抽象プログラミングでバグる。
設計が正しくても、実装する側が手続き型しか使ったことがなかったりすると、確実にバグが発生する。

「オブジェクト指向の抽象プログラミング」
「確実にバグが発生する」

「Javaによく慣れて精通していないと嵌る落とし穴のある言語だ」
くらいに抽象化して言えないのかな

よく慣れて精通していないと嵌る落とし穴満載の言語で最たるものはC++が王様だな
いや、たとえ精通していても…

特に何も抽象化していないいのに抽象化という言葉を使うのはやめましょうよ
ものすごい違和感というかもはや不快感を覚える

オブジェクト指向（設計）とは抽象化ですよ。
オブジェクト指向言語は抽象化言語。
オブジェクトやメッセージに抽象化することで状態や実装を隠ぺいする手法なのです。

javaは単純化したのが命取りのようではあるが、
手続き型中心のオールドプログラマを攪乱し、リバースエンジニアリングさせない効果はある。

parseIntが面倒糞かった

どちらかというと、手続型（命令型）と関数型（宣言型）が対立的な概念で、オブジェクト指向は手続型の範疇というイメージかな。もっとも、関数型（宣言型）の良いところを部分的にではあれ取り入れようという動きは顕著よね。
手続型（命令型）の書き方をベースに書くときに、どの程度オブジェクト指向的な書き方をするかと、どの程度関数型的な考え方を取り入れるかはそれぞれ独立のことだと思う。

>>49
その二つも差はなくね？
関数を入れ子にして手続き書いていくとか
メソッド関数を数珠繋ぎにして手続き書いていくとか
見かけは宣言型でも手続き型と何が違うの？

オブジェクト＝タスクマシン
他のプログラムに干渉されずに独立してプログラムを実行できる仕組み、ならいいんだが

delay()使っても止まってるのはそこだけで、他を止めない

>>51
それは非同期並行タスクとしてそれを持つ各言語で実現されてる

>>52
で、1000以上のキャラの弾幕ゲームを作れるかね？
全部のキャラを独立したオブジェクトでさ

>>50
関数型の考え方を取り入れるというので想定していたのは、純粋でない関数はできるだけ減らすとか、高階関数を活用するとかの素朴な考え方だけど、これらはオブジェクト指向の直接的な関心事ではないでしょう。オブジェクト指向でも取り入れることはできるけど。
いわゆるメソッドチェーンは、それ自体としては宣言的になる場合もあれば、命令的になる場合もあるんじゃないかな。

宣言的な度合いに相対的な高低差があるというだけ

何か抽象的なような煙に巻くような言い方だなｗ

>>46-47 こういう人が未だに居るんだな…
残り少ない生き残りというか残党みたいな信奉者(やや狂信的傾向)
最後まで城を守る！あるいは船と沈む！みたいな

他の言語やパラダイムも勉強して視野広げたほうが良いと思うの
それから、客観的にものを見られるようになったり、合理的に考えたりする力の訓練もね

まあ、どうのこうのといっても、手続き型言語も抽象化されたものだし、
CPUやGPUなども抽象化されたものだし、
その意味では、最初からオブジェクト指向で設計されているともいえる。
数学的な理論づけとしては圏論も欠かせない。
が、これから重要なのは情報理論。それはエネルギー論でもあり、場の量子論でもある、ということ。

場のおじさんだったかｗ

CPUやGPUは尤も生々しい具現だチューにｗ
あんた、場だの論だの抽象だの既存の権威付けられた言葉の印象に憧れてるか酔ってるだけでは？

>>9 java
https://ideone.com/DCrHR4
・Woofの303がFizzFizzFizz版
・countは正規表現つかって実装
・clone, list(b, e)メソッド追加

>>9 ruby
https://ideone.com/1G57lm
・Woofの303がFizzFizzFizz版
・countは正規表現つかって実装

勉強不足ですなー。CPU/GPUは抽象計算機を物理的に実装したものですよ。
計算モデルに従います。

CPU/GPUもやっぱり場の理論によって動作しているのですか？

場の理論といえばやっぱりランダウのバコテン(場の古典論)、QEDはFeynmanが懐かしい

論的量子力学・QFDはBjorken Drell、QCDはFeynman

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

んなこたーない

>>64
ま、量子世界にいるわけですから、いまのところ場の量子論で動作しているということでも
いいわけですが、量子レベルの現象を直接扱っているわけではないと。
現在の計算モデルは、何世代目かの宇宙における構造（カラビヤウ多様体）に起因していると考えております。

オブジェクトンとオブジェクティーノの対称性

>>32
その通りRustだよ

>>36
Rustは3つのインターフェースに分かれてるよ
trait Debug デバック表示用の文字列化
trait Display 通常の文字列化
trait ToString 通常の文字列化＋文字列型Stringに格納するためのメモリ確保

文字列型へのToStringはこのように非常に重い処理なので分離されてる
表示や既存文字列への追記は中間生成Stringを作ると無駄だからね
プログラマはDisplayを実装すればToStringは自動実装されるよ

Debugはそれらと独立のもので自分でも実装していいけど
各型の宣言に #[derive(Debug)] を修飾すると機械的に自動実装してくれる

FizzBuzzへのtrait Displayの実装例が >>20
コストの高いメモリ確保処理は分離されて純粋な文字列化処理のみになってるよ
Rustはこれが標準で数値などのプリミティブ型も全てtrait Displayを実装

こうすることで何がメリットかというと
例えば >>21 のこの処理

　「1から15までのBizzFizzの結果をスペースで繋げて1つの文字列にするコード」
　(1..=15).map(|t| FizzBuzz(t, CLASSIC)).join(" ")

よくある15個のStringを生成してそれらを繋げて1つのStringを作るのと比べて
join()はtrait Display実装型を受け付けるため一気に1つのStringのみ作ります
15個の中間生成Stringのメモリ確保と生成を省くことができてます
これはjoin()に限らずprint!系なども同様です

自然数の文字化だけだとユニークで一対一なのでフェルミだ。
これを３の倍数とか５の倍数とかで文字化すると、そこは複数の値が同じ文字になるのでボゾンだ。
量子統計が異なる。
で、フェルミが積で、ボゾンが和だ。場の量子論から、そうなる。（かなりすっ飛ばした結論笑）
区別がつくものは積であらわされ、区別がつかないものは和であらわされる。
積と和がハイブリッドしたもの...それはアレだ！（ホントかどうか調査中）

>>71
実に醜いし
CPUがやってる作業も壮大な無駄と遠回りだろう

普通にシンプルな手続き型でやりゃいいことを、無駄にオブジェクト指向で作る意味はない

>>73
オブジェクト指向だから実現できてるんじゃね？
使わないと無理っぽい

手続き型で普通のシンプルな条件処理で済むじゃん

>>75
見たい
コード書いてみて

BizzFizzの話題になった初期に出てるじゃん

>>73
オブジェクト指向によってその無駄なCPUの作業を減らしている好例だよ
「文字列型への変換」という格納メモリ確保を伴う重い作業から
「純粋に文字列への変換のみ」を別のインターフェースとして切り出している
そうすることで無駄な一時的な文字列型の生成を防ぐことができているよ

>>74
「何が」オブジェクト指向だから実現できてるの？

オブジェクト指向によって
全ての型に対して「(メモリ確保を伴わない)純粋な文字列化変換」という共通インターフェース(trait Display)を設けて各型がそれを実装しています
それを用いて「(メモリ確保を伴う)文字列型への変換」という共通インターフェース(trait ToString)が全ての型に自動実装されます
この両者の分離により無駄なCPU処理と無駄な一時メモリ確保を防いでいます

>>80は>>74と同一人物なのかな？

一般的にオブジェクト指向を使わないとインターフェイス抽象型による共通の扱いができないから各々の型でバラバラにやることになって破綻だよな

複数の異なる型を同じメソッドで呼び出しできる
これがオブジェクト指向の最大の利点だ

多相性は型システムの問題のような気もするけど。

単なる多相性だと型を横断しての共通呼び出しが保証されない

>>49
無駄なこだわり主張して現場を困らせるやつの典型例だな

手続き型が小汚いので、各オブジェクト指向系言語は工夫しているが、
ダメなものはダメで、さらに小汚いものが書かれて、それをオブジェクト指向のせいにしている。
Why extends is evil が、その典型的な例で、最後にはなにも解決せず、さらに悪化させたまま
終わっている。そこには絶望しか残っていない。
手続き型でも、キレイにかけるやつはかけるのだが...残念なプログラマが多い。
プログラムは文学的/文芸的であるが、叙述ミステリーであっては困る。

>>9 java
https://ideone.com/C9Cmel
・Woofの303がFizzFizzFizz版
・OOPらしく（？）継承でなんとかするやつ
・委譲でなんとかするやつは>>62

>>9 octave
https://ideone.com/MXBicD
・Woofの303がFizzFizzFizz版
・Java版のRuby移植のOCaml移植のOctave移植
・ほかの言語のクセが混入しちゃってOctaveらしくないかも

実行結果

~ $ perl FizzBuzz_variations-26830.pl
1 2 Fizz 4 Buzz Fizz 7 8 Fizz Buzz 11 Fizz 13 14 FizzBuzz
1 2 Fizz 4 Buzz 6 7 8 9 10 11 12 Fizz 14 Buzz FizzBuzz
1 2 Fizz 4 Buzz Fizz Boom 8 Fizz Buzz 11 Fizz Fizz Boom FizzBuzz FizzBuzzBoom
1 2 FizzFizz 4 BuzzBuzz Fizz WoofWoof 8 Fizz Buzz 11 Fizz 13 Woof FizzBuzzBuzz BuzzBuzzWoof FizzFizzFizz
1 2 Fizz 4 Buzz Fizz Pop 8 Fizz Buzz Whack Fizz 13 Pop FizzBuzz FizzBuzzPopWhack
1 2 Fizz 4 Buzz Fizz Pop 8 Fizz Buzz Whack Fizz Chop Pop FizzBuzz FizzBuzzPopWhackChop

おー、octaveって初めて見た。

>>90
むむ、4番目と6番目の結果が違う

4番目
1 2 FizzFizz 4 BuzzBuzz Fizz WoofWoof 8 Fizz Buzz 11 Fizz Fizz Woof FizzBuzzBuzz

6番目
1 2 Fizz 4 Buzz Fizz Pop Zing Fizz Buzz Whack Fizz Chop Pop FizzBuzz

>>87
俺のオブジェクト指向を見てくれ、こいつをどう思う？
https://paiza.io/projects/74r7Bk2gDxB1PllUsjS1vQ

>>93
失格
皆が検証しているwoofの303やchopの120120を求めることすらできないプログラムになっている

>>92
90 の 4,6行目と 93の 4,6行目は合っているように見える

ｵﾚの目が疲れている？

>>94
余裕でした、なぜならオブジェクト指向だから
https://paiza.io/projects/JoOYtyQ9TMC-CV0n_HWDuA

>>95

4行目
1 2 FizzFizz 4 BuzzBuzz Fizz WoofWoof 8 Fizz Buzz 11 Fizz 13 Woof FizzBuzzBuzz
1 2 FizzFizz 4 BuzzBuzz Fizz WoofWoof 8 Fizz Buzz 11 Fizz Fizz Woof FizzBuzzBuzz

6行目
1 2 Fizz 4 Buzz Fizz Pop 8 Fizz Buzz Whack Fizz Chop Pop FizzBuzz
1 2 Fizz 4 Buzz Fizz Pop Zing Fizz Buzz Whack Fizz Chop Pop FizzBuzz

FizzBuzzのプログラムを書いてみるとデータと操作は分けた方がいんじゃないかという思いが強まるよな
なんでもかんでもオブジェクトにするのが旧オブジェクト指向だとすると
データ構造や言語機能の補間のためにオブジェクトを作るのが新オブジェクト指向なのかもしれない

>>91
octaveに三項演算子があるか
ifが式で値を返せるようになってたらなあ

x = {b m}(1 + isempty(b));　←こんなこと書きたくはなくて
x = isempty(b) ? m : b;　←こう書けたり
x = if isempty(b) then m else b;　←こう書けたらなあ！
x = ifelse(isempty(b), m, b);　←こうは書けるみたいだけど欲しいものとはまた違うし

それ以外は良い言語だお（　＾ω＾）
いっしょに行列グリグリしようず

>>98
行きつくところはFizzBuzz拡張DSL

Haskell等でeDSLか
他言語でインタープリタかJIT

>>68
ウィック回転することでFizzBuzzの時間の流れから時間を消し去ることが可能

>>103
アンカー間違えた orz
>>89 のソースの修正ね