首页
学习
活动
专区
工具
TVP
发布
社区首页 >问答首页 >当前函数式反应式编程实现的现状如何?

当前函数式反应式编程实现的现状如何?
EN

Stack Overflow用户
提问于 2012-11-12 18:21:09
回答 3查看 14.8K关注 0票数 90

我正在尝试可视化一些简单的自动物理系统(如钟摆、机械臂等)。在哈斯克尔。通常,这些系统可以用如下等式来描述

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

其中u(t)表示某种“智能控制”。这些系统看起来非常适合函数式反应式编程范例。

所以我拿起Paul Hudak的"The Haskell School of Expression“这本书,发现书中介绍的领域特定语言"FAL”(即函数动画语言)实际上对我的简单玩具系统非常有效(虽然有些函数,特别是integrate,看起来有点懒惰,不能有效地使用,但很容易修复)。

我的问题是,对于今天更高级甚至更实际的应用程序来说,更成熟、更新、维护更好、性能更好的替代方案是什么?

This wiki page列出了Haskell的几个选项,但我不清楚以下几个方面:

  1. "reactive“的状态,来自Conal Eliott的项目,他(据我所知)是这种编程范式的发明者之一,看起来有点过时。我喜欢他的代码,但也许我应该尝试其他更新的替代方案?它们之间的主要区别是什么,就2011年survey第6节中的syntax/performance/runtime-stability?
  2. To引述而言,"... FRP实现在性能上仍然不够高效或足够可预测,无法在需要延迟保证的域中有效使用...“。尽管调查提出了一些有趣的可能的优化,但考虑到FRP存在了超过15年的事实,我得到的印象是,这个性能问题可能是非常甚至本质上很难解决的,至少在几年内是这样。这是真的吗?调查的同一作者
  3. 在他的blog中谈到了“时间泄漏”。这个问题是FRP独有的,还是我们在纯非严格语言编程时通常会遇到的问题?你是否曾经发现,随着时间的推移,稳定基于玻璃钢的系统太难了,如果性能不够好的话?
  4. 这仍然是一个研究级别的项目吗?工厂工程师、机器人工程师、金融工程师等人是否真的在使用它们(使用适合其需求的语言)?

尽管我个人更喜欢Haskell实现,但我对其他建议持开放态度。例如,如果有一个Erlang实现会特别有趣-这样就很容易有一个智能的、自适应的、自学习的服务器进程!

EN

回答 3

Stack Overflow用户

回答已采纳

发布于 2012-11-12 21:08:33

目前,主要有两个实用的Haskell库用于函数式反应式编程。两者都是由个人维护的,但也从其他Haskell程序员那里获得了代码贡献:

  • Netwire专注于效率、灵活性和可预测性。它有自己的事件范例,可用于传统FRP不起作用的领域,包括网络服务和复杂的模拟。风格:应用型和/或箭头型。最初的作者和维护者: Ertugrul Söylemez (这是me).
  • reactive-banana建立在传统的玻璃钢范例上。虽然使用它是实用的,但它也是经典FRP研究的基础。它的主要关注点是用户界面,并且有一个现成的wx界面。风格:应用型。最初的作者和维护者: Heinrich Apfelmus。

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

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

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

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

时间泄漏不再是一个真正的问题,因为它们在很大程度上与一元框架有关。实用的FRP实现根本不提供一元接口。Yampa已经开始这样做了,Netwire和reactive-banana都是建立在这个基础上的。

据我所知,目前还没有使用玻璃钢的商业或其他大型项目。图书馆已经准备好了,但我认为人们还没有。

票数 82
EN

Stack Overflow用户

发布于 2012-11-12 23:12:25

虽然已经有了一些很好的答案,但我将尝试回答您的特定问题。

由于时间泄漏问题,

  1. reactive不适用于严重的项目。(参见#3)。当前设计最相似的库是reactive-banana,它是以reactive为灵感开发的,在与Conal Elliott.
  2. Although Haskell讨论时,它本身不适合硬实时应用程序,在某些情况下,可以将Haskell用于软实时应用程序。我不熟悉目前的研究,但我不认为这是一个不可逾越的问题。我怀疑要么像Yampa这样的系统,要么像Atom这样的代码生成系统,可能是解决这个问题的最好方法。
  3. “时间泄漏”是一个特定于可切换FRP的问题。当系统无法释放旧对象时,就会发生泄漏,因为如果在未来某个时候发生切换,系统可能需要旧对象。除了内存泄漏(这可能非常严重)之外,另一个后果是,当切换发生时,系统必须在遍历旧对象链以生成当前状态时暂停。

不可切换的frp库,如Yampa和reactive-banana的旧版本,不会受到时间泄漏的影响。可切换frp库通常采用以下两种方案之一:它们具有创建FRP值的特殊“创建单元体”,或者它们使用“老化”类型参数来限制可以发生切换的上下文。elerea (可能还有netwire?)使用前者,而最近的反应式香蕉和西葫芦使用后者。

所谓“可切换的玻璃钢”,我的意思是一个实现了锥形的功能switcher :: Behavior a -> Event (Behavior a) -> Behavior a,或相同的语义。这意味着网络的形状可以在运行时动态切换。

这实际上与@ertes关于一元接口的声明并不矛盾:事实证明,为Event提供一个Monad实例使得时间泄漏成为可能,并且使用上述任何一种方法,都不再可能定义等效的Monad实例。

最后,尽管FRP还有很多工作要做,但我认为一些较新的平台(reactive-banana,elerea,netwire)已经足够稳定和成熟,你可以用它们来构建可靠的代码。但是,您可能需要花费大量时间来学习细节,以便了解如何获得良好的性能。

票数 23
EN

Stack Overflow用户

发布于 2012-11-12 21:26:32

我将列出Mono和.Net空间中的几个项目,以及不久前在Haskell空间中发现的一个项目。我将从Haskell开始。

Elm - link

根据其网站的描述:

Elm旨在让前端web开发变得更加愉快。它引入了一种新的图形用户界面编程方法,纠正了HTML、CSS和JavaScript的系统性问题。Elm允许您快速轻松地使用可视化布局,使用画布,管理复杂的用户输入,并从回调地狱中逃脱。

它有自己的FRP变体。从它的例子来看,它似乎相当成熟。

反应式扩展- link

首页的描述:

Reactive Extensions (Rx)是一个库,用于使用可观察的序列和

风格的查询操作符组成异步和基于事件的程序。使用Rx,开发人员使用可观察对象表示异步数据流,使用LINQ运算符查询异步数据流,并使用调度器对异步数据流中的并发性进行参数化。简单地说,Rx =可观察值+ LINQ +调度器。

反应式扩展来自MSFT,并实现了许多优秀的运算符,简化了事件处理。就在几天前,它是open sourced。它非常成熟,并在生产中使用;在我看来,对于Windows8API来说,它将是一个比TPL库提供的更好的API;因为观察值可以是热的和冷的,以及重试/合并等,而任务总是表示正在运行的、出错的或完成的热计算或已完成的计算。

我已经使用Rx编写了用于异步的服务器端代码,但我必须承认,用C#编写函数可能有点烦人。F#有几个包装器,但是很难跟踪API的开发,因为这个组是相对封闭的,并且不像其他项目那样由微软进行推广。

它的开源来自于它的IL-to-JS编译器的开源,所以它可能可以很好地与JavaScript或Elm一起工作。

您可以使用消息代理将F#/C#/JS/Haskell很好地绑定在一起,比如RabbitMQ和SocksJS。

闪亮的UI工具包- link

首页的描述:

WPF是一个基于C#的库,用于在微软的

/.NET上轻松地编程图像、动画、交互和可视化。Bling面向设计技术人员,即有时编程的设计师,以帮助快速构建丰富的UI设计思想的原型。学生、艺术家、研究人员和业余爱好者也会发现Bling作为一种快速表达想法或可视化的工具很有用。Bling的API和构造针对快速编程丢弃代码进行了优化,而不是仔细地编程生产代码。

免费的LtU-article

我对此进行了测试,但没有在客户项目中使用它。它看起来很棒,有很好的C#操作符重载来形成值之间的绑定。它使用WPF/SL/(WinRT)中的依赖属性作为事件源。它的3D动画在合理的硬件上工作得很好。如果我在一个需要可视化的项目上结束,我会使用它;可能会将它移植到Windows 8。

ReactiveUI - link

Paul Betts之前在MSFT工作,现在在Github工作,他编写了这个框架。我用它做了相当广泛的工作,我喜欢这个模型。它比Blink更容易解耦(本质上是使用Rx和它的抽象)--使得使用它对代码进行单元测试变得更容易。Windows的github git客户端就是这样编写的。

评论

反应式模型的性能足以满足大多数对性能要求很高的应用程序的要求。如果你考虑的是硬实时,我敢打赌大多数GC语言都有问题。Rx、ReactiveUI创建了一些需要GCed的小对象,因为订阅是这样创建/处理的,中间值是在被动的回调“单体”中进行处理的。一般来说,在.Net上我更喜欢反应式编程,而不是基于任务的编程,因为回调是静态的(在编译时已知,没有分配),而任务是动态分配的(不知道,所有调用都需要一个实例,垃圾创建)-而lambda会编译成编译器生成的类。

显然,C#和F#是严格计算的,所以时间泄漏在这里不是问题。JS也是如此。不过,对于可重放或缓存的可观察对象来说,这可能是一个问题。

票数 20
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/13341937

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档