最近ですね、FRPはいまいち筋が悪いのではないかと

おしいれのぼうけん @osiire

最近ですね、FRPはいまいち筋が悪いのではないかと思うようになってきたのです。少なくともプログラムの中で完結する使い方としては。やはりpureにドンドンドンと変換を回すべきであって、副作用を推奨しちゃイカンですよ。

pokarim @pokarim

@osiire FRPは筋が悪いというのは同意です。というか実用的な側面が非常に限られると思います。

pokarim @pokarim

@osiire 関数型言語上に内部DSL的に実装することが難しいのではないかというのもありますが、一番大きいのはリアクティブプログラミングの利点が出易いのは、閉じたシステムなんじゃないかということです。

pokarim @pokarim

@osiire 例えばDBMSとのやり取りを、単なるネットワークIOのイベントストリームとしてFRPで記述しても、モナドで手続きを記述するのとあまり変わらないと思います。それに比べてSTMの内部の依存関係を記述するのならばFRPの利点が出易いと思います。

おしいれのぼうけん @osiire

@pokarim 内部DSL的に実装する事は別に難しくはないです。私ですらある程度まで出来るくらいには簡単。利点が出やすいのは閉じたシステムというのに同意。そもそも小さい物を組み合わせて大きくするのが良いのに、組み合わせてもドンドン小さいものが連鎖していくだけって管理しきれない。

pokarim @pokarim

@osiire GUIの中で閉じた依存関係ならFRPに向くと思います。しかしWebアプリのサーバサイドをきれいにFRPで記述するなら、http,html,javascriptをまるまる含めてモデル化する必要があって、httpのIOだけをFRPで抽象化しても仕方ないと思います。

pokarim @pokarim

@osiire 確かに内部DSLだから難しいというのは間違いでした。HTML、ブラウザ側まで含めた環境全体を抽象化するような場合は、内部DSLにする意義が相対的に低くなるとは思います。

おしいれのぼうけん @osiire

@pokarim あぁ、そこまで広く考えるのですか。でも、もっと狭くても、例えGUIの中に閉じてても、いまいちだと思います。

おしいれのぼうけん @osiire

根と葉の関係が逆なんですよね。普通の関数型の書き方と。葉を集めて根にしてドンっていうのが簡単なのに、FRPは葉が散らばっちゃうのですよ。

pokarim @pokarim

@osiire そもそもGUIの中に完全に閉じていることは少なくて、裏にDBMSか何かがあることの方が多いというのもあると思いますが、かりにGUIで閉じていたとしてもいまいちだとすれば、原因は他に考えられます。

おしいれのぼうけん @osiire

散らばった物は遅延評価で無視することも普通は出来るのに、リアクティブシステムは問答無用に外部から情報が入ってくるから無視できない。こういう事情もある気がします。

pokarim @pokarim

@osiire まだ理論的な説明ができず直感的になってしまいますがお許しください。GUIの中に閉じていてもFRPが微妙だとしたら、それは適切なデータモデルがないからだと思います。

おしいれのぼうけん @osiire

@pokarim ううーん。適切なデータモデルですか？

pokarim @pokarim

@osiire GUIで閉じているとしたら、その中で持っている状態がそのシステムの全てで、ユーザからみれば、それはデータベースのようなものだとみなせると思うんです。その状態と依存関係をいかに適切に記述できるかどうかというのは、データモデル次第だと思います。

おしいれのぼうけん @osiire

@pokarim あー、なるほど。仰るとおりですね。そのデータモデルをうまく設計すると、規模の大きい依存関係は無くせるんじゃないかと疑っているのです。そしてFRPも要らなくなる。少なくともGUIでは。

pokarim @pokarim

@osiire そう思います。依存関係の中にも、アプリのユーザ側から見て本質的な物と、そうでない実装や最適化のための低レベルなものの両方があるんだと思います。そして後者は全体を最適化させれば消すことができます。

pokarim @pokarim

@osiire たとえばGUIの裏にDBMSがあったとして、DBMS側のスキーマレベルで本質的な依存関係が記述されていれば、GUIレベルの挙動はそこから自動的に決まってくるはずです。

おしいれのぼうけん @osiire

@pokarim はい、決まる部分もあります。でも最近はUIに特有の情報が多いので、全部は決まらないと思います。例えばアニメーションが終わったら、ボタンが現れるとかいう関係は、DBMSとは関係なく存在します。

pokarim @pokarim

@osiire それはもちろんです。ただ、簡単にウィジェット的なものとしてうまく部品化できるのなら、その中の実装の記述方法は問題にならないと思います。逆にうまく部品化できない場合、それは裏にあるデータモデルとどうしても密に絡む部分があるからだと思います。

pokarim @pokarim

@osiire ウィジェットのモジュール性再利用性を高めるためにこそ、ウィジェットのモデルと、裏にある本質的なデータモデルとの整合性がとれていることが重要だと思います。

pokarim @pokarim

@osiire たとえば、CSSとHTMLもデザインと構造の分離ですが、コアとなるデータモデルが適切であればあるほどその分離がうまく行き、そこがうまく分離できさえすれば問題はあらかた解決すると思います。

おしいれのぼうけん @osiire

@pokarim 整合性についてはそうですし、分離した後にFRP的な記述が依存表現に便利なのは分かります。でも、GUIプログラミング的には、実はウィジットという考え方自体を止めたらもっとpurelyに書けるのではないかと思っています。段々FRPから話が遠ざかって恐縮ですが。

おしいれのぼうけん @osiire

すみません、離脱します！

pokarim @pokarim

@osiire たしかにFRPの純粋な範疇から離れつつあるとは思いますが、全体を見て適切にモデル化することこそが重要だと思っているので望むところです。

pokarim @pokarim

@osiire ウィジェットに関しても同意です。どんなイメージをされているかはもちろんわからないのでぜひもう少し教えていただきたいですが、ウィジェットという言葉を使ったのはあくまで仮にです。