很奇怪不是，很少有人每天都使用函数式编程语言。如果你用Scala，Haskell，Erlang，F#或某个Lisp方言来编程，很可能没有公司会花钱聘你。这个行业里的绝大部分人都是使用像Python，Ruby，Java或C#等面向对象的编程语言——它们用起来很顺手。不错，你也许会偶然用到一两个“函数式语言特征”，例如“block”，但人们不会去做函数式编程。 然而，很多年来，我们一直被教导说函数式编程语言很好很棒。我仍然记得当我第一次阅读ESR的著名的关于学习Lisp语言的论文时的困惑。也许大多数的人对Paul Graham 的《Beating The Averages》这篇文章更加熟悉： 使用Lisp开发使我们的开发周期迭代的如此之快，以至于有时当竞争对手在新闻发布会上推出他们的新功能一两天后，我们就能复制出同样的功能。当报道产品发布的新闻记者打电话给我们时，我们的产品已经拥有了同样的功能特征。 那些皈依函数式编程的人中，一直常见的考虑是：学习这种新的、函数式的语言“对你有好处”；就像是某些人建议说每天30分钟的健身房活动会“让你的身体健康”一样。但这也同时暗示了这样做的难度和需要的付出。Lisp语言跟Haskell、Ocaml和Scala语言不同，被认为是出了名的难学，可以说是臭名昭著。文雅的人说这是Lisp语言的“深度&广度”的体现。不文雅的人说这是“意淫”或“玩弄学术”或简单的“没必要”。我认为，它的难度跟你对它熟不熟悉有关，而且，这种难度是一种重要指标显示：学习这样的一种语言会让你编程更有效率、能力更强。 它给你的初次印象不友善 我7岁时就开始编程，在漫长无聊的郊区夏季里，在我祖父的计算机上瞎搞一气。我学了BASIC，用它在屏幕上画一个蹦跳的球。我学了Pascal，用它写了一个能通过PC喇叭放音乐的程序。大概10岁时我学了C语言，但遇到了一堵越不过去的墙，直到我上了高中。那就是：指针。即使不算这些该死的指针，我写、读、学习、练习中，同样遭遇无数的失败。我把祖父的硬盘给毁掉了两次(一次属意外)，最后弄得不少次要自己重装操作系统。我失败，一遍遍的失败。 也许你也有跟我相似的故事，也许是完全不同的一个。但我想，差不多所有学过编程的人都有过遇到困难的经历。我们在学了一些基本知识后，必然会遇到一些公认的概念上的关口，比如“指针”。很多计算机科学教授会把指针描述为他们课程上的过滤网。如果你想成为一名优秀的程序员，你必须要能理解指针。很少人能轻松的掌握它们。大多数人，包括我，则需要不断的练习和参考例子来理解什么是指针、为什么它们很重要。 这种艰难的努力过程不是偶然的，是一种几乎普遍的现象。指针是一种非常强大和基础功能的概念。学会它能让你成为一名更好的程序员，能让你的思考更加形象化。即使你使用的语言并不提供指针这样的特征，但跟指针类似的数据结构和概念却随处可见。 新奇事物 一旦你学会了几种语言后，所有的语言都开始看起来都很相似。知道Python的人学习Ruby可能不会遇到太多的问题，知道Java的人学习C#会感到很熟悉。不错，也有意外的地方。Ruby爱好者在学习Python时会对它的comprehension感到吃惊，Java用户会对C#里的委派摸不着头脑。还是那句话，如果你只瞟一眼，它们都很相似。我可以打保票的说，如果你还不曾有过这样的认识，一旦你学了一种Lisp语言，你会发现所有的Lisp变种都很相似。 有人说，大部分人第一次使用Haskell或Ocaml时都完全的不知所措。见鬼了，在Haskell里，连分号都跟别人不一样。这并不是语法的问题；Haskell和ML语言完全基于一种不同的概念、一种新的语言范式。你需要用不同的方式开发应用，不同的方式组织应用，不同的方式扩展应用。 很多这样的新概念都具有不可思议的强大力量。Haskell里的Monads是跟指针一样基础且强大的概念(你很可能在不知道它叫什么的情况下就已经使用过它们了)。所以，跟学了Java后再学C#不一样，有志向学习函数式语言的人需要往回走的更远，去学习更加基础的概念后才能接下去学习。就像是完全再学习一次指针。并且，就像是当年我们刚开始学习编程一样，一些很大的概念看起来会让人迷惑茫然，让人沮丧，直到你去攻克(以及失败)它们。 吃下你的药丸，找到你的药剂师 尽管不好学，但我坚信，学习这些函数式编程语言会在职业上对你有好处。我相信有些人读到这点时会眼睛翻起来向天看，很难想象出这些monoids或monad会对他们在使用Java或C#时有用处。对我而言，我已经不惊奇于由于这样的思维而阻止他们学习函数式语言的现象；他们需要学习一种跟指针和递归一样基础的新概念。他们需要有一种只有专业人员在完成清晰的商业目标时才具有的耐心和斗志。很少人能在过了可塑的年龄后还受得了挫折——一次又一次的挫折——否则我们现在都早成专家了，不是吗？ 还有更复杂的东西，有大量的语言和算法研究都是用函数式语言实施的(尤其是Haskell)。你很容易会被这些不熟悉的概念——例如分类学理论，half-finished abstractions，一些失败的研究——弄的迷失方向。没有一个清晰的指导(比如由一个实用主义的作者写的一本好书)，本来已经很困难的学习任务变的更加可怕。 这些叠加起来的复杂因素导致了不出意外的结果：很多人不情愿在函数式编程学习中投入时间。很容易理解这种不情愿，“我干嘛不把花在学习这些东西的时间用在实现什么东西上呢？”但这种思路也表明了你永远不愿意在任何新技术上浪费时间(只用自己熟悉的)。在一个像软件技术这样日新月异的产业里，我不认为这是正确的判断。 眼见为实 学习一种函数式编程语言最显而易见的好处是，你能学会这种类型语言中的函数式概念。它能帮助你的大脑，让它具有能非常清晰的思考和处理一些惊人的重大概念的能力。这并不是函数式编程具有魔法；各种语言和范式的出现都是为了应对某一特定类别的问题。函数式编程的杀手锏正是应对了当今世界上日益增长的并行性编程和元数据编程趋势。 例如，我们研究一个简化的、本地版本化的Google著名的MapReduce范例。用函数式方式描述这种范例是不可思议的清晰简洁：   mapReducer data partitioner mapper reducer =   let partitions = partitioner data   in reduce reducer (map mapper partitions)   让这样的代码支持并行计算或分布式并行计算是轻而易举的(对于本地并行计算，很多的功能包都支持“pmap”和“preduce“——只需要利用函数式语言的一些简单特性)。像maps，partitions, generators, streams, reductions, folds，已以及function chaining等概念在各种的函数式编程语言中都大同小异，所以，任何对Lisp，Haskell，OCaml，甚至带点函数式语言特征的语言——Python和Ruby熟悉的人，都会很容易的理解这里面的思想精华。 让我们花点时间考虑一下，如何用一种面向对象的语言，以一种常见的面向对象的模式来清楚的描述这种架构。至少你需要做的事情是定义用来描述mapper和reducer的声明。如果你有好奇心，请试着用你喜欢的面向对象语言描述一个最小化的“面向对象”的MapReduce。我发现那是非常罗嗦的。如果使用Java风格的语言，它会像这样： interface Mapper {   B map(A input);   }     interface Reducer {   Y reduce(X a, X b);   }     abstract class MapReduce {   private Mapper mapper;   private Reducer reducer;     public MapReduce(Mapper map, Reducer reduce) {   // ...   }     public run(SeqenceType data) {   // ...   }   }     即使是没有加入循环逻辑