現在の機能的リアクティブプログラミングの実装のステータスはどうなっていますか？
Haskellでいくつかの単純な自動物理システム（振り子、ロボットアームなど）を視覚化しようとしています。多くの場合、これらのシステムは次のような方程式で記述できます。
df/dt = c*f(t) + u(t)
u(t)は、ある種の「インテリジェント制御」を表します。これらのシステムは、機能的リアクティブプログラミングパラダイムに非常にうまく適合するように見えます。
そこで私はPaul Hudakの本「The Haskell School of Expression」を手に取り、そこに提示されたドメイン固有言語「FAL」（Functional Animation Language用）が実際に私の単純なおもちゃシステム（特にintegrateは、効率的に使用するには少し遅すぎるように見えましたが、簡単に修正できます）。
私の質問は、今日のより高度な、または実用的なアプリケーションのための、より成熟した、最新の、よく維持された、パフォーマンス調整された代替物は何ですか？
このWikiページ Haskellのいくつかのオプションがリストされていますが、次の点については明確ではありません。
このプログラミングパラダイムの発明者の1人である（理解しているように）Conal Eliottのプロジェクトである "reactive"のステータスは少し古くなっています。私は彼のコードが大好きですが、他の最新の代替手段を試すべきでしょうか？構文/パフォーマンス/実行時の安定性に関して、それらの主な違いは何ですか？
2011年の 調査 から引用するには、セクション6、「... FRPの実装は、ドメインで効果的に使用できるほど十分に効率的または予測可能です。待ち時間の保証が必要です...」。調査では、FRPが15年以上存在しているという事実を考慮して、いくつかの可能な最適化が提案されていますが、このパフォーマンスの問題は何かveryまたは少なくとも数年以内に本質的に解決することさえ困難です。これは本当ですか？
調査の同じ著者は、彼の blog で「時間リーク」について語っています。問題はFRPに固有のものですか、それとも純粋で厳密ではない言語でプログラミングするときに一般的に発生するものですか？十分なパフォーマンスが得られないとしても、FRPベースのシステムを長期にわたって安定させるのが非常に難しいと感じたことはありますか？
これはまだ研究レベルのプロジェクトですか？プラントエンジニア、ロボットエンジニア、金融エンジニアなどの人々は、実際に（ニーズに合った言語で）それらを使用していますか？
私は個人的にHaskellの実装を好みますが、他の提案も受け入れています。たとえば、Erlangを実装することは特に楽しいでしょう。それでは、インテリジェントで適応性のある自己学習型のサーバープロセスを簡単に構築できます。
現在、機能的なリアクティブプログラミングのために、主に2つの実用的なHaskellライブラリがあります。両方とも一人で保守されていますが、他のHaskellプログラマーからもコード提供を受けています：
Netwire 効率、柔軟性、予測可能性に焦点を当てています。独自のイベントパラダイムがあり、ネットワークサービスや複雑なシミュレーションなど、従来のFRPが機能しない領域で使用できます。スタイル：適用的および/または矢印付き。最初の著者およびメンテナー：ErtugrulSöylemez（これは私です）。
reactive-banana は、従来のFRPパラダイムに基づいています。使用することは実用的ですが、従来のFRP研究の基盤としても機能します。その主な焦点はユーザーインターフェイスにあり、wxへの既製のインターフェイスがあります。スタイル：適用。初期の著者およびメンテナー：ハインリッヒアプフェルムス。
両方を試してみてください。ただし、アプリケーションによっては、どちらかがより適していると思われます。
ゲーム、ネットワーク、ロボット制御、シミュレーションには、Netwireが役立ちます。これらのアプリケーション用の既製のワイヤが付属しています。これには、さまざまな有用な差分、積分、および透過的なイベント処理のための多くの機能が含まれます。チュートリアルについては、Control.Wireリンクしたページのモジュール。
現在、グラフィカルユーザーインターフェイスの最適な選択肢は、リアクティブバナナです。既にwxインターフェース（別のライブラリーreact-banana-wxとして）があり、Heinrichはコードサンプルを含むこのコンテキストでFRPについて多くのブログを書いています。
他の質問に答えるには：FRPは、リアルタイムの予測可能性が必要なシナリオには適していません。これは主にHaskellによるものですが、残念ながらFRPを低レベルの言語で実現することは困難です。 Haskell自体がリアルタイム対応になるとすぐに、FRPもそこに到達します。概念的には、Netwireはリアルタイムアプリケーションに対応しています。
タイムリークは主にモナドフレームワークに関連しているため、もはや実際の問題ではありません。実用的なFRP実装は、単純にモナドインターフェイスを提供しません。 Yampaがこれを開始し、Netwireとリアクティブバナナの両方がその上に構築されています。
現在、FRPを使用した商用プロジェクトや大規模プロジェクトはありません。図書館の準備はできていますが、人々はまだ準備ができていないと思います。
すでにいくつかの良い答えがありますが、私はあなたの特定の質問に答えようとします。
時間漏れの問題があるため、reactiveは深刻なプロジェクトには使用できません。 （＃3を参照）。最も類似した設計の現在のライブラリはリアクティブバナナであり、これはインスピレーションとしてリアクティブを使用して開発され、Conal Elliottとの議論の中で作成されました。
Haskell自体はハードリアルタイムアプリケーションには不適切ですが、場合によってはソフトリアルタイムアプリケーションにHaskellを使用することもできます。私は現在の研究に精通していませんが、これが克服できない問題だとは思いません。 Yampaのようなシステム、またはAtomのようなコード生成システムのいずれかが、これを解決するための最良のアプローチであると思われます。
「タイムリーク」は、切り替え可能なFRPに固有の問題です。システムが古いオブジェクトを解放できない場合にリークが発生するのは、将来のある時点で切り替えが発生した場合に必要になる可能性があるためです。メモリリーク（非常に深刻な場合があります）に加えて、別の結果として、切り替えが発生すると、現在の状態を生成するために古いオブジェクトのチェーンがトラバースされる間、システムが一時停止する必要があります。
Yampaや古いバージョンのリアクティブバナナなどの切り替え不可能なfrpライブラリは、タイムリークの影響を受けません。切り替え可能なfrpライブラリは通常、2つのスキームのいずれかを使用します。FRP値が作成される特別な「作成モナド」を使用するか、「エージング」タイプのパラメーターを使用して切り替えが発生するコンテキストを制限します。 elerea （そしておそらくnetwire？）は前者を使用しますが、最近のリアクティブバナナとグレープフルーツは後者を使用します。
「切り替え可能なfrp」とは、Conalの関数switcher :: Behavior a -> Event (Behavior a) -> Behavior aまたは同一のセマンティクスを実装するものを意味します。これは、実行中にネットワークの形状が動的に切り替わることを意味します。
これは、@ ertesのモナドインターフェイスに関するステートメントと実際には矛盾していません。MonadのEventインスタンスを提供すると、時間のリークが発生し、上記のアプローチのいずれかでは定義できなくなります同等のMonadインスタンス。
最後に、FRPでやるべきことはまだたくさんありますが、新しいプラットフォーム（reactive-banana、elerea、netwire）のいくつかは安定しており、信頼性の高いコードを構築できるほど成熟していると思います。しかし、優れたパフォーマンスを得る方法を理解するためには、多くの時間を費やして入念な学習が必要になる場合があります。
Monoと.Netのスペースにあるアイテムをいくつかリストし、もう少し前に見つけたHaskellスペースのアイテムをリストします。 Haskellから始めます。
エルム- リンク
そのサイトごとの説明：
Elmは、フロントエンドWeb開発をより快適にすることを目指しています。 HTML、CSS、およびJavaScriptのシステム上の問題を修正するGUIプログラミングへの新しいアプローチを紹介します。 Elmを使用すると、視覚的レイアウトをすばやく簡単に操作し、キャンバスを使用し、複雑なユーザー入力を管理し、コールバック地獄から脱出できます。
[〜＃〜] frp [〜＃〜] の独自のバリアントがあります。例を使ってみると、かなり成熟しているようです。
リアクティブ拡張機能- リンク
フロントページの説明：
Reactive Extensions（Rx）は、監視可能なシーケンスとLINQスタイルのクエリ演算子を使用して、非同期およびイベントベースのプログラムを作成するためのライブラリです。開発者はRxを使用して、Observableで非同期データストリームを表し、LINQ演算子を使用して非同期データストリームを照会し、スケジューラを使用して非同期データストリームの同時実行性をパラメーター化します。簡単に言えば、Rx = Observables + LINQ + Schedulersです。
Reactive ExtensionsはMSFTから来ており、イベントの処理を簡素化する多くの優れた演算子を実装しています。 オープンソース たった数日前でした。非常に成熟しており、本番環境で使用されています。私の意見では、TPLライブラリが提供するよりもWindows 8 APIの方が優れたAPIだったでしょう。オブザーバブルはホットとコールドの両方であり、再試行/マージなどが可能であるため、タスクは常に、実行中、フォールト済み、または完了したホットまたは完了した計算を表します。
非同期性のためにRxを使用してサーバー側のコードを記述しましたが、C＃で機能的に記述することは少し面倒なことを認めなければなりません。 F＃にはラッパーがいくつかありますが、グループは比較的閉鎖的であり、他のプロジェクトのようにMSFTによって昇格されないため、API開発を追跡するのは困難でした。
そのオープンソーシングは、IL-to-JSコンパイラのオープンソーシングによってもたらされたため、おそらくJavaScriptまたはElmでうまく機能する可能性があります。
RabbitMQやSocksJSなどのメッセージブローカーを使用して、おそらくF＃/ C＃/ JS/Haskellを非常にうまくバインドできます。
Bling UI Toolkit- リンク
フロントページの説明：
Blingは、MicrosoftのWPF/.NETで画像、アニメーション、インタラクション、視覚化を簡単にプログラミングするためのC＃ベースのライブラリです。 Blingは、豊富なUIデザインアイデアのラピッドプロトタイピングを支援するために、設計技術者、つまり時々プログラミングを行うデザイナーを対象としています。学生、アーティスト、研究者、愛好家も、Blingがアイデアや視覚化をすばやく表現するためのツールとして役立つことを理解するでしょう。 BlingのAPIとコンストラクトは、プロダクションコードの注意深いプログラミングではなく、スローアウェイコードの高速プログラミング向けに最適化されています。
無料 LtU-article 。
私はこれをテストしましたが、クライアントプロジェクトでは使用しませんでした。見た目は素晴らしく、値間のバインディングを形成するニースC＃演算子のオーバーロードがあります。 WPF/SL /（WinRT）の依存関係プロパティをイベントソースとして使用します。その3Dアニメーションは、適切なハードウェアでうまく機能します。視覚化を必要とするプロジェクトに行き着いた場合、これを使用します。おそらくWindows 8に移植しています。
ReactiveUI- リンク
以前はMSFTで、現在はGithubであるPaul Bettsがそのフレームワークを作成しました。私はそれをかなり広範に扱っており、モデルが好きです。それはBlinkよりも分離されています（Rxとその抽象化を使用するという性質から）-それを使用してコードを単体テストするのが簡単になります。 Windows用のgithub gitクライアントはこれで書かれています。
コメント
リアクティブモデルは、ほとんどのパフォーマンスが要求されるアプリケーションに十分なパフォーマンスを発揮します。ハードリアルタイムを考えているのであれば、ほとんどのGC言語には問題があると思います。 Rx、ReactiveUIは、GCが必要な小さなオブジェクトをいくつか作成します。これは、サブスクリプションが作成/破棄され、コールバックのリアクティブ「モナド」で中間値が進行するためです。一般的に.Netでは、コールバックは静的（コンパイル時に既知、割り当てなし）であり、タスクは動的に割り当てられ（不明、すべての呼び出しにはインスタンスが必要、ガベージ作成）、ラムダはコンパイルされるため、タスクベースのプログラミングよりもリアクティブプログラミングを好むコンパイラ生成クラス。
明らかにC＃とF＃は厳密に評価されるため、ここではタイムリークは問題になりません。 JSについても同じです。ただし、再生可能またはキャッシュされたオブザーバブルでは問題になる可能性があります。