深夜のオブジェクト指向と関数型がうんたらかんたら

ちゅーん @its_out_of_tune

objectiveの写経で、とりあえずコンパイル通るけどなんでコンパイル通るかわからんしなんでちゃんと動くかわからないというLens触りたての頃に感じてたあの感じを再度味わっている。

ちゅーん @its_out_of_tune

それでもとりあえず型を見れば何をする関数なのかなんとなく解るのがHaskellの凄いところ。

はなだ☆のぶかず@lisp &ボドゲ勢ボドゲプレイヤー) @nobkz

正直、「型を観れば分かる」ってのはその通りなんだけど、むしろ型を理解しないといかんのでな。

ちゅーん @its_out_of_tune

なんか、良い感じにつっこもうと思ったけどうまい日本語出てこなかった。

ちゅーん @its_out_of_tune

「コード読めばわかる」に対して「コードを理解しないといけない」って言われたら「コード理解しろよ」って言いたくなるだろうし、それに対して「読みやすいコード書けよ」ってなるかもしれない。

はなだ☆のぶかず@lisp &ボドゲ勢ボドゲプレイヤー) @nobkz

@its_out_of_tune アカウンタビリティの問題かなぁと。チームなら、たとえばソースのドキュメント性に関心のあるチームならば、「読みやすいコード」書けってなる事が多い。あと、はチームのスキルレベルにも寄る。

ちゅーん @its_out_of_tune

@nobkz とゆーか、大概はスキルレベルの問題に収束するかなぁとは思ってる。「型理論は難しい」といえばそれまでだし、forallとか出てきたら説明する際にももにょりそうだけど、そのくらい抽象度が高い関数はむしろ値レベルのみで説明させるのは困難なので・・・。

はなだ☆のぶかず@lisp &ボドゲ勢ボドゲプレイヤー) @nobkz

@its_out_of_tune スキルと言っても、それは方向性が違うので、たぶん数学ができる人間でないと難しい。それを、「属人性」と言うかどうかの問題だけど、多くの場合は数学が分かんなくても書けるべきなんだろうなと思っている。

ちゅーん @its_out_of_tune

@nobkz まぁ、大抵Haskellerの言う「型を読めばわかる」は数学わかんなくても解るレベルの話だと思うんだなぁ。俺の場合はJavaあたりから型のドキュメント性を意識しだして、Haskellerになって確信に至って、その感覚が数式の読み方の理解に繋がったのでよーわからん。

はなだ☆のぶかず@lisp &ボドゲ勢ボドゲプレイヤー) @nobkz

@its_out_of_tune まぁ、「数学」というか「数学的能力」の話に近いのかなと。他の言語と比較くしてHaskellを書くとき何かが、「学習コスト」が高い面があって、それはエンジニアとして乗り超えるべきなんですけど、しかし「属人性」ってのがあると言われてるのかなぁとか。

はなだ☆のぶかず@lisp &ボドゲ勢ボドゲプレイヤー) @nobkz

@its_out_of_tune たぶん、なんでしょう、やっぱり関数型言語って、シーケンシャルに記述するようななものだと最近思うのだけど、OOPってむしろ構造的に書く感覚と、それが「型で設計する」ってことに違和感を覚えるのじゃないかなぁと思っています。なんか表現しにくい。

ちゅーん @its_out_of_tune

@nobkz んっ、関数型がシーケンシャルに記述するっていうのは、だいぶ感覚に相違がある気がする。そもそもそこから「宣言的にうんぬん」って言い方がバズワード化する事は無い気がするけども。

はなだ☆のぶかず@lisp &ボドゲ勢ボドゲプレイヤー) @nobkz

@its_out_of_tune まぁ、主観性の言葉を使う議論なんで、まぁ、難しいのですけど、僕にとって、関数的に記述するとかってデータフローなんですよ。そういう意味でシーケンシャルだなぁと思ってます。

ちゅーん @its_out_of_tune

@nobkz 確かにｗ まぁでも、その感覚で言うとOOPも結局はデータフローだよねーとか、堂々巡りになりそうだし、実の所は意識とか認識の問題で、OOPも関数型も大差ない、という感覚に落ち着く。

はなだ☆のぶかず@lisp &ボドゲ勢ボドゲプレイヤー) @nobkz

@its_out_of_tune それが、「ずっとOOPで偉そうにしている、人には分からんのですよ!!!!」というかね。

はなだ☆のぶかず@lisp &ボドゲ勢ボドゲプレイヤー) @nobkz

@its_out_of_tune まぁ、ただ言うと、手続き->OOPの流れっていうのは、以下に構造的にプログラムを書くかって流れなので、むしろシーケンシャルより構造が重視されてるって感じがする。というか、OOPって基本的にGUIを書くためにあると思っているので。

ちゅーん @its_out_of_tune

@nobkz うむ、で、根本的な話をすると、ラムダ計算とか型理論ってチューリング機会よりはずっと、抽象的な構造に寄り添った理論に感じていて、「実用的」な汎用プログラミング言語の目指す方向が構造の埋め込みであれば、手続き->OO->関数型のブームの流れってすごく自然なのかもしれない

青江 憂 @がんばらねば @aoeui666

@its_out_of_tune @nobkz OOとFPのそういう意味での大域的な違いはプログラムのどの部分(のデータや処理の流れ)をどのように切り出すかだと思います. メッセージパッシングなりなんなり. 局所的にはどうなんでしょうね? 僕はFPの方がオートマトン的に書けるので

ちゅーん @its_out_of_tune

@aoeui666 @nobkz しいていうなら「状態を持つか持たないか」かと。

青江 憂 @がんばらねば @aoeui666

Lisper のいう FP+OO と Haskeller のいう FP と Smalltalker のいう OO とではかなりの隔たりがある気がする. 確実に差がある.

青江 憂 @がんばらねば @aoeui666

@its_out_of_tune @nobkz Stateモナドと無限エクステントは…?

はなだ☆のぶかず@lisp &ボドゲ勢ボドゲプレイヤー) @nobkz

@its_out_of_tune @aoeui666 どうでしょう、ただ、なんとなく単純にOOPって言ってもいろんなOOPがあると思うので、その一面としてFP的な部分はあるのかなと。

ちゅーん @its_out_of_tune

@nobkz @aoeui666 ええと、無限エクステントは良くわからないのですが、少なくともStateモナドそれ自体が状態を持つわけでは無いです（この議論の場合はそう解釈すべきというか・・・）

はなだ☆のぶかず@lisp &ボドゲ勢ボドゲプレイヤー) @nobkz

@its_out_of_tune @aoeui666 ただ、とは言うても、Stateモナドの記述自体は状態を管理しているとは思うのでなぁ。なんで、@fumieval 氏のObjectiveは読んでないけど、そこらへんは実際にはあんまり差が無いんじゃないかと思ったりする。

ふみ (DJ Monad) @fumieval

@nobkz @its_out_of_tune @aoeui666 状態をStateモナドに委ねることはできますが、それをこの世界に持っていくためには初期状態を与える必要があります。オブジェクトは状態の型を完全に隠蔽できますが、オブジェクト自体が状態なので、それの管理も必要です。