reactiveな、お話

marble @marblejenka

@ashigeru ね。ところで、リアクティブプログラミングって知ってます？ http://en.wikipedia.org/wiki/Reactive_programming なんかたびたび話してるものっぽい気が。

Suguru ARAKAWA @ashigeru

@marblejenka その話題は半年前くらいにかずのりさんとかが釣れた記憶が。

御徒町@Serializable @okachimachiorz

@marblejenka イベントドリブンでいんじゃね？

Suguru ARAKAWA @ashigeru

@marblejenka 足りるとかどうとかじゃなくて、概念でしかないから、今後の方向でどう活きるかって程度のディスカッションだったような

御徒町@Serializable @okachimachiorz

@marblejenka イベントドリブンって、言葉がUI系で狭義に使われて代名詞になってしまったので、仕切り直した感がありますが>reactive

Suguru ARAKAWA @ashigeru

@okachimachiorz プロセスの時相的な原子化粒度は確かに今後意味合いが弱くなるかも。データの原子化粒度の面で考えた方が良さそうですね

Suguru ARAKAWA @ashigeru

@marblejenka たしかその時はExcelの話で盛り上がった気が。かずのりさんが最近おっしゃってたデータバインディングもその辺りの話題ですね

marble @marblejenka

@okachimachiorz ああ、なるほど。本質的に何か違うという話ではないということですか。。 >reactive

pokarim @pokarim

@marblejenka @okachimachiorz reactiveとイベントドリブンは、本質的に違うと思います。在庫=SUM(入庫)-SUM(出庫)として在庫が自動更新されるのがreactiveで、入庫が追加->在庫+=入庫 を明示的に記述するのがイベントドリブンです。

御徒町@Serializable @okachimachiorz

@pokarim レスどうもです。あら。えっと、在庫＝SUM（入庫）-SUM（出庫）っていうと非同期バッチ処理処理っぽくみえるですが、・・・reactiveっていうと、何かの入力に対して「reactive」に処理が走る、とおもっていましたが。違いますかね？

marble @marblejenka

@pokarim @okachimachiorz なるほど。でも、reactiveにやるときって、在庫の計算をしているときに入出庫されたらどうなっちゃうのかなと思いました。

御徒町@Serializable @okachimachiorz

う～ん、不勉強だな・・・いかん。reactiveってどんな定義かね。そもそも計算がpropagationしていく感じだったのだが・・・違うのかｗ

pokarim @pokarim

@okachimachiorz @marblejenka reactiveやeventという言葉自体は一般的な言葉で、reactive programmingが指す対象も文脈によってぶれがあるようです。そこらへんはあとで調べ直します。

pokarim @pokarim

@okachimachiorz とりあえず自分が理解をもとに話します。イベントに反応するという意味ではイベントドリブンとreactiveは同じです。反応の記述をアクションとして記述する方法が前者で、タイミングによらない静的な関係式として記述するのが後者です。

御徒町@Serializable @okachimachiorz

@pokarim あぁなるほど、確かに記述方法としては違いますね。自分的にはプログラミングの記述方法というよりは、処理の伝播という側面で見ていました。

御徒町@Serializable @okachimachiorz

reactive programingって言う感じだと、割と汎用的な記述になるのかな。ぬ・・・・。一般的にそうとは限らないけど、そう書けるって感じか。フレームワークみたいなものを作る時には便利かも。

pokarim @pokarim

@okachimachiorz そうですね。記述方法が違うだけで、結果的に行われる処理は同じですね。なにを持って"本質"とするかは難しいものですね。いかに記述を簡単にするかばかり考えているので見方が偏っていたかもしれないです。

御徒町@Serializable @okachimachiorz

@pokarim なるほど、勉強になります。reactiveの方が汎用性が高いように見えますが、記述の難易度は上がるよう気がしますね。

pokarim @pokarim

@okachimachiorz Reactiveの例によくでるのがExcelです。ポイントは、値の計算方法だけ記述すれば、計算のタイミングや依存関係について考えなくていいところです。記述の難易度がどうなるかは、簡単には言えないと思いますが、記述量は確実に減ります。

marble @marblejenka

@pokarim なるほど。そりゃそうですね。。平行性とかサポートしてくれる仕組みがあったらいいなあとおもって聞いてみました。

御徒町@Serializable @okachimachiorz

@pokarim 同意ですね。記述量は減ると思います。その分事前の設計や想定しているインプット・アウトプットへの考慮が必要ですね。センスが大事かと。

pokarim @pokarim

@okachimachiorz そうですね。命令型->関数型のようなパラダイムチェンジは必要かもですが、消し込み処理のようなものや、依存関係が複雑になった場合には、理論的には相対的な利点が増すと思います。実証実験はこれからです。センスはどこまでいっても大事でしょうね。。。

御徒町@Serializable @okachimachiorz

@pokarim なるほど～。staticにだらだら記述するのは、あるレベルで限界になりますが、とは言え何でもdynamicというのも、「動くのかそれわ」みたいな感じにもなるので・・・・制限的にかつ幅を持たせて簡潔に、というのはいい感じですね。

pokarim @pokarim

@okachimachiorz static記述するのに限界があるというのは、パフォーマンスやスケーラビリティについてなら同意です。いまのところ分散や非同期を考えなくて済む比較的小規模なアプリに焦点をあてています。個人的には遠い未来にはMRとも統合されると思っていますが。

御徒町@Serializable @okachimachiorz

@pokarim 現場的に言うと、MRとの統合は比較的近い可能性もあるかなと思います。MR的なところは現実的に基本staticに書けない部分も多い（正確に言うとstaticに書きすぎると生産性が下がる）ので、今パラダイムを模索中というところだと思っています。