在阅读了许多页关于FRP的文章后，我终于看到了这篇关于FRP的启发性文章，它最终让我明白了FRP的真正含义。

下面我引用海因里希·阿费尔马斯(活性香蕉的作者)的话。

What is the essence of functional reactive programming? A common answer would be that “FRP is all about describing a system in terms of time-varying functions instead of mutable state”, and that would certainly not be wrong. This is the semantic viewpoint. But in my opinion, the deeper, more satisfying answer is given by the following purely syntactic criterion: The essence of functional reactive programming is to specify the dynamic behavior of a value completely at the time of declaration. For instance, take the example of a counter: you have two buttons labelled “Up” and “Down” which can be used to increment or decrement the counter. Imperatively, you would first specify an initial value and then change it whenever a button is pressed; something like this: counter := 0 -- initial value on buttonUp = (counter := counter + 1) -- change it later on buttonDown = (counter := counter - 1) The point is that at the time of declaration, only the initial value for the counter is specified; the dynamic behavior of counter is implicit in the rest of the program text. In contrast, functional reactive programming specifies the whole dynamic behavior at the time of declaration, like this: counter :: Behavior Int counter = accumulate ($) 0 (fmap (+1) eventUp `union` fmap (subtract 1) eventDown) Whenever you want to understand the dynamics of counter, you only have to look at its definition. Everything that can happen to it will appear on the right-hand side. This is very much in contrast to the imperative approach where subsequent declarations can change the dynamic behavior of previously declared values.

所以，在我的理解中，FRP程序是一组方程:

J是离散的:1,2,3,4…

F依赖于t所以这包含了外部刺激模型的可能性

程序的所有状态都封装在变量x_i中

FRP库考虑了进度时间，换句话说，从j到j+1。

我会在这个视频中更详细地解释这些方程。

编辑:

在最初的回答大约2年后，最近我得出结论，FRP实现还有另一个重要的方面。它们需要(通常也会)解决一个重要的实际问题:缓存失效。

x_i-s的方程描述了一个依赖关系图。当x_i在j时刻发生变化时，并不需要更新j+1时刻的所有其他x_i'值，因此并不需要重新计算所有依赖项，因为有些x_i'可能与x_i无关。

而且，改变的x_i-s可以被增量更新。例如，让我们考虑Scala中的映射操作f=g.map(_+1)，其中f和g是int类型的列表。这里f对应于x_i(t_j) g是x_j(t_j)现在，如果我将一个元素前置到g中，那么对g中的所有元素执行映射操作将是浪费的。一些FRP实现(例如reflect - FRP)旨在解决这个问题。这个问题也称为增量计算。

换句话说，FRP中的行为(x_i-s)可以被认为是缓存的计算。如果某些f_i-s确实发生了变化，FRP引擎的任务就是有效地使这些缓存(x_i-s)失效并重新计算。

在阅读了许多页关于FRP的文章后，我终于看到了这篇关于FRP的启发性文章，它最终让我明白了FRP的真正含义。

下面我引用海因里希·阿费尔马斯(活性香蕉的作者)的话。

What is the essence of functional reactive programming? A common answer would be that “FRP is all about describing a system in terms of time-varying functions instead of mutable state”, and that would certainly not be wrong. This is the semantic viewpoint. But in my opinion, the deeper, more satisfying answer is given by the following purely syntactic criterion: The essence of functional reactive programming is to specify the dynamic behavior of a value completely at the time of declaration. For instance, take the example of a counter: you have two buttons labelled “Up” and “Down” which can be used to increment or decrement the counter. Imperatively, you would first specify an initial value and then change it whenever a button is pressed; something like this: counter := 0 -- initial value on buttonUp = (counter := counter + 1) -- change it later on buttonDown = (counter := counter - 1) The point is that at the time of declaration, only the initial value for the counter is specified; the dynamic behavior of counter is implicit in the rest of the program text. In contrast, functional reactive programming specifies the whole dynamic behavior at the time of declaration, like this: counter :: Behavior Int counter = accumulate ($) 0 (fmap (+1) eventUp `union` fmap (subtract 1) eventDown) Whenever you want to understand the dynamics of counter, you only have to look at its definition. Everything that can happen to it will appear on the right-hand side. This is very much in contrast to the imperative approach where subsequent declarations can change the dynamic behavior of previously declared values.

所以，在我的理解中，FRP程序是一组方程:

J是离散的:1,2,3,4…

F依赖于t所以这包含了外部刺激模型的可能性

程序的所有状态都封装在变量x_i中

FRP库考虑了进度时间，换句话说，从j到j+1。

我会在这个视频中更详细地解释这些方程。

编辑:

在最初的回答大约2年后，最近我得出结论，FRP实现还有另一个重要的方面。它们需要(通常也会)解决一个重要的实际问题:缓存失效。

x_i-s的方程描述了一个依赖关系图。当x_i在j时刻发生变化时，并不需要更新j+1时刻的所有其他x_i'值，因此并不需要重新计算所有依赖项，因为有些x_i'可能与x_i无关。

而且，改变的x_i-s可以被增量更新。例如，让我们考虑Scala中的映射操作f=g.map(_+1)，其中f和g是int类型的列表。这里f对应于x_i(t_j) g是x_j(t_j)现在，如果我将一个元素前置到g中，那么对g中的所有元素执行映射操作将是浪费的。一些FRP实现(例如reflect - FRP)旨在解决这个问题。这个问题也称为增量计算。

换句话说，FRP中的行为(x_i-s)可以被认为是缓存的计算。如果某些f_i-s确实发生了变化，FRP引擎的任务就是有效地使这些缓存(x_i-s)失效并重新计算。

有一种简单的方法可以直观地了解它是什么样子的，那就是把你的程序想象成一个电子表格，所有的变量都是单元格。如果电子表格中的任何单元格发生变化，则引用该单元格的任何单元格也会发生变化。玻璃钢也是一样。现在想象一下，一些单元格会自己改变(或者更确切地说，是从外部世界中获取的):在GUI情况下，鼠标的位置就是一个很好的例子。

这必然会错过很多东西。当你实际使用FRP系统时，这个比喻很快就被打破了。首先，通常也会尝试建模离散事件(例如鼠标被点击)。我把这个放在这里只是为了让你们了解它是什么样的。

在纯函数式编程中，没有副作用。对于许多类型的软件(例如，任何与用户交互的软件)，在某种程度上副作用都是必要的。

在保持函数式风格的同时获得类似副作用的行为的一种方法是使用函数式响应式编程。这是函数式编程和响应式编程的结合。(你链接到的维基百科文章是关于后者的。)

响应式编程背后的基本思想是，有特定的数据类型表示“随时间”的值。涉及这些随时间变化的值的计算本身也具有随时间变化的值。

例如，您可以将鼠标坐标表示为一对随时间变化的整数值。假设我们有这样的东西(这是伪代码):

x = <mouse-x>;
y = <mouse-y>;

在任何时刻，x和y都是鼠标的坐标。与非响应式编程不同，我们只需要进行一次赋值，x和y变量将自动保持“最新”。这就是响应式编程和函数式编程协同工作的原因:响应式编程消除了对变量突变的需要，同时仍然允许您完成许多可以通过变量突变完成的工作。

如果我们在此基础上进行一些计算，得到的值也将是随时间变化的值。例如:

minX = x - 16;
minY = y - 16;
maxX = x + 16;
maxY = y + 16;

在这个例子中，minX总是比鼠标指针的x坐标小16。使用响应式感知库，你可以这样说:

rectangle(minX, minY, maxX, maxY)

一个32x32的方框将围绕鼠标指针绘制，并跟踪它的移动位置。

这是一篇关于函数式响应式编程的很好的论文。

好的，从背景知识和阅读你所指向的维基百科页面来看，响应式编程似乎有点像数据流计算，但有特定的外部“刺激”触发一组节点来触发并执行它们的计算。

这非常适合UI设计，例如，触摸用户界面控件(例如，音乐播放应用程序上的音量控制)可能需要更新各种显示项和音频输出的实际音量。当您修改体积(比如一个滑块)时，这将对应于修改有向图中与节点相关的值。

具有“体积值”节点边缘的各种节点将自动被触发，任何必要的计算和更新将自然地贯穿整个应用程序。应用程序对用户刺激“做出反应”。函数式响应式编程只是在函数式语言中实现这一思想，或者通常在函数式编程范式中实现。

有关“数据流计算”的更多信息，请在维基百科或使用您喜欢的搜索引擎上搜索这两个词。总体思想是这样的:程序是一个节点的有向图，每个节点执行一些简单的计算。这些节点通过图链接相互连接，图链接将一些节点的输出提供给其他节点的输入。

当节点触发或执行其计算时，连接到其输出的节点将“触发”或“标记”相应的输入。任何触发/标记/可用所有输入的节点都会自动触发。图可以是隐式的，也可以是显式的，具体取决于响应式编程是如何实现的。

Nodes can be looked at as firing in parallel, but often they are executed serially or with limited parallelism (for example, there may be a few threads executing them). A famous example was the Manchester Dataflow Machine, which (IIRC) used a tagged data architecture to schedule execution of nodes in the graph through one or more execution units. Dataflow computing is fairly well suited to situations in which triggering computations asynchronously giving rise to cascades of computations works better than trying to have execution be governed by a clock (or clocks).

响应式编程引入了这种“执行级联”的思想，似乎以一种类似数据流的方式来考虑程序，但有一个附带条件，即一些节点与“外部世界”挂钩，当这些类似感知的节点发生变化时，执行级联就会被触发。程序的执行看起来就像一个复杂的反射弧。程序在两个刺激之间可能是基本固定的，也可能不是，也可能在两个刺激之间稳定在基本固定的状态。

"non-reactive" programming would be programming with a very different view of the flow of execution and relationship to external inputs. It's likely to be somewhat subjective, since people will likely be tempted to say anything that responds to external inputs "reacts" to them. But looking at the spirit of the thing, a program that polls an event queue at a fixed interval and dispatches any events found to functions (or threads) is less reactive (because it only attends to user input at a fixed interval). Again, it's the spirit of the thing here: one can imagine putting a polling implementation with a fast polling interval into a system at a very low level and program in a reactive fashion on top of it.

免责声明:我的答案是在rx.js的上下文中给出的——一个用于Javascript的“响应式编程”库。

在函数式编程中，不是遍历集合的每个项，而是对集合本身应用高阶函数(hof)。因此，FRP背后的思想是，与其处理每个单独的事件，不如创建一个事件流(使用可观察对象*实现)，并对其应用HoFs。通过这种方式，您可以将系统可视化为连接发布者和订阅者的数据管道。

The major advantages of using an observable are: i) it abstracts away state from your code, e.g., if you want the event handler to get fired only for every 'n'th event, or stop firing after the first 'n' events, or start firing only after the first 'n' events, you can just use the HoFs (filter, takeUntil, skip respectively) instead of setting, updating and checking counters. ii) it improves code locality - if you have 5 different event handlers changing the state of a component, you can merge their observables and define a single event handler on the merged observable instead, effectively combining 5 event handlers into 1. This makes it very easy to reason about what events in your entire system can affect a component, since it's all present in a single handler.

可观察对象是可迭代对象的对偶。

Iterable是一个惰性消费序列——迭代器在需要使用每个项时都会拉出它，因此枚举是由消费者驱动的。

可观察对象是一个惰性生成的序列——每一项在被添加到序列时都被推送给观察者，因此枚举是由生产者驱动的。