傻瓜函数式编程
傻瓜函数式编程
说明
2006年6月19日，星期一
开篇
我们这些码农做事都是很拖拉的。每天例行报到后，先来点咖啡，看看邮件还有RSS订阅的文章。然后翻翻新闻还有那些技术网站上的更新，再过一遍编程论坛口水区里那些无聊的论战。最后从头把这些再看一次以免错过什么精彩的内容。然后就可以吃午饭了。饭饱过后，回来盯着IDE发一会呆，再看看邮箱，再去搞杯咖啡。光阴似箭，可以回家了……
（在被众人鄙视之前）我唯一想说的是，在这些拖拉的日子里总会时不时读到一些不明觉厉的文章。如果没有打开不应该打开的网站，每隔几天你都可以看到至少一篇这样的东西。它们的共性：难懂，耗时，于是这些文章就慢慢的堆积成山了。很快你就会发现自己已经累积了一堆的收藏链接还有数不清的PDF文件，此时你只希望隐入一个杳无人烟的深山老林里什么也不做，用一年半载好好的消化这些私藏宝贝。当然，我是说最好每天还是能有人来给送吃的顺带帮忙打扫卫生倒垃圾，哇哈哈。
我不知道你都收藏了些什么，我的阅读清单里面相当大部分都是函数式编程相关的东东：基本上是最难啃的。这些文章充斥着无比枯燥的教科书语言，我想就连那些在华尔街浸淫10年以上的大牛都无法搞懂这些函数式编程（简称FP）文章到底在说什么。你可以去花旗集团或者德意志银行找个项目经理来问问1：你们为什么要选JMS而不用Erlang？答案基本上是：我认为这个学术用的语言还无法胜任实际应用。可是，现有的一些系统不仅非常复杂还需要满足十分严苛的需求，它们就都是用函数式编程的方法来实现的。这，就说不过去了。
关于FP的文章确实比较难懂，但我不认为一定要搞得那么晦涩。有一些历史原因造成了这种知识断层，可是FP概念本身并不难理解。我希望这篇文章可以成为一个“FP入门指南”，帮助你从指令式编程走向函数式编程。先来点咖啡，然后继续读下去。很快你对FP的理解就会让同事们刮目相看了。
什么是函数式编程（Functional Programming，FP）？它从何而来？可以吃吗？倘若它真的像那些鼓吹FP的人说的那么好，为什么实际应用中那么少见？为什么只有那些在读博士的家伙想要用它？而最重要的是，它母亲的怎么就那么难学？那些所谓的closure、continuation，currying，lazy evaluation还有no side effects都是什么东东（译者：本着保留专用术语的原则，此处及下文类似情形均不译）？如果没有那些大学教授的帮忙怎样把它应用到实际工程里去？为什么它和我们熟悉的万能而神圣的指令式编程那么的不一样？
我们很快就会解开这些谜团。刚才我说过实际工程和学术界之间的知识断层是有其历史原因的，那么就先让我来解释一下这个问题。答案，就在接下来的一次公园漫步中：
###公园漫步
时间机器启动……我们来到公元前380年，也就是2000多年前的雅典城外。这是一个阳光明媚的久违的春天，柏拉图和一个帅气的小男仆走在一片橄榄树荫下。他们正准备前往一个学院。天气很好，吃得很饱，渐渐的，两人的谈话转向了哲学。
“你看那两个学生，哪一个更高一些？”，柏拉图小心的选择用字，以便让这个问题更好的引导眼前的这个小男孩。
小男仆望向水池旁边的两个男生，“他们差不多一样高。”。
“‘差不多一样高’是什么意思？”柏拉图问。
“嗯……从这里看来他们是一样高的，但是如果走近一点我肯定能看出差别来。”
柏拉图笑了。他知道这个小孩已经朝他引导的方向走了。“这么说来你的意思是世界上没有什么东西是完全相同的咯？”
思考了一会，小男孩回答：“是的。万物之间都至少有一丁点差别，哪怕我们无法分辨出来。”
说到点子上了！“那你说，如果世界上没有什么东西是完全相等的，你怎么理解‘完全相等’这个概念？”
小男仆看起来很困惑。“这我就不知道了。”
这是人类第一次试图了解数学的本质。柏拉图认为我们所在的世界中，万事万物都是完美模型的一个近似。他同时意识到虽然我们不能感受到完美的模型，但这丝毫不会阻止我们了解完美模型的概念。柏拉图进而得出结论：完美的数学模型只存在于另外一个世界，而因为某种原因我们却可以通过联系着这两个世界的一个纽带来认识这些模型。一个简单的例子就是完美的圆形。没有人见过这样的一个圆，但是我们知道怎样的圆是完美的圆，而且可以用公式把它描述出来。
如此说来，什么是数学呢？为什么可以用数学法则来描述我们的这个宇宙？我们所处的这个世界中万事万物都可以用数学来描述吗？2 数理哲学是一门很复杂的学科。它和其他多数哲学一样，更着重于提出问题而不是给出答案。数学就像拼图一样，很多结论都是这样推导出来的：先是确立一些互不冲突的基础原理，以及一些操作这些原理的规则，然后就可以把这些原理以及规则拼凑起来形成新的更加复杂的规则或是定理了。数学家把这种方法称为“形式系统”或是“演算”。如果你想做的话，可以用形式系统描述俄罗斯方块这个游戏。而事实上，俄罗斯方块这个游戏的实现，只要它正确运行，就是一个形式系统。只不过它以一种不常见的形式表现出来罢了。
如果半人马阿尔法上有文明存在的话，那里的生物可能无法解读我们的俄罗斯方块形式系统甚至是简单的圆形的形式系统，因为它们感知世界的唯一器官可能只有鼻子（译者：偶的妈你咋知道？）也许它们是无法得知俄罗斯方块的形式系统了，但是它们很有可能知道圆形。它们的圆形我们可能没法解读，因为我们的鼻子没有它们那么灵敏（译者：那狗可以么？）可是只要越过形式系统的表示方式（比如通过使用“超级鼻子”之类的工具来感知这些用味道表示的形式系统，然后使用标准的解码技术把它们翻译成人类能理解的语言），那么任何有足够智力的文明都可以理解这些形式系统的本质。
有意思的是，哪怕宇宙中完全不存在任何文明，类似俄罗斯方块还有圆形这样的形式系统依旧是成立的：只不过没有智慧生物去发现它们而已。这个时候如果忽然一个文明诞生了，那么这些具有智慧的生物就很有可能发现各种各样的形式系统，并且用它们发现的系统去描述各种宇宙法则。不过它们可能不会发现俄罗斯方块这样的形式系统，因为在它们的世界里没有俄罗斯方块这种东西嘛。有很多像俄罗斯方块这样的形式系统是与客观世界无关的，比如说自然数，很难说所有的自然数都与客观世界有关，随便举一个超级大的数，这个数可能就和世界上任何事物无关，因为这个世界可能不是无穷大的。
历史回眸
再次启动时间机……这次到达的是20世纪30年代，离今天近了很多。无论新旧大陆，经济大萧条都造成了巨大的破坏。社会各阶层几乎每一个家庭都深受其害。只有极其少数的几个地方能让人们免于遭受穷困之苦。几乎没有人能够幸运的在这些避难所里度过危机，注意，我说的是几乎没有，还真的有这么些幸运儿，比如说当时普林斯顿大学的数学家们。
新建成的哥特式办公楼给普林斯顿大学带来一种天堂般的安全感。来自世界各地的逻辑学者应邀来到普林斯顿，他们将组建一个新的学部。正当大部分美国人还在为找不到一片面包做晚餐而发愁的时候，在普林斯顿却是这样一番景象：高高的天花板和木雕包覆的墙，每天品茶论道，漫步丛林。 一个名叫阿隆佐·邱奇(Alonzo Church)的年轻数学家就过着这样优越的生活。阿隆佐本科毕业于普林斯顿后被留在研究院。他觉得这样的生活完全没有必要，于是他鲜少出现在那些数学茶会中也不喜欢到树林里散心。阿隆佐更喜欢独处：自己一个人的时候他的工作效率更高。尽管如此他还是和普林斯顿学者保持着联系，这些人当中有艾伦·图灵、约翰·冯·诺伊曼、库尔特·哥德尔。
这四个人都对形式系统感兴趣。相对于现实世界，他们更关心如何解决抽象的数学问题。而他们的问题都有这么一个共同点：都在尝试解答关于计算的问题。诸如：如果有一台拥有无穷计算能力的超级机器，可以用来解决什么问题？它可以自动的解决这些问题吗？是不是还是有些问题解决不了，如果有的话，是为什么？如果这样的机器采用不同的设计，它们的计算能力相同吗？
在与这些人的合作下，阿隆佐设计了一个名为lambda演算的形式系统。这个系统实质上是为其中一个超级机器设计的编程语言。在这种语言里面，函数的参数是函数，返回值也是函数。这种函数用希腊字母lambda（λ），这种系统因此得名4。有了这种形式系统，阿隆佐终于可以分析前面的那些问题并且能够给出答案了。
除了阿隆佐·邱奇，艾伦·图灵也在进行类似的研究。他设计了一种完全不同的系统（后来被称为图灵机），并用这种系统得出了和阿隆佐相似的答案。到了后来人们证明了图灵机和lambda演算的能力是一样的。
如果二战没有发生，这个故事到这里就应该结束了，我的这篇小文没什么好说的了，你们也可以去看看有什么其他好看的文章。可是二战还是爆发了，整个世界陷于火海之中。那时的美军空前的大量使用炮兵。为了提高轰炸的精度，军方聘请了大批数学家夜以继日的求解各种差分方程用于计算各种火炮发射数据表。后来他们发现单纯手工计算这些方程太耗时了，为了解决这个问题，各种各样的计算设备应运而生。IBM制造的Mark一号就是用来计算这些发射数据表的第一台机器。Mark一号重5吨，由75万个零部件构成，每一秒可以完成3次运算。
战后，人们为提高计算能力而做出的努力并没有停止。1949年第一台电子离散变量自动计算机诞生并取得了巨大的成功。它是冯·诺伊曼设计架构的第一个实例，也是一台现实世界中实现的图灵机。相比他的这些同事，那个时候阿隆佐的运气就没那么好了。
到了50年代末，一个叫John McCarthy的MIT教授（他也是普林斯顿的硕士）对阿隆佐的成果产生了兴趣。1958年他发明了一种列表处理语言（Lisp），这种语言是一种阿隆佐lambda演算在现实世界的实现，而且它能在冯·诺伊曼计算机上运行！很多计算机科学家都认识到了Lisp强大的能力。1973年在MIT人工智能实验室的一些程序员研发出一种机器，并把它叫做Lisp机。于是阿隆佐的lambda演算也有自己的硬件实现了！
函数式编程
函数式编程是阿隆佐思想的在现实世界中的实现。不过不是全部的lambda演算思想都可以运用到实际中，因lambda演算在设计的时候就不是为了在各种现实世界中的限制下工作的。所以，就像面向对象的编程思想一样，函数式编程只是一系列想法，而不是一套严苛的规定。有很多支持函数式编程的程序语言，它们之间的具体设计都不完全一样。在这里我将用Java写的例子介绍那些被广泛应用的函数式编程思想（没错，如果你是受虐狂你可以用Java写出函数式程序）。在下面的章节中我会在Java语言的基础上，做一些修改让它变成实际可用的函数式编程语言。那么现在就开始吧。
Lambda演算在最初设计的时候就是为了研究计算相关的问题。所以函数式编程主要解决的也是计算问题，而出乎意料的是，是用函数来解决的！（译者：请理解原作者的苦心，我想他是希望加入一点调皮的风格以免读者在中途睡着或是转台……）。函数就是函数式编程中的基础元素，可以完成几乎所有的操作，哪怕最简单的计算，也是用函数完成的。我们通常理解的变量在函数式编程中也被函数代替了：在函数式编程中变量仅仅代表某个表达式（这样我们就不用把所有的代码都写在同一行里了）。所以我们这里所说的‘变量’是不能被修改的。所有的变量只能被赋一次初值。在Java中就意味着每一个变量都将被声明为final（如果你用C++，就是const）。在FP中，没有非final的变量。
final int i = 5;
final int j = i + 3;
既然FP中所有的变量都是final的，可以引出两个规定：一是变量前面就没有必要再加上final这个关键字了，二是变量就不能再叫做‘变量’了……于是现在开始对Java做两个改动：所有Java中声明的变量默认为final，而且我们把所谓的‘变量’称为‘符号’。
到现在可能会有人有疑问：这个新创造出来的语言可以用来写什么有用的复杂一些的程序吗？毕竟，如果每个符号的值都是不能修改的，那么我们就什么东西都不能改变了！别紧张，这样的说法不完全正确。阿隆佐在设计lambda演算的时候他并不想要保留状态的值以便稍后修改这些值。他更关心的是基于数据之上的操作（也就是更容易理解的“计算”）。而且，lambda演算和图灵机已经被证明了是具有同样能力的系统，因此指令式编程能做到的函数式编程也同样可以做到。那么，怎样才能做到呢？
事实上函数式程序是可以保存状态的，只不过它们用的不是变量，而是函数。状态保存在函数的参数中，也就是说在栈上。如果你需要保存一个状态一段时间并且时不时的修改它，那么你可以编写一个递归函数。举个例子，试着写一个函数，用来反转一个Java的字符串。记住咯，这个程序里的变量都是默认为final的5。
String reverse(String arg) {
if(arg.length == 0) {
return arg;
}
else {
return reverse(arg.substring(1, arg.length)) + arg.substring(0, 1);
}
}
这个方程运行起来会相对慢一些，因为它重复调用自己。同时它也会大量的消耗内存，因为它会不断的分配创建内存对象。无论如何，它是用函数式编程思想写出来的。这时候可能有人要问了，为什么要用这种奇怪的方式编写程序呢？嘿，我正准备告诉你。
FP之优点
你大概已经在想：上面这种怪胎函数怎么也不合理嘛。在我刚开始学习FP的时候我也这样想的。不过后来我知道我是错的。使用这种方式编程有很多好处。其中一些是主观的。比如说有人认为函数式程序更容易理解。这个我就不说了，哪怕街上随便找个小孩都知道‘容易理解’是多么主观的事情。幸运的是，客观方面的好处还有很多。
单元测试
因为FP中的每个符号都是final的，于是没有什么函数会有副作用。谁也不能在运行时修改任何东西，也没有函数可以修改在它的作用域之外修改什么值给其他函数继续使用（在指令式编程中可以用类成员或是全局变量做到）。这意味着决定函数执行结果的唯一因素就是它的返回值，而影响其返回值的唯一因素就是它的参数。
这正是单元测试工程师梦寐以求的啊。现在测试程序中的函数时只需要关注它的参数就可以了。完全不需要担心函数调用的顺序，也不用费心设置外部某些状态值。唯一需要做的就是传递一些可以代表边界条件的参数给这些函数。相对于指令式编程，如果FP程序中的每一个函数都能通过单元测试，那么我们对这个软件的质量必将信心百倍。反观Java或者C++，仅仅检查函数的返回值是不够的：代码可能修改外部状态值，因此我们还需要验证这些外部的状态值的正确性。在FP语言中呢，就完全不需要。
调试查错
如果一段FP程序没有按照预期设计那样运行，调试的工作几乎不费吹灰之力。这些错误是百分之一百可以重现的，因为FP程序中的错误不依赖于之前运行过的不相关的代码。而在一个指令式程序中，一个bug可能有时能重现而有些时候又不能。因为这些函数的运行依赖于某些外部状态， 而这些外部状态又需要由某些与这个bug完全不相关的代码通过某个特别的执行流程才能修改。在FP中这种情况完全不存在：如果一个函数的返回值出错了，它一直都会出错，无论你之前运行了什么代码。
一旦问题可以重现，解决它就变得非常简单，几乎就是一段愉悦的旅程。中断程序的运行，检查一下栈，就可以看到每一个函数调用时使用的每一个参数，这一点和指令式代码一样。不同的是指令式程序中这些数据还不足够，因为函数的运行还可能依赖于成员变量，全局变量，还有其他类的状态（而这些状态又依赖于类似的变量）。FP中的函数只依赖于传给它的参数，而这些参数就在眼前！还有，对指令式程序中函数返回值的检查并不能保证这个函数是正确运行的。还要逐一检查若干作用域以外的对象以确保这个函数没有对这些牵连的对象做出什么越轨的行为（译者：好吧，翻译到这里我自己已经有点激动了）。对于一个FP程序，你要做的仅仅是看一下函数的返回值。
把栈上的数据过一遍就可以得知有哪些参数传给了什么函数，这些函数又返回了什么值。当一个返回值看起来不对头的那一刻，跳进这个函数看看里面发生了什么。一直重复跟进下去就可以找到bug的源头！
并发执行
不需要任何改动，所有FP程序都是可以并发执行的。由于根本不需要采用锁机制，因此完全不需要担心死锁或是并发竞争的发生。在FP程序中没有哪个线程可以修改任何数据，更不用说多线程之间了。这使得我们可以轻松的添加线程，至于那些祸害并发程序的老问题，想都不用想！
既然是这样，为什么没有人在那些高度并行的那些应用程序中采用FP编程呢？事实上，这样的例子并不少见。爱立信开发了一种FP语言，名叫Erlang，并应用在他们的电信交换机上，而这些交换机不仅容错度高而且拓展性强。许多人看到了Erlang的这些优势也纷纷开始使用这一语言。在这里提到的电信交换控制系统远远要比华尔街上使用的系统具有更好的扩展性也更可靠。事实上，用Erlang搭建的系统并不具备可扩展性和可靠性，而Java可以提供这些特性。Erlang只是像岩石一样结实不容易出错而已。
FP关于并行的优势不仅于此。就算某个FP程序本身只是单线程的，编译器也可以将其优化成可以在多CPU上运行的并发程序。以下面的程序为例：
String s1 = somewhatLongOperation1();
String s2 = somewhatLongOperation2();
String s3 = concatenate(s1, s2);
如果是函数式程序，编译器就可以对代码进行分析，然后可能分析出生成字符串s1和s2的两个函数可能会比较耗时，进而安排它们并行运行。这在指令式编程中是无法做到的，因为每一个函数都有可能修改其外部状态，然后接下来的函数又可能依赖于这些状态的值。在函数式编程中，自动分析代码并找到适合并行执行的函数十分简单，和分析C的内联函数没什么两样。从这个角度来说用FP风格编写的程序是“永不过时”的（虽然我一般不喜欢说大话空话，不过这次就算个例外吧）。硬件厂商已经没办法让CPU运行得再快了。他们只能靠增加CPU核的数量然后用并行来提高运算的速度。这些厂商故意忽略一个事实：只有可以并行的软件才能让你花大价钱买来的这些硬件物有所值。指令式的软件中只有很小一部分能做到跨核运行，而所有的函数式软件都能实现这一目标，因为FP的程序从一开始就是可以并行运行的。
热部署
在Windows早期，如果要更新系统那可是要重启电脑的，而且还要重启很多次。哪怕只是安装一个新版本的播放器。到了XP的时代这种情况得到比较大的改善，尽管还是不理想（我工作的时候用的就是Windows，就在现在，我的系统托盘上就有个讨厌的图标，我不重启机子就不消失）。这一方面Unix好一些，曾经。只需要暂停一些相关的部件而不是整个操作系统，就可以安装更新了。虽然是要好一些了，对很多服务器应用来说这也还是不能接受的。电信系统要求的是100%的在线率，如果一个救急电话因为系统升级而无法拨通，成千上万的人就会因此丧命。同样的，华尔街的那些公司怎么也不能说要安装软件而在整个周末停止他们系统的服务。
最理想的情况是更新相关的代码而不用暂停系统的其他部件。对指令性程序来说是不可能的。想想看，试着在系统运行时卸载掉一个Java的类然后再载入这个类的新的实现，这样做的话系统中所有该类的实例都会立刻不能运行，因为该类的相关状态已经丢失了。这种情况下可能需绞尽脑汁设计复杂的版本控制代码，需要将所有这种类正在运行的实例序列化，逐一销毁它们，然后创建新类的实例，将现有数据也序列化后装载到这些新的实例中，最后希望负责装载的程序可以正确的把这些数据移植到新实例中并正常的工作。这种事很麻烦，每次有新的改动都需要手工编写装载程序来完成更新，而且这些装载程序还要很小心，以免破坏了现有对象之间的联系。理论上是没问题，可是实际上完全行不通。
FP的程序中所有状态就是传给函数的参数，而参数都是储存在栈上的。这一特性让软件的热部署变得十分简单。只要比较一下正在运行的代码以及新的代码获得一个diff，然后用这个diff更新现有的代码，新代码的热部署就完成了。其它的事情有FP的语言工具自动完成！如果还有人认为这只存在于科幻小说中，他需要再想想：多年来Erlang工程师已经使用这种技术对它们的系统进行升级而完全不用暂停运行了。
机器辅助优化及证明
FP语言有一个特性很有意思，那就是它们是可以用数学方法来分析的。FP语言本身就是形式系统的实现，只要是能在纸上写出来的数学运算就可以用这种语言表述出来。于是只要能够用数学方法证明两段代码是一致的，编译器就可以把某段代码解析成在数学上等同的但效率又更高的另外一段代码7。 关系数据库已经用这种方法进行优化很多年了。没有理由在常规的软件行业就不能应用这种技术。 另外，还可以用这种方法来证明代码的正确性，甚至可以设计出能够自动分析代码并为单元测试自动生成边缘测试用例的工具出来！对于那些对缺陷零容忍的系统来说，这一功能简直就是无价之宝。例如心脏起搏器，例如飞行管控系统，这几乎就是必须满足的需求。哪怕你正在开发的程序不是为了完成什么重要核心任务，这些工具也可以帮助你写出更健壮的程序，直接甩竞争对手n条大街。
高阶函数
我还记得在了解到FP以上的各种好处后想到：“这些优势都很吸引人，可是，如果必须非要用这种所有变量都是final的蹩脚语言，估计还是不怎么实用吧”。其实这样的想法是不对的。对于Java这样的指令式语言来说，如果所有的变量都是必须是final的，那么确实很束手束脚。然而对函数式语言来说，情况就不一样了。函数式语言提供了一种特别的抽象工具，这种工具将帮助使用者编写FP代码，让他们甚至都没想到要修改变量的值。高阶函数就是这种工具之一。
FP语言中的函数有别于Java或是C。可以说这种函数是一个全集：Java函数可以做到的它都能做，同时它还有更多的能力。首先，像在C里写程序那样创建一个函数：
int add(int i, int j) {
return i + j;
}
看起来和C程序没什么区别，但是很快你就可以看出区别来。接下来我们扩展Java的编译器以便支持这种代码，也就是说，当我们写下以上的程序编译器会把它转化成下面的Java程序（别忘了，所有的变量都是final的）：
class add_function_t {
int add(int i, int j) {
return i + j;
}
}
add_function_t add = new add_function_t();
在这里，符号add并不是一个函数，它是只有一个函数作为其成员的简单的类。这样做有很多好处，可以在程序中把add当成参数传给其他的函数，也可以把 add 赋给另外一个符号，还可以在运行时创建add_function_t 的实例然后在不再需要这些实例的时候由系统回收机制处理掉。这样做使得函数成为和 integer 或是 string 这样的第一类对象。对其他函数进行操作（比如说把这些函数当成参数）的函数，就是所谓的高阶函数。别让这个看似高深的名字吓倒你（译者：好死不死起个这个名字，初一看还准备搬出已经尘封的高数教材……），它和Java中操作其他类（也就是把一个类实例传给另外的类）的类没有什么区别。可以称这样的类为“高阶类”，但是没人会在意，因为Java圈里就没有什么很强的学术社团。（译者：这是高级黑吗？）
那么什么时候该用高阶函数，又怎样用呢？我很高兴有人问这个问题。设想一下，你写了一大堆程序而不考虑什么类结构设计，然后发现有一部分代码重复了几次，于是你就会把这部分代码独立出来作为一个函数以便多次调用（所幸学校里至少会教这个）。如果你发现这个函数里有一部分逻辑需要在不同的情况下实现不同的行为，那么你可以把这部分逻辑独立出来作为一个高阶函数。搞晕了？下面来看看我工作中的一个真实的例子。
假设有一段Java的客户端程序用来接收消息，用各种方式对消息做转换，然后发给一个服务器。
class MessageHandler {
void handleMessage(Message msg) {
// ...
msg.setClientCode("ABCD_123");
// ...
sendMessage(msg);
}
// ...
}
再进一步假设，整个系统改变了，现在需要发给两个服务器而不再是一个了。系统其他部分都不变，唯独客户端的代码需要改变：额外的那个服务器需要用另外一种格式发送消息。应该如何处理这种情况呢？我们可以先检查一下消息要发送到哪里，然后选择相应的格式把这个消息发出去：
class MessageHandler {
void handleMessage(Message msg) {
// ...
if(msg.getDestination().equals("server1") {
msg.setClientCode("ABCD_123");
} else {
msg.setClientCode("123_ABC");
}
// ...
sendMessage(msg);
}
// ...
}
可是这样的实现是不具备扩展性的。如果将来需要增加更多的服务器，上面函数的大小将呈线性增长，使得维护这个函数最终变成一场噩梦。面向对象的编程方法告诉我们，可以把MessageHandler变成一个基类，然后将针对不同格式的消息编写相应的子类。
abstract class MessageHandler {
void handleMessage(Message msg) {
// ...
msg.setClientCode(getClientCode());
// ...
sendMessage(msg);
}
abstract String getClientCode();
// ...
}
class MessageHandlerOne extends MessageHandler {
String getClientCode() {
return "ABCD_123";
}
}
class MessageHandlerTwo extends MessageHandler {
String getClientCode() {
return "123_ABCD";
}
}
这样一来就可以为每一个接收消息的服务器生成一个相应的类对象，添加服务器就变得更加容易维护了。可是，这一个简单的改动引出了很多的代码。仅仅是为了支持不同的客户端行为代码，就要定义两种新的类型！现在来试试用我们刚才改造的语言来做同样的事情，注意，这种语言支持高阶函数：
class MessageHandler {
void handleMessage(Message msg, Function getClientCode) {
// ...
Message msg1 = msg.setClientCode(getClientCode());
// ...
sendMessage(msg1);
}
// ...
}
String getClientCodeOne() {
return "ABCD_123";
}
String getClientCodeTwo() {
return "123_ABCD";
}
MessageHandler handler = new MessageHandler();
handler.handleMessage(someMsg, getClientCodeOne);
在上面的程序里，我们没有创建任何新的类型或是多层类的结构。仅仅是把相应的函数作为参数进行传递，就做到了和用面向对象编程一样的事情，而且还有额外的好处：一是不再受限于多层类的结构。这样做可以做运行时传递新的函数，可以在任何时候改变这些函数，而且这些改变不仅更加精准而且触碰的代码更少。这种情况下编译器其实就是在替我们编写面向对象的“粘合”代码（译者：又称胶水代码，粘接代码）！除此之外我们还可以享用FP编程的其他所有优势。函数式编程能提供的抽象服务还远不止于此。高阶函数只不过是个开始。
Currying
我遇见的大多数码农都读过“四人帮”的那本《设计模式》。任何稍有自尊心的码农都会说这本书和语言无关，因此无论你用什么编程语言，当中提到的那些模式大体上适用于所有软件工程。听起来很厉害，然而事实却不是这样。
函数式语言的表达能力很强。用这种语言编程的时候基本不需要设计模式，因为这种语言层次已经足够高，使得使用者可以以概念编程，从而完全不需要设计模式了。以适配器模式为例（有人知道这个模式和外观模式有什么区别吗？怎么觉得有人为了出版合同的要求而硬生生凑页数？）（译者：您不愧是高级黑啊）。对于一个支持currying技术的语言来说，这个模式就是多余的。
在Java中最有名的适配器模式就是在其“默认”抽象单元中的应用：类。在函数式语言中这种模式其实就是函数。在这个模式中，一个接口被转换成另外一个接口，让不同的用户代码调用。接下来就有一个适配器模式的例子：
int pow(int i, int j);
int square(int i)
{
return pow(i, 2);
}
上面的代码中square函数计算一个整数的平方，这个函数的接口被转换成计算一个整数的任意整数次幂。在学术圈里这种简单的技术就被叫做currying（因为逻辑学家哈斯凯尔·加里用其数学技巧将这种技术描述出来，于是就以他的名字来命名了）。在一个FP语言中函数（而不是类）被作为参数进行传递，currying常常用于转化一个函数的接口以便于其他代码调用。函数的接口就是它的参数，于是currying通常用于减少函数参数的数量（见前例）。
函数式语言生来就支持这一技术，于是没有必要为某个函数手工创建另外一个函数去包装并转换它的接口，这些函数式语言已经为你做好了。我们继续拓展Java来支持这一功能。
square = int pow(int i, 2);
上面的语句实现了一个平方计算函数，它只需要一个参数。它会继而调用pow函数并且把第二个参数置为2。编译过后将生成以下Java代码：
class square_function_t {
int square(int i) {
return pow(i, 2);
}
}
square_function_t square = new square_function_t();
从上面的例子可以看到，很简单的，函数pow的封装函数就创建出来了。在FP语言中currying就这么简单：一种可以快速且简单的实现函数封装的捷径。我们可以更专注于自己的设计，编译器则会为你编写正确的代码！什么时候使用currying呢？很简单，当你想要用适配器模式（或是封装函数）的时候，就是用currying的时候。
惰性求值
惰性求值（或是延迟求值）是一种有趣的技术，而当我们投入函数式编程的怀抱后这种技术就有了得以实现的可能。前面介绍并发执行的时候已经提到过如下代码：
String s1 = somewhatLongOperation1();
String s2 = somewhatLongOperation2();
String s3 = concatenate(s1, s2);
在指令式语言中以上代码执行的顺序是显而易见的。由于每个函数都有可能改动或者依赖于其外部的状态，因此必须顺序执行。先是计算somewhatLongOperation1，然后到somewhatLongOperation2，最后执行concatenate。函数式语言就不一样了。
在前面讨论过，somewhatLongOperation1 和somewhatLongOperation2是可以并发执行的，因为函数式语言保证了一点：没有函数会影响或者依赖于全局状态。可是万一我们不想要这两个函数并发执行呢？这种情况下是不是也还是要顺序执行这些函数？答案是否定的。只有到了执行需要s1、s2作为参数的函数的时候，才真正需要执行这两个函数。于是在concatenate这个函数没有执行之前，都没有需要去执行这两个函数：这些函数的执行可以一直推迟到concatenate()中需要用到s1和s2的时候。假如把concatenate换成另外一个函数，这个函数中有条件判断语句而且实际上只会需要两个参数中的其中一个，那么就完全没有必要执行计算另外一个参数的函数了！Haskell语言就是一个支持惰性求值的例子。Haskell不能保证任何语句会顺序执行（甚至完全不会执行到），因为Haskell的代码只有在需要的时候才会被执行到。
除了这些优点，惰性求值也有缺点。这里介绍了它的优点，我们将在下一章节介绍这些缺点以及如何克服它们。
代码优化
惰性求值使得代码具备了巨大的优化潜能。支持惰性求值的编译器会像数学家看待代数表达式那样看待函数式程序：抵消相同项从而避免执行无谓的代码，安排代码执行顺序从而实现更高的执行效率甚至是减少错误。在此基础上优化是不会破坏代码正常运行的。严格使用形式系统的基本元素进行编程带来的最大的好处，是可以用数学方法分析处理代码，因为这样的程序是完全符合数学法则的。
抽象化控制结构
惰性求值技术提供了更高阶的抽象能力，这提供了实现程序设计独特的方法。比如说下面的控制结构：
unless(stock.isEuropean()) {
sendToSEC(stock);
}
程序中只有在stock为European的时候才执行sendToSEC。如何实现例子中的unless？如果没有惰性求值就需要求助于某种形式的宏（译者：用if不行么？），不过在像Haskell这样的语言中就不需要那么麻烦了。直接实现一个unless函数就可以！
void unless(boolean condition, List code) {
if(!condition)
code;
}
请注意，如果condition值为真，那就不会计算code。在其他严格语言（见严格求值）中这种行为是做不到的，因为在进入unless这个函数之前，作为参数的code已经被计算过了。 ####无穷数据结构 惰性求值技术允许定义无穷数据结构，这要在严格语言中实现将非常复杂。例如一个储存Fibonacci数列数字的列表。很明显这样一个列表是无法在有限的时间内计算出这个无穷的数列并存储在内存中的。在像Java这样的严格语言中，可以定义一个Fibonacci函数，返回这个序列中的某个数。而在Haskell或是类似的语言中，可以把这个函数进一步抽象化并定义一个Fibonacci数列的无穷列表结构。由于语言本身支持惰性求值，这个列表中只有真正会被用到的数才会被计算出来。这让我们可以把很多问题抽象化，然后在更高的层面上解决它们（比如可以在一个列表处理函数中处理无穷多数据的列表）。 ####不足之处 俗话说天下没有免费的午餐™。惰性求值当然也有其缺点。其中最大的一个就是，嗯，惰性。现实世界中很多问题还是需要严格求值的。比如说下面的例子：
System.out.println("Please enter your name: ");
System.in.readLine();
在惰性语言中没人能保证第一行会中第二行之前执行！这也就意味着我们不能处理IO，不能调用系统函数做任何有用的事情（这些函数需要按照顺序执行，因为它们依赖于外部状态），也就是说不能和外界交互了！如果在代码中引入支持顺序执行的代码原语，那么我们就失去了用数学方式分析处理代码的优势（而这也意味着失去了函数式编程的所有优势）。幸运的是我们还不算一无所有。数学家们研究了不同的方法用以保证代码按一定的顺序执行（in a functional setting?）。这一来我们就可以同时利用到函数式和指令式编程的优点了！这些方法有continuations，monads以及uniqueness typing。这篇文章仅仅介绍了continuations，以后再讨论monads和uniqueness typing。有意思的是呢，coutinuations处理强制代码以特定顺序执行之外还有其他很多出处，这些我们在后面也会提及。
Continuation
continuation对于编程，就像是达芬奇密码对于人类历史一样：它揭开了人类有史以来最大的谜团。好吧，也许没有那么夸张，不过它们的影响至少和当年发现负数有平方根不相上下。
我们对函数的理解只有一半是正确的，因为这样的理解基于一个错误的假设：函数一定要把其返回值返回给调用者。按照这样的理解，continuation就是更加广义的函数。这里的函数不一定要把返回值传回给调用者，相反，它可以把返回值传给程序中的任意代码。continuation就是一种特别的参数，把这种参数传到函数中，函数就能够根据continuation将返回值传递到程序中的某段代码中。说得很高深，实际上没那么复杂。直接来看看下面的例子好了：
int i = add(5, 10);
int j = square(i);
add这个函数将返回15然后这个值会赋给i，这也是add被调用的地方。接下来i的值又会被用于调用square。请注意支持惰性求值的编译器是不能打乱这段代码执行顺序的，因为第二个函数的执行依赖于第一个函数成功执行并返回结果。这段代码可以用Continuation Pass Style（CPS）技术重写，这样一来add的返回值就不是传给其调用者，而是直接传到square里去了。
int j = add(5, 10, square);
在上例中，add多了一个参数：一个函数，add必须在完成自己的计算后，调用这个函数并把结果传给它。这时square就是add的一个continuation。上面两段程序中j的值都是225。
这样，我们学习到了强制惰性语言顺序执行两个表达式的第一个技巧。再来看看下面IO程序（是不是有点眼熟？）：
System.out.println("Please enter your name: ");
System.in.readLine();
这两行代码彼此之间没有依赖关系，因此编译器可以随意的重新安排它们的执行顺序。可是只要用CPS重写它，编译器就必须顺序执行了，因为重写后的代码存在依赖关系了。
System.out.println("Please enter your name: ", System.in.readLine);
这段新的代码中println需要结合其计算结果调用readLine，然后再返回readLine的返回值。这使得两个函数得以保证按顺序执行而且readLine总被执行（这是由于整个运算需要它的返回值作为最终结果）。Java的println是没有返回值的，但是如果它可以返回一个能被readnLine接受的抽象值，问题就解决了！（译者：别忘了，这里作者一开始就在Java的基础上修改搭建自己的语言）当然，如果一直把函数按照这种方法串下去，代码很快就变得不可读了，可是没有人要求你一定要这样做。可以通过在语言中添加语法糖的方式来解决这个问题，这样程序员只要按照顺序写代码，编译器负责自动把它们串起来就好了。于是就可以任意安排代码的执行顺序而不用担心会失去FP带来的好处了（包括可以用数学方法来分析我们的程序）！如果到这里还有人感到困惑，可以这样理解，函数只是有唯一成员的类的实例而已。试着重写上面两行程序，让println和readLine编程这种类的实例，所有问题就都搞清楚了。
到这里本章基本可以结束了，而我们仅仅了解到continuation的一点皮毛，对它的用途也知之甚少。我们可以用CPS完成整个程序，程序里所有的函数都有一个额外的continuation作为参数接受其他函数的返回值。还可以把任何程序转换为CPS的，需要做的只是把当中的函数看作是特殊的continuation（总是将返回值传给调用者的continuation）就可以了，简单到完全可以由工具自动完成（史上很多编译器就是这样做的）。
一旦将程序转为CPS的风格，有些事情就变得显而易见了：每一条指令都会有一些continuation，都会将它的计算结果传给某一个函数并调用它，在一个普通的程序中这个函数就是该指令被调用并且返回的地方。随便找个之前提到过的代码，比如说add(5,10)好了。如果add属于一个用CPS风格写出的程序，add的continuation很明显就是当它执行结束后要调用的那个函数。可是在一个非CPS的程序中，add的continuation又是什么呢？当然我们还是可以把这段程序转成CPS的，可是有必要这样做吗？
事实上没有必要。注意观察整个CPS转换过程，如果有人尝试要为CPS程序写编译器并且认真思考过就会发现：CPS的程序是不需要栈的！在这里完全没有函数需要做传统意义上的“返回”操作，函数执行完后仅需要接着调用另外一个函数就可以了。于是就不需要在每次调用函数的时候把参数压栈再将它们从中取出，只要把这些参数存放在一片内存中然后使用跳转指令就解决问题了。也完全不需要保留原来的参数：因为这种程序里的函数都不返回，所以它们不会被用第二次！
简单点说呢，用CPS风格写出来的程序不需要栈，但是每次调用函数的时候都会要多加一个参数。非CPS风格的程序不需要额外的参数但又需要栈才能运行。栈里面存的是什么？仅仅是参数还有一个供函数运行结束后返回的程序指针而已。这个时候你是不是已经恍然大悟了？对啊，栈里面的数据实际上就是continuation的信息！栈上的程序返回指针实质上就是CPS程序中需要调用的下一个函数！想要知道add(5, 10)的continuation是什么？只要看它运行时栈的内容就可以了。
接下来就简单多了。continuation和栈上指示函数返回地址的指针其实是同一样东西，只是continuation是显式的传递该地址并且因此代码就不局限于只能返回到函数被调用的地方了。前面说过，continuation就是函数，而在我们特制的语言中函数就是类的实例，那么可以得知栈上指向函数返回地址的指针和continuation的参数是一样的，因为我们所谓的函数（就像类的一个实例）其实就是指针。这也意味着在程序运行的任何时候，你都可以得到当前的continuation（就是栈上的信息）。
好了，我们已经搞清楚当前的continuation是什么了。接下来要弄明白它的存在有什么意义。只要得到了当前的continuation并将它保存起来，就相当于保存了程序的当前状态：在时间轴上把它冻结起来了。这有点像操作系统进入休眠状态。continuation对象保存了足够的信息随时可以从指定的某个状态继续运行程序。在切换线程的时候操作系统也是这样做的。唯一的区别在于它保留了所有的控制权利。当请求某个continuation对象时（在Scheme语言中是通过调用call-with-current-continuation函数实现的）得到的是一个存有当前continuation的对象，也就是栈对象（在CPS中也就是下一个要执行的函数）。可以把这个对象保存做一个变量中（或者是存在磁盘上）。当以该continuation对象“重启”该程序时，程序的状态就会立即“转换”为该对象中保存的状态。这一点和切换回一个被暂停的线程或是从系统休眠中唤醒很相像，唯一不同的是continuatoin对象可以反复的这样使用。当系统唤醒后，休眠前保存的信息就会销毁，否则你也可以反复的从该点唤醒系统，就像乘时光机回到过去一样。有了continuation你就可以做到这一点！
那么continuation在什么情况下有用呢？有一些应用程序天生就没有状态，如果要在这样的系统中模拟出状态以简化工作的时候，就可以用到continuation。最合适的应用场合之一就是网页应用程序。微软的ASP.NET为了让程序员更轻松的编写应用程序，花了大量的精力去模拟各种状态。假如C#支持continuation的话，那么ASP.NET的复杂度将减半：因为只要把某一时刻的continuation保存起来，下次用户再次发起同样请求的时候，重新载入这个continuation即可。对于网络应用的程序员来说就再也没有中断了：轻轻松松程序就从下一行开始继续运行了！对于一些实际问题来说，continuation是一种非常有用的抽象工具。如今大量的传统胖客户端（见瘦客户端）正纷纷走进网络，continuation在未来将扮演越来越重要的角色。
模式匹配
模式匹配并不是什么新功能。而事实上它和函数式编程也没有什么太大的关系。它之所以常常被认为是FP的一个特性，是因为在函数式语言已经支持模式匹配很长一段时间后的今天，指令式语言是还没有这个功能。
还是直接用例子来看看什么是模式匹配吧，这是一个用Java写的Fibonacci函数：
int fib(int n) {
if(n == 0) return 1;
if(n == 1) return 1;
return fib(n - 2) + fib(n - 1);
}
再看看用我们基于Java修改过的新语言写出来的Fibonacci函数，这种新语言就支持模式匹配：
int fib(0) {
return 1;
}
int fib(1) {
return 1;
}
int fib(int n) {
return fib(n - 2) + fib(n - 1);
}
区别在哪里呢？在于后者的编译器替我们实现了程序的分支。
这有什么了不起的？确实也没什么。只是有人注意到很多函数中有非常复杂的switch结构（对于函数式程序而言更是如此），于是想到如果能把这层结构也抽象化就更好了。然后就把这个复杂的函数拆分成若干新的函数，并在这些函数的某些参数中应用模式（这和重载有点类似）。这样依赖当这个函数被调用的时候，编译器会在运行时将调用者传入的参数与各个新函数的参数定义进行比较，找出合适的那个函数来执行。合适的函数往往是参数定义上最具体最接近传入参数的那个函数。在这个例子中，当n为1时，可以用函数int fib(int n)，不过真正调用的是int fib(1)因为这个函数更具体更接近调用者的要求。
模式匹配一般来说要比这里举的例子更加复杂。比如说，高级模式匹配系统可以支持下面的操作：
int f(int n < 10) { ... }
int f(int n) { ... }
那么什么情况下模式匹配会有用呢？在需要处理一大堆程序分支的时候！每当需要实现复杂的嵌套if语句的时候，模式匹配可以帮助你用更少的代码更好的完成任务。我所知道的一个这样的函数是标准的WndProc函数，该函数是所有Win32应用程序必须具备的（尽管它经常会被抽象化）。模式匹配系统一般都可以像匹配简单数值一样匹配数据集合。举个例子，对于一个接受数组作为参数的函数，可以通过模式匹配数组中第一个数字为1并且第三个数字大于3的输入。 模式匹配的另外一个好处是每当需要添加或者修改程序分支时，再也不用面对那个庞大臃肿的函数了。只要添加（或者修改）相关的函数定义即可。有了模式匹配就不再需要四人帮的很多设计模式了。程序分支越多越复杂，模式匹配就越有用。而在习惯使用这一技术之后，你可能会怀疑没有它你一天都过不下去了。
Closure
目前为止关于函数式编程各种功能的讨论都只局限在“纯”函数式语言范围内：这些语言都是lambda演算的实现并且都没有那些和阿隆佐形式系统相冲突的特性。然而，很多函数式语言的特性哪怕是在lambda演算框架之外都是很有用的。确实，如果一个公理系统的实现可以用数学思维来看待程序，那么这个实现还是很有用的，但这样的实现却不一定可以付诸实践。很多现实中的语言都选择吸收函数式编程的一些元素，却又不完全受限于函数式教条的束缚。很多这样的语言（比如Common Lisp）都不要求所有的变量必须为final，可以修改他们的值。也不要求函数只能依赖于它们的参数，而是可以读写函数外部的状态。同时这些语言又包含了FP的特性，如高阶函数。与在lambda演算限制下将函数作为参数传递不同，在指令式语言中要做到同样的事情需要支持一个有趣的特性，人们常把它称为lexical closure。还是来看看例子。要注意的是，这个例子中变量不是final，而且函数也可以读写其外部的变量：
Function makePowerFn(int power) {
int powerFn(int base) {
return pow(base, power);
}
return powerFn;
}
Function square = makePowerFn(2);
square(3); // returns 9
makePowerFn函数返回另一个函数，这个新的函数需要一个整数参数然后返回它的平方值。执行square(3)的时候具体发生了什么事呢？变量power并不在powerFn的域内，因为makePowerFn早就运行结束返回了，所以它的栈也已经不存在了。那么square又是怎么正常工作的呢？这个时候需要语言通过某种方式支持继续存储power的值，以便square后面继续使用。那么如果再定义一个函数，cube，用来计算立方，又应该怎么做呢？那么运行中的程序就必须存储两份power的值，提供给makePowerFn生成的两个函数分别使用。这种保存变量值的方法就叫做closure。closure不仅仅保存宿主函数的参数值，还可以用在下例的用法中：
Function makeIncrementer() {
int n = 0;
int increment() {
return ++n;
}
}
Function inc1 = makeIncrementer();
Function inc2 = makeIncrementer();
inc1(); // returns 1;
inc1(); // returns 2;
inc1(); // returns 3;
inc2(); // returns 1;
inc2(); // returns 2;
inc2(); // returns 3;
运行中的程序负责存储n的值，以便incrementer稍后可以访问它。与此同时，程序还会保存多份n的拷贝，虽然这些值应该在makeIncrementer返回后就消失，但在这个情况下却继续保留下来给每一个incrementer对象使用。这样的代码编译之后会是什么样子？closure幕后的真正工作机理又是什么？这次运气不错，我们有一个后台通行证，可以一窥究竟。
一点小常识往往可以帮大忙。乍一看这些本地变量已经不再受限于基本的域限制并拥有无限的生命周期了。于是可以得出一个很明显的结论：它们已经不是存在栈上，而是堆上了8。这么说来closure的实现和前面讨论过的函数差不多，只不过closure多了一个额外的引用指向其外部的变量而已：
class some_function_t {
SymbolTable parentScope;
// ...
}
当closure需要访问不在它本地域的变量时，就可以通过这个引用到更外一层的父域中寻找该变量。谜底揭开了！closure将函数编程与面向对象的方法结合了起来。下一次为了保存并传递某些状态而创建类的时候，想想closure。它能在运行时从相应的域中获得变量，从而可以把该变量当初“成员变量”来访问，也因为这样，就不再需要去创建一个成员变量了。
路在何方？
这篇文章仅仅涉及到函数式编程的一些皮毛。考虑到有时候星星之火可以燎原，所以如果它能给你一些帮助那就再好不过了。接下来我计划就范畴论、monads、函数式编程数据结构、函数式语言中的类型系统、并行函数式编程、数据库的函数式编程以及更多的话题写些类似的文章。如果我可以写出（在我学习的同时）以上清单的一半，我的人生就完整了。于此同时，Google将是我们的良师益友。
欢迎联系
如果您有任何问题，评价或者建议，请发邮件到coffeemug@gmail.com（译者：如果翻译方面的问题／建议请发到yang.huang@ymail.com:)）。期待您的回复。
Note：
- 当我在2005年求职时的的确确经常问别人这个问题。看着那些茫然的面孔实在是很好玩的事情。你们这些年薪30万美金的家伙，至少应该对自己可以利用的工具有个起码的理解嘛。
- 这是个有争议的问题。物理学家和数学家不得不承认目前还无法确定宇宙万物是不是都遵从可以用数学方法描述的各种法则。
- 我一直一来都很讨厌在历史课上罗列一堆枯燥无味的时间、人名、事件。对我来说历史就是关于那些改变世界的人们活生生的故事，是他们行为背后的个人动机，是那些他们用以影响芸芸众生的方法和工具。从这个角度来说，接下来的这堂历史课是不完整的，很遗憾。只有那些非常相关的人和事会被提及。
- 在我学习函数式编程的时候，“lambda”这个术语搞得我很烦，因为我不知道它到底是什么意思。在这里lambda就是一个函数，在数学符号中用这个希腊字母只是因为它更容易写。所以以后在谈及函数式编程的时候只要你听到lambda，把它在脑中翻译为“函数”就可以了。
- 有意思的是不论如何Java中的字符串总是不可修改的。讨论这种背叛Java的设计背后的原因会很有意思，可惜这样会让我们跑题的。
- 大部分函数式语言的编译器都会尽量将迭代函数转换为对等的循环语句。这种做法叫做尾调用优化。
- 反之则不一定成立。尽管有时候可以证明两段代码是等价的，但不是在所有的情况下都可以得出这样的结论。
- 实际上这样做并不比栈上存储要慢，因为在引入垃圾回收机制后，内存分配操作的时间代价仅为O(1)。
