機能的リアクティブプログラミングとアクターモデルはどのように相互に関連していますか？

FRPは、純粋な機能によるイベントと動作のストリーミングに関するものです。少なくともAkkaで実装されているアクターモデルは、アクターと呼ばれる不純なオブジェクトを介した不変メッセージ（離散イベントと見なすことができます）のストリーミングに関するものです。

したがって、表面上はそれらは関連しているように見えます。

それらがどのように関連しているかについて、他に何を言えますか？また、それらのどれが異なるアプリケーションドメインにより適切であるかもしれないかについて何が言えるでしょうか？

アクターもFRPもストリーミングに関するものではありません。アクターは、出力ストリームの外部構成もサポートしていません。

FRPは、線形タイムライン上のモデリングシグナルとイベントによって強く特徴付けられ、FRPの動作を決定論的に構成できます。アクターは、メッセージを非決定的な順序で処理することを強く特徴としており、構成上のプロパティはほとんどありません（つまり、2つのアクターの配置をより大きなアクターとして扱うことはできません）。

類似性を求めている場合、アクターとFRPの両方がラムダ計算と密接な関係にあります。どちらも人間の入力に応答するシステムをモデル化できます。どちらも内部（ローカル）状態のモデリングをサポートしています。

FRPは積分またはアキュムレータ（時間の経過に伴う）を通じてローカル状態をサポートし、アクターモデルは各アクターが現在のメッセージに応じて次のメッセージの動作を指定できるようにすることで状態をサポートします。ローカル状態に対するこの広範なサポートにより、FRPとアクターの両方がライブプログラミング（またはプログラムコードのランタイムアップグレード）に不十分になります。重要な状態を失うことはあまりにも簡単になります。

アプリケーションドメインについて：

アクターモデルは、実行時にアクターをインストールまたは保守するオープンシステムに適しています。また、アクターモデルは分散システムにあまり適していません。メッセージの非決定的な順序付けにより、実装の適合が容易になるためです。（アクターが分散システムにあまり適していない理由は、混乱に直面してメッセージが「一度だけ」到着することを保証することが非常に困難であり、アクターも分散GCを必要とする傾向があるためです）。

FRPは、時間の経過とともに動作するクローズドシステム（ロボットコントローラー、音楽プログラミング、コンピューター玩具など）に適しています。決定論と構成の機能により、少なくともFRPがソリューションを直接モデル化できる場合は、アクターよりもFRPの操作が便利になります。FRPを効果と統合すること（特に、モデルを不純物でハッキングすることなく）は難しいことがわかっています。「ワームホール」を介した効果的なFRPに関する最近の研究があります-リソースへの効果的、一意、または線形の型付きアクセス。

FRPとアクターの間のどこかにある他のモデルがあります。

John Paul Morrisonによって開発されたFlow Based Programming（FBP）は、メッセージのストリーミングを実際にサポートしています。

タイムワーププロトコル（または、ライトタイムタイムワープ（LTW）の最近の研究）は、論理的なタイムラインに俳優のようなメッセージを配置して、メッセージ制御のより制御された構成概念を提供します。タイムワープは、科学計算などの大規模な並列および分散システムによく使用されます。元のタイムワープは対話型シミュレーション（人間の入力に対する応答性）には適さず、LTWはわずかに適しています。

私は、オープンシステムおよび分散システムで信号のレスポンシブ、コンポジション、FRPのような操作および処理を可能にし、ローカル状態を排除するリアクティブデマンドプログラミング（RDP）を開発しています。RDPは、経時的な信号によるリソース状態への可換でべき等の影響に副作用を制限することによって実現されます。RDPでは、リソースモデルと状態モデルを再考する必要があります。

私はそれらが実際の観点からどのように異なるかを指摘したい：

1）アクターは他のアクターにメッセージを送信します。このメッセージの受け渡しは明示的かつ強制的に記述されます。

例えば：

send msg to Actor137。

2）FRPでは、データフローは宣言的に記述されています。

例えば：

Cell134=Cell185+Cell42。

メッセージの受け渡しはFRPフレームワークによって処理され、1つのセル（アクター、カプセル化状態、または動作）から別のセルにメッセージを渡す方法を「手動で」記述する必要はありません。

言い換えると：

関数型リアクティブプログラミングの本質は、宣言時に値の動的な動作を完全に指定することです。したがって、のすべての依存関係はCell134宣言ポイントで定義されます。

これは、アクターモデルには当てはまりません。アクターの動作に影響を与えるアクターAは、アクターが定義されているソースコード内の同じ場所で定義されていませんA。

最近、2つの間に興味深いハイブリッドがあることに気付きました。Akkaストリーム。データフローは宣言的に記述されていますが、アクターを使用して実装されています。

別の違いは次のとおりです。アクターは非同期になる傾向がありますが、FRPは同期する傾向があります（多くの場合、グリッチはありません）。