非純粋関数型言語の純粋関数と純粋関数型言語メモ 続き

前編はこちら https://togetter.com/li/1811866 前編を編集不可にしてしまったので続編作りました。 こちらは編集可にしてあるので不測あれば自由に足してください。
1
前へ 1 2 ・・ 14 次へ
. @sundaycrafts

> I/Oの存在自体をドメインロジックから消し去れないかと考えた方がいい。 確かに。 クリーンアーキテクチャではドメインロジックがなんであるかという話はあまりなかったですが、つまりそういうことですね。 twitter.com/sugimoto_kei/s…

2021-12-05 13:06:06
杉本啓 @sugimoto_kei

賛成。クリーンアーキテクチャは、I/Oの実装をドメインロジックから追い出そうとするが、それより先に、I/Oの存在自体をドメインロジックから消し去れないかと考えた方がいい。いつもそうできるわけではないが、出来る場合も多い。 twitter.com/j5ik2o/status/…

2021-12-05 09:44:52
Kory @Kory__3

@cactaceae なるほど、ありがとうございます(それはその通りだと思います)

2021-12-05 13:06:10
r.ishibashi @cactaceae

@Kory__3 正確に表現を教えていただけて助かりました。

2021-12-05 13:06:45
r.ishibashi @cactaceae

@Kory__3 少し補足させてください 純粋関数とエフェクトシステムは強力な道具です。その前提で、「純粋関数ライブラリを除いた純粋関数型プログラミング言語”だけ”が銀の弾丸である」という主張と、Haskellをやらない人は極端が怖くて退路を用意したがり想像で批判しているという主張に意義を申したかったです

2021-12-05 14:43:48
r.ishibashi @cactaceae

気分を悪くさせてしまったようで申し訳ない。 pic.twitter.com/jJE90hsWbI

2021-12-05 14:46:45
拡大
Kenji Yoshida @xuwei_k

@cactaceae 遅延評価はそんなに関係ない気がするんですが、遅延評価だとやりやすい、と思ったのはどのあたりが・・・?

2021-12-05 15:18:45
r.ishibashi @cactaceae

@xuwei_k Redditの議論みてるとHaskellのシステム全体が遅延評価を前提にしていてそれが自然に反映されているのと、最適化されているという話もでてたので触れました。

2021-12-05 15:35:21
r.ishibashi @cactaceae

@xuwei_k あと想像と期待が多分に入っているんですがその最適化がJITコンパイラやRDMBSの実行計画のようなレベルにあるのか(あるいは到達する)とか考えたら楽しくなってました あと、完全な遅延評価を前提にしたら僕が以前考えたアーキテクチャも変わっていたなーとか考えてました。

2021-12-05 15:36:44
慎ましく暮らす人 @qtamaki

@cactaceae なるほど読みました。プログラムの純粋性に関する疑問について私の解釈でいうとこのブログの通りです。Monadについては純粋と非純粋の領域を分けるために(も)使えますがそれ自身は純粋ですね qtamaki.hatenablog.com/entry/2015/01/…

2021-12-05 15:25:05
Kory @Kory__3

@cactaceae うーん、二つ目はどこから来たのかよく分かりませんが、一つ目に関してはcubbitさんは元ツイでそのように主張していないように思えますね

2021-12-05 15:31:55
Kory @Kory__3

@cactaceae 「内部が見えるデータ型と副作用(を表すデータ型)をはっきり分ける」を目指したい場合標準でunsafeなことをすることが難しい純粋関数型言語の方が楽に達成できそう、というのはそれはそうではなかったりしませんか?

2021-12-05 15:33:20
r.ishibashi @cactaceae

@Kory__3 元ツイではそうですが、その後の僕へのツイートについてはそういうスタンスだったと感じました。誤解ならただただ申し訳ないですが。。。 2つ目は別の人です。

2021-12-05 15:38:45
r.ishibashi @cactaceae

@Kory__3 それはそう思います。 そのため関数型プログラミングのパラダイムに初めて取り組むならHaskellはベストだと思っています。

2021-12-05 15:40:03
r.ishibashi @cactaceae

@Kory__3 2つ目についても、cubbitさんは言葉で説明するのではなく、「cactaceaeはHaskellを書いてないから誤解している。とにかくHaskellのコードを書け」と繰り返し言っていたのでそう思ってるんじゃないですかね。。。。

2021-12-05 15:43:34
Kory @Kory__3

@cactaceae (やり取りには関与しませんが、一応技術的な補足をすると)純粋性の定義に関しては(Scalaであっても)普通Cubbitさんが提示したものが利用されてそうです

2021-12-05 15:51:49
r.ishibashi @cactaceae

@Kory__3 僕も一応そういう理解ではあります。 ただ現実にある重要な課題について正確で良い表現が見つかりませんでした。。。

2021-12-05 15:55:40
r.ishibashi @cactaceae

@Kory__3 あとここで、明確に純粋関数型言語では意識して書き分ける必要がないと言ってるんですが、このあたりはどう解釈されます? pic.twitter.com/Tds9zdOxbC

2021-12-05 15:59:31
拡大
Kory @Kory__3

@cactaceae cats-effectのようなライブラリを使っている場合、Scalaは(純粋性の観点で)unsafeな操作が(良かれ悪かれ)非常に簡単に書けてしまうため、厳密な純粋性を要求したいような箇所では「非純粋になってしまっていないか」どうかを常に意識し続ける必要があり、(続)

2021-12-05 16:09:54
Kory @Kory__3

@cactaceae その点、Haskellを利用していれば比較的簡単に(unsafeなことをしていなければ)プログラム全体で純粋性に関する保証が得られるので、その意味で「書き分ける必要が無い」というのがありそうです

2021-12-05 16:11:46
r.ishibashi @cactaceae

@Kory__3 それも話が食い違っていたということですかねー

2021-12-05 16:19:48
r.ishibashi @cactaceae

@xuwei_k @Kory__3 どうしたらよかったんでしょうね。。。。

2021-12-05 16:27:40
Kenji Yoshida @xuwei_k

@cactaceae @Kory__3 Haskell使ったら(unsafePerformIOなどの一部の例外除き)全体が勝手に純粋なプログラムになるのと Haskell使ったからといって大半の関数がIOなどのシグネチャだらけになったら、せっかくHaskell使う意味が減る(でもプログラムとしては純粋) は別問題なはずなので、

2021-12-05 16:08:34
Kenji Yoshida @xuwei_k

@cactaceae @Kory__3 言葉の使い方や解釈が違うというか、話の前提が共有されてないままずっと議論してる雰囲気を感じたので、 すると議論してもああなるだろうなぁというか

2021-12-05 16:08:55
前へ 1 2 ・・ 14 次へ