-
- いいね！4
Toshiyuki Takahashi
@tototoshi
@seratch_ja ちなみにQiitaの記事のアプリケーション少し関わってるんですけど、まあここはFutureじゃなくていいよね(jdbcだし)。めでたし、となりました。
2015-03-27 20:46:52
Kazuhiro Sera (瀬良)
@seratch_ja
@tototoshi early return みたいなことしたくなったときのやりづらさとか、もともと別々で走ってた Future に依存関係生まれたとか、待ち合わせしなくいけなくなったとかですかね。書き直せばいいだけですけど、手間が大きいかなという印象があります。
2015-03-27 21:00:33
がくぞ
@gakuzzzz
抽象化による恩恵を享受できないような過剰な抽象化はするな、って話は全く同意。 ただ合成可能な設計を意識するのはテスト書くにも恩恵受けやすいし、それによって、単にビジネスロジックを手続き的に書き下すんじゃなくて、ロジックを型で表現しやすい方向に持っていけると思う
2015-03-28 18:45:15
がくぞ
@gakuzzzz
ScalaのFutureは並行性とエラーという複数の責務を持ってるせいで合成時に考える事が増えたり、標準ライブラリに抽象化して扱う術が無かったりするのが問題なのであって、合成可能なAPIを設計することそのもの自体を止めようとするのは微妙な気がする
2015-03-28 18:49:16
Kenji Yoshida
@xuwei_k
べつにある程度はせらさんの言ってることに賛成だし、自分のブログはあくまで「Futureを扱いつつ、かつエラーの型を限定したい場合」という前提がある場合の話なので、最終的に(ジェネリックがないgo出してきても)もにょるというか qiita.com/edvakf@github/…
2015-03-28 21:50:11
Toshiyuki Takahashi
@tototoshi
Future の話、結局せらさんが Skinny 作ってるからそのポジショントークであって、Play へのあてつけなんだろうなーって思ってあんまマジで考えないようにしてる。
2015-03-28 22:47:08
Kazuhiro Sera (瀬良)
@seratch_ja
@tototoshi そう思われてもいいかと思ってはいますけど。前からああいうことを思っているところから Play に積極的じゃないわけで。あれは私の問題意識としては Skinny つくる前からずっとあって、それがなかったら Skinny も生まれなかったとも言えますね。
2015-03-28 22:55:15
Toshiyuki Takahashi
@tototoshi
非同期縛りがきついとコールバックとかFutureを嫌う皆様には是非ともPHPを書いて同期縛りの辛さを感じてもらいたい
2015-03-28 23:06:14
Atsushi Takayama
@edvakf
@xuwei_k ジェネリック云々はこの文脈ではあまり関係ないのではないでしょうか？「モナドを使う場合と使わない場合でコードの構造がだいぶ変わってしまうのがよくない」という問題は slideshare.net/Odersky/scala-… で言われてることなのではないかと思いました。
2015-03-29 10:40:54
Kenji Yoshida
@xuwei_k
@edvakf モナドを使う場合と使わない場合でコードの構造がだいぶ変わる、のは、一部異なるプログラムにしてるのだからある意味当たり前で、だとしても、それに見合うメリットがあるのだから妥当だと思ってます。あとこういうテクニック eed3si9n.com/ja/the-abstrac… 使えば
2015-03-29 10:46:06
Kenji Yoshida
@xuwei_k
@edvakf goが出てきたことに疑問だったのは、確かにgoは非同期プログラミングが一部やりやすいかもしれないけど、だとしてもEitherTと同じレベルで「非同期プログラミングやりつつエラーの種類の限定やエラー処理やプログラムの綺麗な合成」はおそらく不可能だと思ったので、
2015-03-29 10:49:15
Atsushi Takayama
@edvakf
@xuwei_k そうですね。モナドを使うと決めて全部をそういうスタイルで書くか、使わないと決めてあくまでシンプルに同期的に書くかの二択になるかと思います。モナドを使うならモナドトランスフォーマーまで使うのが良いですね。
2015-03-29 11:24:46
Kenji Yoshida
@xuwei_k
@edvakf モナドトランスフォーマー使いこなせるなら使うでいいと思いますけど、FutureのThrowableの側にエラーが全部潰れるのが辛いと思わない場合は、EitherTやFuture[Option[A]]ではなく全部Future[A]使うという選択肢もありだとは思います
2015-03-29 11:27:56
Kenji Yoshida
@xuwei_k
というわけで(?)便乗してモナドの抽象化についての話を書きました d.hatena.ne.jp/xuwei/20150329… "モナドの本当の力を引き出す・・・モナドによる同期/非同期プログラミングの抽象化"
2015-03-29 12:23:24
Atsushi Takayama
@edvakf
@xuwei_k そうですね。選択肢は色々あるんですが、もし定番があって、コードベースができてしまってから別の書き方にすることを考えなくて良くなるといいですね。
2015-03-29 12:28:30