原文：Why I cannot say FRP but I just did
一个有用的缩写词与过度维护的爸爸妈妈的故事。
函数呼应式编程（Functional Reactive Programming，FRP）是一个越来越流行的缩写词。呼应式编程和函数式编程都是真实有用的术语，它们传达的思维没有正式谨慎的界说。可是，FRP 是一个极点严厉的术语，它是 20 年前从数学上界说的编程技能。
人们松散地运用 FRP 来指代函数式编程与呼应式编程相结合的技能。可是，他们都错了。这种挑剔的术语伤害了开发者社区，带来了紊乱和对这 3 个字母发音的惊骇。我现已多次看到这种紊乱的状况，我以为将 FRP 约束在它最初的严厉语义上并不能协助咱们沟通编程思维。
我信任 FRP 应该是一个传达理念的术语，就像函数式编程和反应式编程那样。
函数式（Functional）
函数式编程是一种将核算表明为对数学表达式求值的范式。在这种范式中，咱们避免了有副作用的函数和易变的数据。我所想到的大多数编程言语都供给了一种编写纯数学函数的办法，例如，square(x) 函数。在某种程度上，函数式范式能够应用于任何言语，通过运用纯函数和避免（用约好或类型体系）可变数据和副作用。
Haskell 是函数式编程的极致表现，但它不是函数式技能的仅有载体。Clojure（和其他根据 LISP 的言语）、OCaml、F# 是几个值得一提的函数式编程言语。
函数式技能无处不在，把 “函数式编程” 这个术语只是局限于 Haskell 是不公平的。这是一个即便没有严厉的数学也能了解和应用的主意。
反应式（Reactive）
虽然 “反应式编程” 并没有一个广为人知的精确界说，但它作为一个指代可监听信号、数据流和电子表格式核算的术语仍然很有用（现已超越 20 年了！）。
反应式编程在 1989 年的一篇论文中初次被提及的。它是用文字模糊地界说的，而不是数学上的严厉界说：
改换式程序从一组给定的输入中核算结果；[…] 交互式程序以自己的速度与用户或其他程序交互 […]。反应式程序也与环境坚持持续的互动，但其速度由环境决议，而不是由程序自身决议。[…] 实时程序通常是反应式的。
从那时起，就有了反应式编程的其他界说 [1] [2] [3]，但它们往往与能够观察到的事情流或能够对其他事情流做出反应的主意相关。
FRP 是一个被制止的术语
鉴于上述反应式和函数式的意义，把 “函数呼应式编程” 作为一种范式或思维来议论是有意义的，在这种范式或思维中，你运用可监听的事情流（或“信号”）来构建应用程序，运用纯函数来创建和组合它们。可是，这并不是 FRP 在从太阳起的第三块石头上初次被说出时的具体而精确的意义。
“原始 FRP” 是指运用行为和事情的指称和时刻连续性函数式编程。
原始 FRP 的另一个术语是表明性、时刻连续性编程（DCTP）。任何偏离 FRP 先驱 Conal Elliot 界说的一毫米的东西都是术语上的罪行。
Conal Elliott 在 Twitter 上
我指的是精确/严厉的规范，而不是挥手示意。这是我对几乎一切现代的所谓“FRP”体系的不满之一。
Conal Elliott on Twitter
我对大多数所谓的“FRP”体系的另一个首要不满是抛弃了最初的准则，即时刻连续性。
Conal Elliott on Twitter
我想知道人们是如何把 Rx、RAC 及同类产品视为 #FRP 的，以及这些主意/信仰是如何传播的。
Conal Elliott on Twitter
@mattpodwysocki @raimohanska @ph1 和 Bacon 等人并没有完成 FRP 的主意，它有一个精确的（impl-independent）表明。
Conal Elliott on Twitter
@tacticalgrace 大多数现代“FRP”体系也忽略了精确的指称，留下了不知道是什么的语义鼠窝而未被发现。
Conal Elliott on Twitter
@crstry 纵情享受! 尽量不要被“FRP”标签的现代、涣散/模糊的运用所诈骗。我很乐意答复问题。
Conal Elliott on Twitter
@andrestaltz 这是关于FRP的基本准则（指称性和连续性）。Rx、Bacon 和 Elm 缺少这两点。@mattpodwysocki @slashdotpeter
如果不遵循指示性和时刻连续性的要求，Conal 就会尽力避免对 FRP 的提及，这很无情。这背面的原因是什么？
人们猜测框架的 “FRP 分类” 将是一个有意义的分类，其饼状图大致如此。
人们期望 FRP 的分类是怎样的，是一个饼状图
上述状况彻底不是实践的状况。原始的 FRP 在 Haskell 社区中是一个小众（ Haskell 自身便是一个小众言语）。真实的饼状图看起来更像这样。
对 FRP 框架的分类更精确的认知
Conal 在 StackOverflow 上的答复链接到一个 Haskell 页面，列出了一些库。你会猜想至少这些库一定是真实的 FRP。这是不正确的。Sodium 是该列表中的第一个库，可是这个论坛的评论表明，Sodium 缺少真实的 FRP 所需要的精确指称。任何洒在上面的指称都意味着一种错误的办法，由于真实的 FRP 是指称优先的。
这使得 FRP 这个词对大多数程序员来说基本上是无用的，由于它只与一个小众范畴有关。
咱们有什么挑选呢？
鉴于 “函数式” 和 “呼应式” 经常一同用来描绘一个解决方案或库，我开始运用 “F&RP”（它也可能是 “RFP” 或 “R&FP”）。
Andr Staltz on Twitter
2015年2月5日：我在此正式树立一个新的缩写。F&RP：函数和呼应式编程。(!=FRP)
当我认识到 FRP 是一个传达理念的术语，而不是一种规范时，我并不孤单。
Tenor Biel on Twitter
@conal 无意冒犯，但你应该把你对 FRP 的意义和更常见的意义分开：事情发射器是可折叠的应用程序（Event emitters are Foldable Applicatives）。
Yaron Minsky on Twitter
@conal 为什么离散版 “不是FRP”？分类应该在世界的关节处进行切割，它们似乎更相似而不是不同。
Manuel Chakravarty on Twitter
@conal 恕我直言，您挑选了一个适当笼统的术语，所以通用的解释很常见，我并不感到惊奇。
Ben Christensen on Twitter
@daverstevens @tlockney 是的，这便是我在了解前史之前就开始运用 FRP 的原因……反应式风格 + 函数式风格 == FRP ……但没有。
Juha Paananen on Twitter
@mattpodwysocki @ph1 我以为 FRP 是一种思维办法。框架只是完成主意的办法。会持续得罪人的。很抱歉 :)
Elm 的创造者 Evan Czaplicki 在 Strangeloop 做了一个很好的讲演，对 “FRP” 的不同口味进行了分类，虽然依照保守派的说法这是一个悖论。
英语不是一个严厉的类型体系
英国言语的开展和持续演化。咱们运用词语来表达意思，但咱们也会出于多种原因对词语和它们的意义进行延伸和变异。这个进程是人类可读的，也是不可避免的。
作为人类，咱们想要议论主意，而名字是表达这些主意的好办法。正如 Evan 的上述讲演所示，有多种工具（Fran, Yampa, Elm, Reactive Banana, Reactive Extensions, Bacon.js, ReactiveCocoa, Sodium）都有一个一起的主意：功用可控的信号。通过给一个一起的主意命名，咱们使沟通变得更容易。
咱们应该给这个一起的主意起什么名字呢？RFP？F&RP？R&FP？这些都没有 FRP 那么广泛，对很多人来说，FRP 现已传达了可听和功用可控的事情流的概念。
咱们要做什么？
讽刺的是，我实践上会采纳 Conal Elliott 的建议，他在 StackOverflow 的答复中说了一句：
为了减少紊乱，我希望看到 “函数呼应式编程” 一词被更精确和描绘性的“指称性，时刻连续性编程”（DCTP）”所替代。
原来的 FRP 变成了 DCTP，FRP 能够模糊地用于函数化的信号。
厌烦的人要厌烦，我宣告 Reactive Extensions 便是 FRP。
