90

Haskellでいくつかの単純な自動物理システム（振り子、ロボットアームなど）を視覚化しようとしています。多くの場合、これらのシステムは次のような方程式で記述できます。

df/dt = c*f(t) + u(t)

ここで、u(t)はある種の「インテリジェント制御」を表します。これらのシステムは、関数型リアクティブプログラミングパラダイムに非常にうまく適合しているように見えます。

そこで、PaulHudakの「TheHaskellSchool of Expression」という本を手に取ってみたところ、そこにあるドメイン固有言語「FAL」（機能アニメーション言語）は、私の単純なおもちゃのシステムで実際に非常にうまく機能することがわかりました（ただし、一部の機能、特にintegrate、効率的に使用するには少し怠惰すぎるように見えましたが、簡単に修正できます）。

私の質問は、今日のより高度な、あるいは実用的なアプリケーションのための、より成熟した、最新の、よく維持された、パフォーマンスが調整された代替手段は何ですか？

このwikiページにはHaskellのいくつかのオプションがリストされていますが、次の点についてははっきりしていません。

  1. このプログラミングパラダイムの発明者の1人であるConalEliottのプロジェクトである「reactive」のステータスは少し古くなっているように見えます。私は彼のコードが大好きですが、他のより最新の代替案を試す必要があるかもしれません。構文/パフォーマンス/ランタイム安定性の観点から、それらの主な違いは何ですか？

  2. 2011年の調査、セクション6から引用すると、「 ... FRPの実装は、遅延の保証が必要なドメインで効果的に使用するには、パフォーマンスが十分に効率的または予測可能ではありません...」。調査はいくつかの興味深い可能な最適化を示唆していますが、FRPが15年以上存在するという事実を考えると、このパフォーマンスの問題は、少なくとも数年以内に解決するのが非常にまたは本質的に難しいものである可能性があるという印象を受けます。これは本当ですか？

  3. 調査の同じ著者は彼のブログで「時間の漏れ」について話します。この問題はFRPに固有のものですか、それとも純粋で厳密でない言語でプログラミングするときに一般的に発生する問題ですか？十分な性能がない場合でも、FRPベースのシステムを長期にわたって安定させるのが難しすぎることに気付いたことがありますか？

  4. これはまだ研究レベルのプロジェクトですか？プラントエンジニア、ロボット工学エンジニア、金融エンジニアなどの人々は実際にそれらを使用していますか（彼らのニーズに合った言語で）？

私は個人的にHaskellの実装を好みますが、他の提案も受け付けています。たとえば、Erlangを実装するのは特に楽しいでしょう。そうすれば、インテリジェントで適応性のある自己学習型サーバープロセスを簡単に作成できます。

4

3 に答える 3

83

現在、関数型リアクティブプログラミング用の実用的なHaskellライブラリが主に2つあります。どちらも独身者によって維持されていますが、他のHaskellプログラマーからもコードの貢献を受けています。

  • Netwireは、効率、柔軟性、および予測可能性に重点を置いています。独自のイベントパラダイムがあり、ネットワークサービスや複雑なシミュレーションなど、従来のFRPが機能しない領域で使用できます。スタイル：適用可能および/または矢印付き。最初の作者およびメンテナ：ErtugrulSöylemez（これは私です）。

  • 反応性バナナは、従来のFRPパラダイムに基づいています。実用的ですが、古典的なFRP研究の基礎としても機能します。その主な焦点はユーザーインターフェイスにあり、wxへの既製のインターフェイスがあります。スタイル：適用可能。最初の作者およびメンテナ：ハインリッヒ・アフェルムス。

両方を試してみてください。ただし、アプリケーションによっては、どちらか一方の方が適している可能性があります。

ゲーム、ネットワーキング、ロボット制御、シミュレーションでは、Netwireが便利です。さまざまな便利なディファレンシャル、インテグラル、透過的なイベント処理のための多くの機能など、これらのアプリケーション用の既製のワイヤが付属しています。チュートリアルについては、Control.Wireリンクしたページのモジュールのドキュメントにアクセスしてください。

グラフィカルユーザーインターフェイスの場合、現在のところ最良の選択はリアクティブバナナです。すでにwxインターフェース（別のライブラリreactive-banana-wxとして）があり、Heinrichは、コードサンプルを含むこのコンテキストでのFRPについて多くのブログを書いています。

他の質問に答えるには：FRPは、リアルタイムの予測可能性が必要なシナリオには適していません。これは主にHaskellによるものですが、残念ながらFRPを低水準言語で実現することは困難です。Haskell自体がリアルタイム対応になるとすぐに、FRPもそこに到達します。概念的には、Netwireはリアルタイムアプリケーションに対応しています。

時間のリークは、主にモナディックフレームワークに関連しているため、もはや実際には問題ではありません。実用的なFRPの実装では、単調なインターフェースは提供されません。Yampaはこれを開始し、Netwireとreactive-bananaはどちらもその上に構築されています。

私は現在、FRPを使用している商業的またはその他の大規模なプロジェクトを知りません。図書館は準備ができていますが、人々はまだ準備ができていないと思います。

于 2012-11-12T13:08:33.067 に答える
23

すでにいくつかの良い答えがありますが、私はあなたの特定の質問に答えようとします。

  1. リアクティブは、タイムリークの問題があるため、深刻なプロジェクトには使用できません。（＃3を参照）。最も類似したデザインの現在のライブラリは、リアクティブバナナです。これは、リアクティブをインスピレーションとして開発され、コナルエリオットと話し合っています。

  2. Haskell自体はハードリアルタイムアプリケーションには不適切ですが、場合によってはソフトリアルタイムアプリケーションにHaskellを使用することが可能です。私は現在の研究に精通していませんが、これが克服できない問題であるとは思いません。Yampaのようなシステム、またはAtomのようなコード生成システムのいずれかが、これを解決するための最良のアプローチである可能性があります。

  3. 「タイムリーク」は、切り替え可能なFRPに固有の問題です。リークは、システムが古いオブジェクトを解放できない場合に発生します。これは、将来のある時点で切り替えが発生した場合に、古いオブジェクトが必要になる可能性があるためです。メモリリーク（非常に深刻な場合があります）に加えて、別の結果として、切り替えが発生すると、システムは古いオブジェクトのチェーンをトラバースして現在の状態を生成している間、一時停止する必要があります。

Yampaや古いバージョンのreactive-bananaなどの切り替え不可能なfrpライブラリは、時間のリークに悩まされることはありません。切り替え可能なfrpライブラリは、通常、FRP値が作成される特別な「作成モナド」を備えているか、「エージング」タイプのパラメータを使用して切り替えが発生する可能性のあるコンテキストを制限する2つのスキームのいずれかを採用しています。 elerea（そしておそらくnetwire？）は前者を使用しますが、最近のリアクティブバナナとグレープフルーツは後者を使用します。

「切り替え可能なfrp」とは、Conalの機能switcher :: Behavior a -> Event (Behavior a) -> Behavior aまたは同一のセマンティクスを実装するものを意味します。これは、ネットワークの形状が実行時に動的に切り替わる可能性があることを意味します。

これは、モナドインターフェイスに関する@ertesのステートメントと実際には矛盾しません。Monadインスタンスを提供するEventと時間リークが発生する可能性があり、上記のいずれのアプローチでも、同等のモナドインスタンスを定義することはできなくなります。

最後に、FRPで行うべき作業はまだたくさんありますが、新しいプラットフォームのいくつか（reactive-banana、elerea、netwire）は安定していて、信頼できるコードを構築できるほど成熟していると思います。しかし、良いパフォーマンスを得る方法を理解するために、インとアウトを学ぶのに多くの時間を費やす必要があるかもしれません。

于 2012-11-12T15:12:24.830 に答える
20

Monoと.Netスペースにいくつかのアイテムをリストし、少し前に見つけたHaskellスペースから1つをリストします。Haskellから始めましょう。

Elm-リンク

そのサイトによるその説明：

Elmは、フロントエンドWeb開発をより快適にすることを目指しています。HTML、CSS、およびJavaScriptの体系的な問題を修正するGUIプログラミングへの新しいアプローチを紹介します。Elmを使用すると、視覚的なレイアウトをすばやく簡単に操作し、キャンバスを使用し、複雑なユーザー入力を管理し、コールバックの地獄から脱出することができます。

FRPの独自のバリアントがあります。その例で遊んでみると、かなり成熟しているようです。

リアクティブエクステンション-リンク

フロントページからの説明：

Reactive Extensions（Rx）は、監視可能なシーケンスとLINQスタイルのクエリ演算子を使用して非同期およびイベントベースのプログラムを作成するためのライブラリです。開発者は、Rxを使用して、Observablesで非同期データストリームを表現し、LINQ演算子を使用して非同期データストリームをクエリし、スケジューラーを使用して非同期データストリームの同時実行性をパラメーター化します。簡単に言えば、Rx = Observables + LINQ+Schedulersです。

Reactive ExtensionsはMSFTに由来し、イベントの処理を簡素化する多くの優れた演算子を実装しています。ほんの数日前にオープンソースでした。それは非常に成熟しており、生産に使用されています。私の意見では、TPLライブラリが提供するよりもWindows8APIの方が優れたAPIでした。オブザーバブルはホットとコールドの両方、再試行/マージなどが可能であるのに対し、タスクは常に、実行中、障害、または完了したホットまたは完了した計算を表します。

非同期性のためにRxを使用してサーバー側のコードを記述しましたが、C＃で機能的に記述するのは少し面倒な場合があることを認めなければなりません。F＃にはいくつかのラッパーがありますが、グループは比較的閉鎖的であり、他のプロジェクトのようにMSFTによってプロモートされていないため、API開発を追跡することは困難です。

そのオープンソーシングは、IL-to-JSコンパイラのオープンソーシングに付属しているため、JavaScriptまたはElmでうまく機能する可能性があります。

RabbitMQやSocksJSなどのメッセージブローカーを使用して、F＃/ C＃/ JS/Haskellを非常にうまくバインドできます。

BlingUIToolkit-リンク

フロントページからの説明：

Blingは、MicrosoftのWPF / .NETで画像、アニメーション、インタラクション、および視覚化を簡単にプログラミングするためのC＃ベースのライブラリです。Blingは、豊富なUIデザインのアイデアのラピッドプロトタイピングを支援するために、デザインテクノロジスト、つまり、プログラミングを行うことがあるデザイナーを対象としています。学生、芸術家、研究者、愛好家も、アイデアや視覚化をすばやく表現するためのツールとしてBlingが役立つことに気付くでしょう。BlingのAPIと構造は、本番コードの注意深いプログラミングとは対照的に、使い捨てコードの高速プログラミング用に最適化されています。

無料のLtU-記事。

私はこれをテストしましたが、クライアントプロジェクトでは使用しませんでした。見た目は素晴らしく、値間のバインディングを形成するC＃演算子のオーバーロードが優れています。WPF / SL /（WinRT）の依存関係プロパティをイベントソースとして使用します。その3Dアニメーションは、妥当なハードウェアでうまく機能します。視覚化が必要なプロジェクトにたどり着いた場合は、これを使用します。おそらくそれをWindows8に移植します。

ReactiveUI-リンク

以前はMSFTにいて、現在はGithubにいるPaul Bettsが、そのフレームワークを作成しました。私はそれをかなり広範囲に使用し、モデルが好きです。Blinkよりも分離されています（Rxとその抽象化を使用することからの性質により）-それを使用してテストコードを単体テストするのが簡単になります。Windows用のgithubgitクライアントはこれで書かれています。

コメントコメント

リアクティブモデルは、パフォーマンスが要求されるほとんどのアプリケーションに十分なパフォーマンスを発揮します。あなたがハードリアルタイムを考えているなら、私はほとんどのGC言語に問題があると賭けます。Rx、ReactiveUIは、GCが必要な少量の小さなオブジェクトを作成します。これは、サブスクリプションが作成/破棄され、コールバックのリアクティブな「モナド」で中間値が進行するためです。一般に、.Netでは、コールバックは静的（コンパイル時に既知、割り当てなし）であり、タスクは動的に割り当てられる（不明、すべての呼び出しにはインスタンスが必要、ガベージが作成される）ため、タスクベースのプログラミングよりもリアクティブプログラミングを好みます-ラムダはコンパイルされますコンパイラによって生成されたクラス。

明らかに、C＃とF＃は厳密に評価されているため、ここではタイムリークは問題になりません。JSについても同じです。ただし、再生可能またはキャッシュされたオブザーバブルでは問題になる可能性があります。

于 2012-11-12T13:26:31.527 に答える