我最近发现了FP bug(试图学习Haskell),到目前为止我已经看到了(一流的功能,懒惰的评估和所有其他好东西).我还不是专家,但是我已经开始发现在功能上比在基本算法上强制推理更容易(而且我很难回到我必须去的地方).
然而,当前FP看起来平坦的一个领域是GUI编程.Haskell方法似乎只是包装命令式GUI工具包(例如GTK +或wxWidgets)并使用"do"块来模拟命令式样式.我没有使用过F#,但我的理解是它使用OOP和.NET类做了类似的事情.显然,有一个很好的理由 - 当前的GUI编程完全是关于IO和副作用的,所以对于大多数当前的框架来说,纯函数式编程是不可能的.
我的问题是,是否可以使用GUI编程的功能方法？我无法想象在实践中这会是什么样子.有没有人知道任何尝试此类事物的框架(实验或其他)(或者甚至是为功能语言设计的任何框架)？或者只是使用混合方法的解决方案,其中OOP用于GUI部件,FP用于逻辑？(我只是想出于好奇心 - 我很想认为FP是"未来",但GUI编程似乎是一个非常大的漏洞.)
我正在尝试在Haskell中可视化一些简单的自动物理系统(例如摆锤,机器人手臂等).通常这些系统可以用类似的方程来描述
df/dt = c*f(t) + u(t)
其中,u(t)代表了某种"智能控制"的.这些系统看起来非常适合功能反应式编程范例.
因此,我通过保罗·哈达克抓起书"表达的哈斯克尔学校",并发现,领域特定语言"FAL"(功能动画语言)提出有实际工作相当pleasently我简单的玩具系统(虽然某些功能,尤其是integrate,似乎有点懒得有效使用,但很容易修复).
我的问题是,对于今天更先进甚至实际的应用,更成熟,最新,维护良好,性能优化的替代方案是什么？
这个wiki页面列出了Haskell的几个选项,但我不清楚以下几个方面:
"反应"的状态,来自Conal Eliott的项目(据我所知)是这种编程范式的发明者之一,看起来有点陈旧.我喜欢他的代码,但也许我应该尝试其他更新的替代品？在语法/性能/运行时稳定性方面,它们之间的主要区别是什么？
引用2011年的一项调查,第6节," ...... FRP实施仍然没有足够的效率或足够可预测的性能,无法在需要延迟保证的领域中有效使用...... ".Alghough调查提出了一些有趣的可能的优化,鉴于FRP是有超过15年,我得到的印象是,这个性能问题可能会是一件非常,甚至本来就很难在几年内至少解决.这是真的？
该调查的同一位作者在他的博客中谈到了"时间泄漏" .问题是FRP独有的,还是我们在用纯粹的非严格语言编程时通常会遇到的问题？您是否曾经发现,如果性能不够,那么随着时间的推移稳定基于FRP的系统就太难了？
这还是一个研究水平的项目吗？人们喜欢工厂工程师,机器人工程师,金融工程师等实际使用它们(用适合他们需要的各种语言)吗？
虽然我个人更喜欢Haskell实现,但我愿意接受其他建议.例如,拥有一个Erlang实现会特别有趣 - 那么拥有一个智能的,自适应的,自学的服务器进程就很容易了!
触发火灾动作是否安全
(addHandler, fire) <- newAddHandler
从一个不同的线程,编译反应香蕉图？