FRP は非常に一般的な手法であり、通常はイベントを使用するあらゆるものを実装するためにほぼ確実に使用できます。FRP の古典的な表現では、中核となる抽象化の 1 つがイベントです。違いは、コールバックを使用して個別にイベントを操作するのではなく、イベントのストリームを操作することです。
イベントのストリームに関して、通常のイベント駆動型コードをレンダリングできる必要があります。唯一の問題は、ストリームを GUI ツールキットのような既存の外部コードにバインドすることです。ただし、これはトリッキーというより面倒です。したがって、別の言語でイベントを使用する場所で FRP を使用することを妨げる根本的な問題は見当たりません。
実際、私は FRP を使用して、いわゆる「軽い」もの、つまり単純な GUI プログラムに良い経験をしました。私はwxWidgets でリアクティブ バナナを使用して、非常に単純で小さなグラフィカル プログラムを作成しました。結果として得られるコードは、同等のコールバック ベースのコードよりもはるかに単純で、書きやすく、読みやすいことがわかりました。
Reactive Banana はmusicなどにも使用できるため、明らかに広く適用できます。私はそれを使った GUI プログラミング以外は何も試していませんが、他の人はそうしているはずです。
さらに、FRP を使用して Web アプリを実装するための ML スタイルの言語である Elm もチェックしてください。HTML、CSS 、 JavaScriptなど、必要なものがすべて生成されます。サーバーとの通信も処理していると思います。試したことはありませんが、とてもいい感じです。
つまり、「重い」ものではない分野も含め、さまざまな分野で FRP が使用されていることは明らかです。しかし、これはどこでも使用する必要があるという意味ではありません。
1 つには、予測不可能な空間と時間の動作が発生する可能性があります。Reactive Banana と Elm の両方の作成者がこれらを減らすために多大な努力を払っていることは知っていますが、まだリスクがあると思います. Reactive Banana WX で遊んでいるときに非常に奇妙なスペース リークが発生したことはわかっているので、注意が必要です。これらを FRP で処理するのは、使い慣れたイベント駆動型のコードよりも難しいかもしれません。もちろん、標準の JavaScript で不可解なメモリ リークが発生したことがあるので、FRP 以外のコードもこれに影響されません。
もう 1 つの考慮事項は、FRP が特定のタスクにとって最適または最も明確な抽象化ではない可能性があることです。完全に反応する必要があるものには最適ですが、Web サーバーのような非常に単純なコードはどうでしょうか? (異なるリクエストでは、おそらくお互いにあまり密接に相互作用しないので、単純という意味です。) FRP に基づくプログラミング モデルを使用して大量のリクエストを処理する Web フレームワークを持つことは可能であると思います。私はそれが最適だとは思わない。
実際、私の理解では、GHC IO システムは内部ですでにイベント駆動型になっているため、標準的なプログラミング スタイルで Web サーバーを記述し、イベントを無料で使用する利点を得ることができます。そのため、Web サーバー コードの場合は、基になる抽象化を単純化する方が適切な選択になる可能性があります。これは、Snap や Yesod などの既存のフレームワークが行っていることだと思います。どちらもリアクティブ プログラミング スタイルを使用していませんが、どちらも快適に使用できます。