来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
（一）
一、引言
说到函数式编程，大家可能第一印象都是学院派的那些晦涩难懂的代码，充满了一大堆抽象的不知所云的符号，似乎只有大学里的计算机教授才会使用这些东西。在曾经的某个时代可能确实如此，但是近年来随着技术的发展，函数式编程已经在实际生产中发挥巨大的作用了，越来越多的语言开始加入闭包，匿名函数等非常典型的函数式编程的特性，从某种程度上来讲，函数式编程正在逐步“同化”命令式编程。
JavaScript 作为一种典型的多范式编程语言，这两年随着React的火热，函数式编程的概念也开始流行起来，RxJS、cycleJS、lodashJS、underscoreJS等多种开源库都使用了函数式的特性。所以下面介绍一些函数式编程的知识和概念。
二、纯函数
如果你还记得一些初中的数学知识的话，函数 f 的概念就是，对于输入 x 产生一个输出 y = f(x)。这便是一种最简单的纯函数。纯函数的定义是，对于相同的输入，永远会得到相同的输出，而且没有任何可观察的副作用，也不依赖外部环境的状态。
下面来举个栗子，比如在Javascript中对于数组的操作，有些是纯的，有些就不是纯的：
var arr = [1,2,3,4,5];
// Array.slice是纯函数，因为它没有副作用，对于固定的输入，输出总是固定的
// 可以，这很函数式
xs.slice(0,3);
//=> [1,2,3]
xs.slice(0,3);
//=> [1,2,3]
// Array.splice是不纯的，它有副作用，对于固定的输入，输出不是固定的
// 这不函数式
xs.splice(0,3);
//=> [1,2,3]
xs.splice(0,3);
//=> [4,5]
xs.splice(0,3);
//=> []
在函数式编程中，我们想要的是 slice 这样的纯函数，而不是 splice这种每次调用后都会把数据弄得一团乱的函数。
为什么函数式编程会排斥不纯的函数呢？下面再看一个例子：
//不纯的
var min = 18;
var checkage = age => age > min;
//纯的，这很函数式
var checkage = age => age > 18;
在不纯的版本中，checkage 这个函数的行为不仅取决于输入的参数 age，还取决于一个外部的变量 min，换句话说，这个函数的行为需要由外部的系统环境决定。对于大型系统来说，这种对于外部状态的依赖是造成系统复杂性大大提高的主要原因。
可以注意到，纯的 checkage 把关键数字 18 硬编码在函数内部，扩展性比较差，我们可以在后面的柯里化中看到如何用优雅的函数式解决这种问题。
纯函数不仅可以有效降低系统的复杂度，还有很多很棒的特性，比如可缓存性：
import _ from 'lodash';
var sin = _.memorize(x => Math.sin(x));
//第一次计算的时候会稍慢一点
var a = sin(1);
//第二次有了缓存，速度极快
var b = sin(1);
三、函数的柯里化
函数柯里化（curry）的定义很简单：传递给函数一部分参数来调用它，让它返回一个函数去处理剩下的参数。
比如对于加法函数 var add = (x, y) => x + y ，我们可以这样进行柯里化：
//比较容易读懂的ES5写法
var add = function(x){
return function(y){
return x + y
}
}
//ES6写法，也是比较正统的函数式写法
var add = x => (y => x + y);
//试试看
var add2 = add(2);
var add200 = add(200);
add2(2); // =>4
add200(50); // =>250
对于加法这种极其简单的函数来说，柯里化并没有什么大用处。
还记得上面那个 checkage 的函数吗？我们可以这样柯里化它：
var checkage = min => (age => age > min);
var checkage18 = checkage(18);
checkage18(20);
// =>true
事实上柯里化是一种“预加载”函数的方法，通过传递较少的参数，得到一个已经记住了这些参数的新函数，某种意义上讲，这是一种对参数的“缓存”，是一种非常高效的编写函数的方法：
import { curry } from 'lodash';
//首先柯里化两个纯函数
var match = curry((reg, str) => str.match(reg));
var filter = curry((f, arr) => arr.filter(f));
//判断字符串里有没有空格
var haveSpace = match(/\s+/g);
haveSpace("ffffffff");
//=>null
haveSpace("a b");
//=>[" "]
filter(haveSpace, ["abcdefg", "Hello World"]);
//=>["Hello world"]
四、函数组合
学会了使用纯函数以及如何把它柯里化之后，我们会很容易写出这样的“包菜式”代码：
h(g(f(x)));
虽然这也是函数式的代码，但它依然存在某种意义上的“不优雅”。为了解决函数嵌套的问题，我们需要用到“函数组合”：
//两个函数的组合
var compose = function(f, g) {
return function(x) {
return f(g(x));
};
};
//或者
var compose = (f, g) => (x => f(g(x)));
var add1 = x => x + 1;
var mul5 = x => x * 5;
compose(mul5, add1)(2);
// =>15
我们定义的compose就像双面胶一样，可以把任何两个纯函数结合到一起。当然你也可以扩展出组合三个函数的“三面胶”，甚至“四面胶”“N面胶”。
这种灵活的组合可以让我们像拼积木一样来组合函数式的代码：
var first = arr => arr[0];
var reverse = arr => arr.reverse();
var last = compose(first, reverse);
last([1,2,3,4,5]);
// =>5
五、Point Free
有了柯里化和函数组合的基础知识，下面介绍一下Point Free这种代码风格。
细心的话你可能会注意到，之前的代码中我们总是喜欢把一些对象自带的方法转化成纯函数：
var map = (f, arr) => arr.map(f);
var toUpperCase = word => word.toUpperCase();
这种做法是有原因的。
Point Free这种模式现在还暂且没有中文的翻译，有兴趣的话可以看看这里的英文解释：
https://en.wikipedia.org/wiki/Tacit_programming
用中文解释的话大概就是，不要命名转瞬即逝的中间变量，比如：
//这不Piont free
var f = str => str.toUpperCase().split(' ');
这个函数中，我们使用了 str 作为我们的中间变量，但这个中间变量除了让代码变得长了一点以外是毫无意义的。下面改造一下这段代码：
var toUpperCase = word => word.toUpperCase();
var split = x => (str => str.split(x));
var f = compose(split(' '), toUpperCase);
f("abcd efgh");
// =>["ABCD", "EFGH"]
这种风格能够帮助我们减少不必要的命名，让代码保持简洁和通用。当然，为了在一些函数中写出Point Free的风格，在代码的其它地方必然是不那么Point Free的，这个地方需要自己取舍。
六、声明式与命令式代码
命令式代码的意思就是，我们通过编写一条又一条指令去让计算机执行一些动作，这其中一般都会涉及到很多繁杂的细节。
而声明式就要优雅很多了，我们通过写表达式的方式来声明我们想干什么，而不是通过一步一步的指示。
//命令式
var CEOs = [];
for(var i = 0; i < companies.length; i++){
CEOs.push(companies[i].CEO)
}
//声明式
var CEOs = companies.map(c => c.CEO);
命令式的写法要先实例化一个数组，然后再对 companies 数组进行for循环遍历，手动命名、判断、增加计数器，就好像你开了一辆零件全部暴露在外的汽车一样，虽然很机械朋克风，但这并不是优雅的程序员应该做的。
声明式的写法是一个表达式，如何进行计数器迭代，返回的数组如何收集，这些细节都隐藏了起来。它指明的是做什么，而不是怎么做。除了更加清晰和简洁之外，map 函数还可以进一步独立优化，甚至用解释器内置的速度极快的 map 函数，这么一来我们主要的业务代码就无须改动了。
函数式编程的一个明显的好处就是这种声明式的代码，对于无副作用的纯函数，我们完全可以不考虑函数内部是如何实现的，专注于编写业务代码。优化代码时，目光只需要集中在这些稳定坚固的函数内部即可。
相反，不纯的不函数式的代码会产生副作用或者依赖外部系统环境，使用它们的时候总是要考虑这些不干净的副作用。在复杂的系统中，这对于程序员的心智来说是极大的负担。
七、尾声
任何代码都是要有实际用处才有意义，对于JS来说也是如此。然而现实的编程世界显然不如范例中的函数式世界那么美好，实际应用中的JS是要接触到ajax、DOM操作，NodeJS环境中读写文件、网络操作这些对于外部环境强依赖，有明显副作用的“很脏”的工作。
这对于函数式编程来说也是很大的挑战，所以我们也需要更强大的技术去解决这些“脏问题”。我会在下一篇文章中介绍函数式编程的更加高阶一些的知识，例如Functor、Monad等等概念。
八、参考
1、https://github.com/MostlyAdequate/mostly-adequate-guide
2、http://www.ibm.com/developerworks/cn/web/1006_qiujt_jsfunctional/
3、《JavaScript函数式编程》【美】迈克尔·佛格斯
（二）
拖延症了好久，第二篇终于写出来了。
上一篇文章里我们提到了纯函数的概念，所谓的纯函数就是，对于相同的输入，永远会得到相同的输出，而且没有任何可观察的副作用，也不依赖外部环境的状态（我偷懒复制过来的）。
但是实际的编程中，特别是前端的编程范畴里，“不依赖外部环境”这个条件是根本不可能的，我们总是不可避免地接触到 DOM、AJAX 这些状态随时都在变化的东西。所以我们需要用更强大的技术来干这些脏活。
一、容器、Functor
如果你熟悉 jQuery 的话，应该还记得，$(...) 返回的对象并不是一个原生的 DOM 对象，而是对于原生对象的一种封装：
var foo = $('#foo');
foo == document.getElementById('foo');
//=> false
foo[0] == document.getElementById('foo');
//=> true
这在某种意义上就是一个“容器”（但它并不函数式）。
接下类我们会看到，容器为函数式编程里普通的变量、对象、函数提供了一层极其强大的外衣，赋予了它们一些很惊艳的特性，就好像 Tony Stark 的钢铁外衣，Dva 的机甲，明日香的2号机一样。
下面我们就来写一个最简单的容器吧：
var Container = function(x) {
this.__value = x;
}
Container.of = x => new Container(x);
//试试看
Container.of(1);
//=> Container(1)
Container.of('abcd');
//=> Container('abcd')
我们调用 Container.of 把东西装进容器里之后，由于这一层外壳的阻挡，普通的函数就对他们不再起作用了，所以我们需要加一个接口来让外部的函数也能作用到容器里面的值：
Container.prototype.map = function(f){
return Container.of(f(this.__value))
}
我们可以这样使用它：
Container.of(3)
.map(x => x + 1) //=> Container(4)
.map(x => 'Result is ' + x); //=> Container('Result is 4')
没错！我们仅花了 7 行代码就实现了很炫的『链式调用』，这也是我们的第一个 Functor。
Functor（函子）是实现了 map 并遵守一些特定规则的容器类型。
也就是说，如果我们要将普通函数应用到一个被容器包裹的值，那么我们首先需要定义一个叫 Functor 的数据类型，在这个数据类型中需要定义如何使用 map 来应用这个普通函数。
把东西装进一个容器，只留出一个接口 map 给容器外的函数，这么做有什么好处呢？
本质上，Functor 是一个对于函数调用的抽象，我们赋予容器自己去调用函数的能力。当 map 一个函数时，我们让容器自己来运行这个函数，这样容器就可以自由地选择何时何地如何操作这个函数，以致于拥有惰性求值、错误处理、异步调用等等非常牛掰的特性。
举个例子，我们现在为 map 函数添加一个检查空值的特性，这个新的容器我们称之为 Maybe（原型来自于Haskell）：
var Maybe = function(x) {
this.__value = x;
}
Maybe.of = function(x) {
return new Maybe(x);
}
Maybe.prototype.map = function(f) {
return this.isNothing() ? Maybe.of(null) : Maybe.of(f(this.__value));
}
Maybe.prototype.isNothing = function() {
return (this.__value === null || this.__value === undefined);
}
//试试看
import _ from 'lodash';
var add = _.curry(_.add);
Maybe.of({name: "Stark"})
.map(_.prop("age"))
.map(add(10));
//=> Maybe(null)
Maybe.of({name: "Stark", age: 21})
.map(_.prop("age"))
.map(add(10));
//=> Maybe(31)
看了这些代码，觉得链式调用总是要输入一堆 .map(...) 很烦对吧？这个问题很好解决，还记得我们上一篇文章里介绍的柯里化吗？
有了柯里化这个强大的工具，我们可以这样写：
import _ from 'lodash';
var compose = _.flowRight;
var add = _.curry(_.add);
// 创造一个柯里化的 map
var map = _.curry((f, functor) => functor.map(f));
var doEverything = map(compose(add(10), _.property("age")));
var functor = Maybe.of({name: "Stark", age: 21});
doEverything(functor);
//=> Maybe(31)
二、错误处理、Either
现在我们的容器能做的事情太少了，它甚至连做简单的错误处理都做不到，现在我们只能类似这样处理错误：
try{
doSomething();
}catch(e){
// 错误处理
}
try/catch/throw 并不是“纯”的，因为它从外部接管了我们的函数，并且在这个函数出错时抛弃了它的返回值。这不是我们期望的函数式的行为。
如果你对 Promise 熟悉的话应该还记得，Promise 是可以调用 catch 来集中处理错误的：
doSomething()
.then(async1)
.then(async2)
.catch(e => console.log(e));
对于函数式编程我们也可以做同样的操作，如果运行正确，那么就返回正确的结果；如果错误，就返回一个用于描述错误的结果。这个概念在 Haskell 中称之为 Either 类，Left 和 Right 是它的两个子类。我们用 JS 来实现一下：
// 这里是一样的=。=
var Left = function(x) {
this.__value = x;
}
var Right = function(x) {
this.__value = x;
}
// 这里也是一样的=。=
Left.of = function(x) {
return new Left(x);
}
Right.of = function(x) {
return new Right(x);
}
// 这里不同！！！
Left.prototype.map = function(f) {
return this;
}
Right.prototype.map = function(f) {
return Right.of(f(this.__value));
}
下面来看看 Left 和 Right 的区别吧：
Right.of("Hello").map(str => str + " World!");
// Right("Hello World!")
Left.of("Hello").map(str => str + " World!");
// Left("Hello")
Left 和 Right 唯一的区别就在于 map 方法的实现，Right.map 的行为和我们之前提到的 map 函数一样。但是 Left.map 就很不同了：它不会对容器做任何事情，只是很简单地把这个容器拿进来又扔出去。这个特性意味着，Left 可以用来传递一个错误消息。
var getAge = user => user.age ? Right.of(user.age) : Left.of("ERROR!");
//试试
getAge({name: 'stark', age: '21'}).map(age => 'Age is ' + age);
//=> Right('Age is 21')
getAge({name: 'stark'}).map(age => 'Age is ' + age);
//=> Left('ERROR!')
是的，Left 可以让调用链中任意一环的错误立刻返回到调用链的尾部，这给我们错误处理带来了很大的方便，再也不用一层又一层的 try/catch。
Left 和 Right 是 Either 类的两个子类，事实上 Either 并不只是用来做错误处理的，它表示了逻辑或，范畴学里的 coproduct。但这些超出了我们的讨论范围。
三、IO
下面我们的程序要走出象牙塔，去接触外面“肮脏”的世界了，在这个世界里，很多事情都是有副作用的或者依赖于外部环境的，比如下面这样：
function readLocalStorage(){
return window.localStorage;
}
这个函数显然不是纯函数，因为它强依赖外部的 window.localStorage 这个对象，它的返回值会随着环境的变化而变化。为了让它“纯”起来，我们可以把它包裹在一个函数内部，延迟执行它：
function readLocalStorage(){
return function(){
return window.localStorage;
}
}
这样 readLocalStorage 就变成了一个真正的纯函数！ OvO为机智的程序员鼓掌！
额……好吧……好像确实没什么卵用……我们只是（像大多数拖延症晚期患者那样）把讨厌做的事情暂时搁置了而已。为了能彻底解决这些讨厌的事情，我们需要一个叫 IO 的新的 Functor：
import _ from 'lodash';
var compose = _.flowRight;
var IO = function(f) {
this.__value = f;
}
IO.of = x => new IO(_ => x);
IO.prototype.map = function(f) {
return new IO(compose(f, this.__value))
};
IO 跟前面那几个 Functor 不同的地方在于，它的 __value 是一个函数。它把不纯的操作（比如 IO、网络请求、DOM）包裹到一个函数内，从而延迟这个操作的执行。所以我们认为，IO 包含的是被包裹的操作的返回值。
var io_document = new IO(_ => window.document);
io_document.map(function(doc){ return doc.title });
//=> IO(document.title)
注意我们这里虽然感觉上返回了一个实际的值 IO(document.title)，但事实上只是一个对象：{ __value: [Function] }，它并没有执行，而是简单地把我们想要的操作存了起来，只有当我们在真的需要这个值得时候，IO 才会真的开始求值，这个特性我们称之为『惰性求值』。（培提尔其乌斯：“这是怠惰啊！”）
是的，我们依然需要某种方法让 IO 开始求值，并且把它返回给我们。它可能因为 map 的调用链积累了很多很多不纯的操作，一旦开始求值，就可能会把本来很干净的程序给“弄脏”。但是去直接执行这些“脏”操作不同，我们把这些不纯的操作带来的复杂性和不可维护性推到了 IO 的调用者身上（嗯就是这么不负责任）。
下面我们来做稍微复杂点的事情，编写一个函数，从当前 url 中解析出对应的参数。
import _ from 'lodash';
// 先来几个基础函数：
// 字符串
var split = _.curry((char, str) => str.split(char));
// 数组
var first = arr => arr[0];
var last = arr => arr[arr.length - 1];
var filter = _.curry((f, arr) => arr.filter(f));
//注意这里的 x 既可以是数组，也可以是 functor
var map = _.curry((f, x) => x.map(f));
// 判断
var eq = _.curry((x, y) => x == y);
// 结合
var compose = _.flowRight;
var toPairs = compose(map(split('=')), split('&'));
// toPairs('a=1&b=2')
//=> [['a', '1'], ['b', '2']]
var params = compose(toPairs, last, split('?'));
// params('http://xxx.com?a=1&b=2')
//=> [['a', '1'], ['b', '2']]
// 这里会有些难懂=。= 慢慢看
// 1.首先，getParam是一个接受IO(url)，返回一个新的接受 key 的函数；
// 2.我们先对 url 调用 params 函数，得到类似[['a', '1'], ['b', '2']]
// 这样的数组；
// 3.然后调用 filter(compose(eq(key), first))，这是一个过滤器，过滤的
// 条件是 compose(eq(key), first) 为真，它的意思就是只留下首项为 key
// 的数组；
// 4.最后调用 Maybe.of，把它包装起来。
// 5.这一系列的调用是针对 IO 的，所以我们用 map 把这些调用封装起来。
var getParam = url => key => map(compose(Maybe.of, filter(compose(eq(key), first)), params))(url);
// 创建充满了洪荒之力的 IO！！！
var url = new IO(_ => window.location.href);
// 最终的调用函数！！！
var findParam = getParam(url);
// 上面的代码都是很干净的纯函数，下面我们来对它求值，求值的过程是非纯的。
// 假设现在的 url 是 http://xxx.com?a=1&b=2
// 调用 __value() 来运行它！
findParam("a").__value();
//=> Maybe(['a', '1'])
四、总结
如果你还能坚持看到这里的话，不管看没看懂，已经是勇士了。在这篇文章里，我们先后提到了 Maybe、Either、IO 这三种强大的 Functor，在链式调用、惰性求值、错误捕获、输入输出中都发挥着巨大的作用。事实上 Functor 远不止这三种，但由于篇幅的问题就不再继续介绍了（哼才不告诉你其实是因为我还没看懂其它 Functor 的原理）
但依然有问题困扰着我们：
1. 如何处理嵌套的 Functor 呢？（比如 Maybe(IO(42))）
2. 如何处理一个由非纯的或者异步的操作序列呢？
在这个充满了容器和 Functor 的世界里，我们手上的工具还不够多，函数式编程的学习还远远没有结束，在下一篇文章里会讲到 Monad 这个神奇的东西（然而我也不知道啥时候写下一篇，估计等到实习考核后吧OvO）。
五、参考
1、https://github.com/MostlyAdequate/mostly-adequate-guide
2、http://www.ibm.com/developerworks/cn/web/1006_qiujt_jsfunctional/
3、《JavaScript函数式编程》【美】迈克尔·佛格斯
（三）
在第二篇文章里，我们介绍了 Maybe、Either、IO 等几种常见的 Functor，或许很多看完第二篇文章的人都会有疑惑：
『这些东西有什么卵用？』
事实上，如果只是为了学习编写函数式、副作用小的代码的话，看完第一篇文章就足够了。第二篇文章和这里的第三篇着重于的是一些函数式理论的实践，是的，这些很难（但并非不可能）应用到实际的生产中，因为很多轮子都已经造好了并且很好用了。比如现在在前端大规模使用的 Promise 这种异步调用规范，其实就是一种 Monad（等下会讲到）；现在日趋成熟的 Redux 作为一种 FLUX 的变种实现，核心理念也是状态机和函数式编程。
一、Monad
关于 Monad 的介绍和教程在网络上已经层出不穷了，很多文章都写得比我下面的更好，所以我在这里只是用一种更简单易懂的方式介绍 Monad，当然简单易懂带来的坏处就是不严谨，所以见谅/w\
如果你对 Promise 这种规范有了解的话，应该记得 Promise 里一个很惊艳的特性：
doSomething()
.then(result => {
// 你可以return一个Promise链！
return fetch('url').then(result => parseBody(result));
})
.then(result => {
// 这里的result是上面那个Promise的终值
})
doSomething()
.then(result => {
// 也可以直接return一个具体的值！
return 123;
})
.then(result => {
// result === 123
})
对于 Promise 的一个回调函数来说，它既可以直接返回一个值，也可以返回一个新的 Promise，但对于他们后续的回调函数来说，这二者都是等价的，这就很巧妙地解决了 nodejs 里被诟病已久的嵌套地狱。
事实上，Promise 就是一种 Monad，是的，可能你天天要写一大堆 Promise，可直到现在才知道天天用的这个东西竟然是个听起来很高大上的函数式概念。
下面我们来实际实现一个 Monad，如果你不想看的话，只要记住 『Promise 就是一种 Monad』 这句话然后直接跳过这一章就好了。
我们来写一个函数 cat，这个函数的作用和 Linux 命令行下的 cat 一样，读取一个文件，然后打出这个文件的内容，这里 IO 的实现请参考上一篇文章：
import fs from 'fs';
import _ from 'lodash';
var map = _.curry((f, x) => x.map(f));
var compose = _.flowRight;
var readFile = function(filename) {
return new IO(_ => fs.readFileSync(filename, 'utf-8'));
};
var print = function(x) {
return new IO(_ => {
console.log(x);
return x;
});
}
var cat = compose(map(print), readFile);
cat("file")
//=> IO(IO("file的内容"))
由于这里涉及到两个 IO：读取文件和打印，所以最后结果就是我们得到了两层 IO，想要运行它，只能调用：
cat("file").__value().__value();
//=> 读取文件并打印到控制台
很尴尬对吧，如果我们涉及到 100 个 IO 操作，那么难道要连续写 100 个 __value() 吗？
当然不能这样不优雅，我们来实现一个 join 方法，它的作用就是剥开一层 Functor，把里面的东西暴露给我们：
var join = x => x.join();
IO.prototype.join = function() {
return this.__value ? IO.of(null) : this.__value();
}
// 试试看
var foo = IO.of(IO.of('123'));
foo.join();
//=> IO('123')
有了 join 方法之后，就稍微优雅那么一点儿了：
var cat = compose(join, map(print), readFile);
cat("file").__value();
//=> 读取文件并打印到控制台
join 方法可以把 Functor 拍平（flatten），我们一般把具有这种能力的 Functor 称之为 Monad。
这里只是非常简单地移除了一层 Functor 的包装，但作为优雅的程序员，我们不可能总是在 map 之后手动调用 join 来剥离多余的包装，否则代码会长得像这样：
var doSomething = compose(join, map(f), join, map(g), join, map(h));
所以我们需要一个叫 chain 的方法来实现我们期望的链式调用，它会在调用 map 之后自动调用 join 来去除多余的包装，这也是 Monad 的一大特性：
var chain = _.curry((f, functor) => functor.chain(f));
IO.prototype.chain = function(f) {
return this.map(f).join();
}
// 现在可以这样调用了
var doSomething = compose(chain(f), chain(g), chain(h));
// 当然，也可以这样
someMonad.chain(f).chain(g).chain(h)
// 写成这样是不是很熟悉呢？
readFile('file')
.chain(x => new IO(_ => {
console.log(x);
return x;
}))
.chain(x => new IO(_ => {
// 对x做一些事情，然后返回
}))
哈哈，你可能看出来了，chain 不就类似 Promise 中的 then 吗？是的，它们行为上确实是一致的（then 会稍微多一些逻辑，它会记录嵌套的层数以及区别 Promise 和普通返回值），Promise 也确实是一种函数式的思想。
（我本来想在下面用 Promise 为例写一些例子，但估计能看到这里的人应该都能熟练地写各种 Promise 链了，所以就不写了0w0）
总之就是，Monad 让我们避开了嵌套地狱，可以轻松地进行深度嵌套的函数式编程，比如IO和其它异步任务。
二、函数式编程的应用
好了，关于函数式编程的一些基础理论的介绍就到此为止了，如果想了解更多的话其实建议去学习 Haskell 或者 Lisp 这样比较正统的函数式语言。下面我们来回答一个问题：函数式编程在实际应用中到底有啥用咧？
1、React
React 现在已经随处可见了，要问它为什么流行，可能有人会说它『性能好』、『酷炫』、『第三方组件丰富』、『新颖』等等，但这些都不是最关键的，最关键是 React 给前端开发带来了全新的理念：函数式和状态机。
我们来看看 React 怎么写一个『纯组件』吧：
var Text = props => (
<div style={props.style}>{props.text}</div>
)
咦这不就是纯函数吗？对于任意的 text 输入，都会产生唯一的固定输出，只不过这个输出是一个 virtual DOM 的元素罢了。配合状态机，就大大简化了前端开发的复杂度：
state => virtual DOM => 真实 DOM
在 Redux 中更是可以把核心逻辑抽象成一个纯函数 reducer：
reducer(currentState, action) => newState
关于 React+Redux（或者其它FLUX架构）就不在这里介绍太多了，有兴趣的可以参考相关的教程。
2、Rxjs
Rxjs 从诞生以来一直都不温不火，但它函数响应式编程（Functional Reactive Programming，FRP）的理念非常先进，虽然或许对于大部分应用环境来说，外部输入事件并不是太频繁，并不需要引入一个如此庞大的 FRP 体系，但我们也可以了解一下它有哪些优秀的特性。
在 Rxjs 中，所有的外部输入（用户输入、网络请求等等）都被视作一种 『事件流』：
--- 用户点击了按钮 --> 网络请求成功 --> 用户键盘输入 --> 某个定时事件发生 --> ......
举个最简单的例子，下面这段代码会监听点击事件，每 2 次点击事件产生一次事件响应：
var clicks = Rx.Observable
.fromEvent(document, 'click')
.bufferCount(2)
.subscribe(x => console.log(x)); // 打印出前2次点击事件
其中 bufferCount 对于事件流的作用是这样的：
是不是很神奇呢？Rxjs 非常适合游戏、编辑器这种外部输入极多的应用，比如有的游戏可能有『搓大招』这个功能，即监听用户一系列连续的键盘、鼠标输入，比如上上下下左右左右BABA，不用事件流的思想的话，实现会非常困难且不优雅，但用 Rxjs 的话，就只是维护一个定长队列的问题而已：
var inputs = [];
var clicks = Rx.Observable
.fromEvent(document, 'keydown')
.scan((acc, cur) => {
acc.push(cur.keyCode);
var start = acc.length - 12 < 0 ? 0 : acc.length - 12;
return acc.slice(start);
}, inputs)
.filter(x => x.join(',') == [38, 38, 40, 40, 37, 39, 37, 39, 66, 65, 66, 65].join(','))// 上上下下左右左右BABA，这里用了比较奇技淫巧的数组对比方法
.subscribe(x => console.log('!!!!!!ACE!!!!!!'));
当然，Rxjs 的作用远不止于此，但可以从这个范例里看出函数响应式编程的一些优良的特性。
3、Cycle.js
Cycle.js 是一个基于 Rxjs 的框架，它是一个彻彻底底的 FRP 理念的框架，和 React 一样支持 virtual DOM、JSX 语法，但现在似乎还没有看到大型的应用经验。
本质的讲，它就是在 Rxjs 的基础上加入了对 virtual DOM、容器和组件的支持，比如下面就是一个简单的『开关』按钮：
import xs from 'xstream';
import {run} from '@cycle/xstream-run';
import {makeDOMDriver} from '@cycle/dom';
import {html} from 'snabbdom-jsx';
function main(sources) {
const sinks = {
DOM: sources.DOM.select('input').events('click')
.map(ev => ev.target.checked)
.startWith(false)
.map(toggled =>
<div>
<input type="checkbox" /> Toggle me
<p>{toggled ? 'ON' : 'off'}</p>
</div>
)
};
return sinks;
}
const drivers = {
DOM: makeDOMDriver('#app')
};
run(main, drivers);
当然，Cycle.js 这种『侵入式』的框架适用性不是太广，因为使用它就意味着应用中必须全部或者大部分都要围绕它的理念设计，这对于大规模应用来说反而是负担。
三、总结
既然是完结篇，那我们来总结一下这三篇文章究竟讲了些啥？
第一篇文章里，介绍了纯函数、柯里化、Point Free、声明式代码和命令式代码的区别，你可能忘记得差不多了，但只要记住『函数对于外部状态的依赖是造成系统复杂性大大提高的主要原因』以及『让函数尽可能地纯净』就行了。
第二篇文章，或许是最没有也或许是最有干货的一篇，里面介绍了『容器』的概念和 Maybe、Either、IO 这三个强大的 Functor。是的，大多数人或许都没有机会在生产环境中自己去实现这样的玩具级 Functor，但通过了解它们的特性会让你产生对于函数式编程的意识。
软件工程上讲『没有银弹』，函数式编程同样也不是万能的，它与烂大街的 OOP 一样，只是一种编程范式而已。很多实际应用中是很难用函数式去表达的，选择 OOP 亦或是其它编程范式或许会更简单。但我们要注意到函数式编程的核心理念，如果说 OOP 降低复杂度是靠良好的封装、继承、多态以及接口定义的话，那么函数式编程就是通过纯函数以及它们的组合、柯里化、Functor 等技术来降低系统复杂度，而 React、Rxjs、Cycle.js 正是这种理念的代言人，这可能是大势所趋，也或许是昙花一现，但不妨碍我们去多掌握一种编程范式嘛0w0
