当前函数式响应式编程实现的状态如何? [英] What's the status of current Functional Reactive Programming implementations?

问题描述

我试图在 Haskell 中可视化一些简单的自动物理系统(例如钟摆、机械臂等).通常这些系统可以用像

I'm trying to visualize some simple automatic physical systems (such things as pendulum, robot arms,etc.) in Haskell. Often those systems can be described by equations like

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

其中 u(t) 代表某种智能控制".这些系统看起来非常适合函数式响应式编程范式.

where u(t) represents some kind of 'intelligent control'. Those systems look to fit very nicely in the Functional Reactive Programming paradigm.

所以我拿起了 Paul Hudak 的书The Haskell School of Expression"，并发现那里提供的领域特定语言FAL"(用于功能动画语言)实际上非常适合我的简单玩具系统(尽管某些功能，特别是 integrate，似乎有点太懒了一种有效的使用方式，但很容易修复).

So I grabbed the book "The Haskell School of Expression" by Paul Hudak, and found that the domain specific language "FAL" (for Functional Animation Language) presented there actually works quite pleasently for my simple toy systems (although some functions, notably integrate, seemed to be a bit too lazy for an efficient use, but easily fixable).

我的问题是，对于当今更先进甚至更实际的应用程序，有哪些更成熟、最新、维护良好、性能调整的替代方案?

My question is, what's the more mature, up-to-date, well-maintained, performance-tuned alternative for more advanced, or even practical applications today?

这个维基页面列出了 Haskell 的几个选项，但我不清楚以下几个方面:

This wiki page lists several options for Haskell, but I'm not clear about the following respects:

1. 反应式"的状态，Conal Eliott 的项目(据我所知)是这种编程范式的发明者之一，看起来有点陈旧.我喜欢他的代码，但也许我应该尝试其他更新的替代方案?在语法/性能/运行时稳定性方面，它们之间的主要区别是什么?

1. The status of "reactive", the project from Conal Eliott who is (as I understand it) one of the inventers of this programming paradigm, looks a bit stale. I love his code, but maybe I should try other more up-to-date alternatives? What's the primary difference between them, in terms of syntax/performance/runtime-stability?

引自 2011 年的调查，第6，... FRP 实现在性能方面仍然不够高效或可预测，无法在需要延迟保证的域中有效使用...".尽管调查提出了一些有趣的可能优化方案，但鉴于 FRP 已存在超过 15 年，我的印象是，这个性能问题可能是非常甚至本质上难以解决的问题，至少在一些年.这是真的吗?

To quote from a survey in 2011, Section 6, "... FRP implementations are still not efficient enough or predictable enough in performance to be used effectively in domains which require latency guarantees ...". Alghough the survey suggests some interesting possible optimizations, given the fact that FRP is there for more than 15 years, I get the impression that this performance problem might be something very or even inherently difficult to solve at least within a few years. Is this true?

调查的同一作者在他的 博客.这个问题是 FRP 独有的，还是我们在用纯的、非严格的语言编程时通常会遇到的问题?您是否曾经发现，如果性能不够，那么随着时间的推移要稳定基于 FRP 的系统太困难了?

The same author of the survey talks about "time leaks" in his blog. Is the problem unique to FRP, or something we are generally having when programming in a pure, non-strict language? Have you ever found it just too difficult to stabilize an FRP-based system over time, if not performant enough?

这还是研究级项目吗?工厂工程师、机器人工程师、金融工程师等人是否真的在使用它们(以适合他们需求的任何语言)?

Is this still a research level project? Are the people like plant engineers, robotics engineers, financial engineers, etc. actually using them (in whaterver language that suits their needs)?

虽然我个人更喜欢 Haskell 实现，但我愿意接受其他建议.例如，拥有一个 Erlang 实现会特别有趣——那么拥有一个智能的、自适应的、自学习的服务器进程将非常容易！

Although I personally prefer a Haskell implementation, I'm open to other suggestions. For example, it would be particularly fun to have an Erlang implementation --- it would then be very easy to have an intelligent, adaptive, self-learning server process!

推荐答案

现在主要有两个实用的 Haskell 库用于函数式响应式编程.两者都由一个人维护，但也接受其他 Haskell 程序员的代码贡献:

Right now there are mainly two practical Haskell libraries out there for functional reactive programming. Both are maintained by single persons, but are receiving code contributions from other Haskell programmers as well:

• Netwire 专注于效率、灵活性和可预测性.它有自己的事件范式，可用于传统 FRP 不适用的领域，包括网络服务和复杂的模拟.风格:适用和/或箭头化.最初的作者和维护者:Ertugrul Söylemez(这就是我).

• Netwire focusses on efficiency, flexibility and predictability. It has its own event paradigm and can be used in areas where traditional FRP does not work, including network services and complex simulations. Style: applicative and/or arrowized. Initial author and maintainer: Ertugrul Söylemez (this is me).

reactive-banana 建立在传统的 FRP 范式之上.虽然使用起来很实用，但它也可以作为经典 FRP 研究的基础.它的主要重点是用户界面，并且有一个现成的 wx 界面.风格:适用.最初的作者和维护者:Heinrich Apfelmus.

reactive-banana builds on the traditional FRP paradigm. While it is practical to use it also serves as ground for classic FRP research. Its main focus is on user interfaces and there is a ready-made interface to wx. Style: applicative. Initial author and maintainer: Heinrich Apfelmus.

您应该同时尝试这两种方法，但根据您的应用，您可能会发现其中一种更适合.

You should try both of them, but depending on your application you will likely find one or the other to be a better fit.

对于游戏、网络、机器人控制和模拟，您会发现 Netwire 很有用.它为这些应用程序提供了现成的线，包括各种有用的微分、积分和许多用于透明事件处理的功能.如需教程，请访问我链接的页面上 Control.Wire 模块的文档.

For games, networking, robot control and simulations you will find Netwire to be useful. It comes with ready-made wires for those applications, including various useful differentials, integrals and lots of functionality for transparent event handling. For a tutorial visit the documentation of the Control.Wire module on the page I linked.

对于图形用户界面，目前你最好的选择是 react-banana.它已经有一个 wx 接口(作为一个单独的库 react-banana-wx)并且 Heinrich 在这方面写了很多关于 FRP 的博客，包括代码示例.

For graphical user interfaces currently your best choice is reactive-banana. It already has a wx interface (as a separate library reactive-banana-wx) and Heinrich blogs a lot about FRP in this context including code samples.

回答您的其他问题:FRP 不适合需要实时可预测性的场景.这主要归功于 Haskell，但不幸的是 FRP 很难在较低级别的语言中实现.一旦 Haskell 本身成为实时就绪，FRP 也将到达那里.从概念上讲，Netwire 已准备好用于实时应用程序.

To answer your other questions: FRP isn't suitable in scenarios where you need real-time predictability. This is largely due to Haskell, but unfortunately FRP is difficult to realize in lower level languages. As soon as Haskell itself becomes real-time-ready, FRP will get there, too. Conceptually Netwire is ready for real-time applications.

时间泄漏不再是真正的问题，因为它们主要与 monadic 框架有关.实际的 FRP 实现根本不提供 monadic 接口.Yampa 已经开始了这个，Netwire 和reactive-banana 都以此为基础.

Time leaks aren't really a problem anymore, because they are largely related to the monadic framework. Practical FRP implementations simply don't offer a monadic interface. Yampa has started this and Netwire and reactive-banana both build on that.

我知道目前没有使用 FRP 的商业或其他大型项目.图书馆已经准备好了，但我认为人们还没有准备好.

I know of no commercial or otherwise large scale projects using FRP right now. The libraries are ready, but I think the people aren't – yet.

这篇关于当前函数式响应式编程实现的状态如何?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！