The following part is not maintained anymore. Please go to 函数式程序设计的另类指南 for the whole translation.
以下内容不再更新，浏览全部翻译，请访问函数式程序设计的另类指南
原文链接：Functional Programming For The Rest of Us
原文作者：Vyacheslav Akhmechet
Continuations对于程序设计的意义，就像《达芬奇密码》对人类历史的意义：揭露了人类有史以来最大的假象。恩，也许没那么牛。但它在概念上的突破性至少和开方负数的意义相同。
我们学习函数时，其实基于这样一个假设：函数只能将结果返回给调用者。在这个意义上continuation是广义的函数。一个函数不一定必须要返回到其调用者，它可以返回到程序的任何地方。continuation可以是函数的一个参数，我们通过这个参数指定函数返回位置。这个描述可能听起来很复杂，我们来看看下面的代码：
The following part is not maintained anymore. Please go to 函数式程序设计的另类指南 for the whole translation.
以下内容不再更新，浏览全部翻译，请访问 函数式程序设计的另类指南
原文链接：Functional Programming For The Rest of Us
原文作者：Vyacheslav Akhmechet
我们已经讨论了纯函数式语言的很多功能——所谓“纯”函数式语言就是实现了lambda演算并且不包含与Church范式矛盾的特性。但是函数式语言并不仅限于lambda演算。虽然实现一个自我证明的系统非常有用，它可以让我们以数学的方式来思考程序，但是可能在实际中它没有什么用处。所以很多语言选择支持部分函数式元素，但又不严格遵守那些教条。一些语言（比如Common Lisp）不要求变量是final的。你可以随时修改变量。它们的函数也不仅依赖于函数的参数。函数可以访问外部状态。但这些语言的确包含了函数式特性，比如高阶函数。在非纯粹的函数式语言里以函数作为参数传递，和在lambda演算系统中有些不同，它需要一种被称为词法闭包（lexical closure）的有趣特性。让我们来看看这段例子代码。记住，这回变量不是final的，并且函数可以引用其作用域外的变量：
The following part is not maintained anymore. Please go to 函数式程序设计的另类指南 for the whole translation.
以下内容不再更新，浏览全部翻译，请访问 函数式程序设计的另类指南
原文链接：Functional Programming For The Rest of Us
原文作者：Vyacheslav Akhmechet
模式匹配不是什么新特性。事实上，它和函数式编程的关系不大。为什么总是把它当做函数式编程的一个特性呢？这是因为函数式语言已经支持模式匹配一段时间了，而现代命令式语言还不行。
用一个例子来进一步了解模式匹配。下面是Java实现的斐波那契函数：
int fib(int n) {
if(n == 0) return 1;
if(n == 1) return 1;
return fib(n - 2) + fib(n - 1);
}
如果用我们上文构造的并且支持模式匹配的Java来写，实现如下
The following part is not maintained anymore. Please go to 函数式程序设计的另类指南 for the whole translation.
以下内容不再更新，浏览全部翻译，请访问 函数式程序设计的另类指南
原文链接：Functional Programming For The Rest of Us
原文作者：Vyacheslav Akhmechet
当我们采用函数式哲学以后，就可以使用惰性（或延迟）求值这一技术。在并发一节，我们已经看过如下代码：
String s1 = somewhatLongOperation1(); String s2 = somewhatLongOperation2(); String s3 = concatenate(s1, s2);
在一个命令式语言中，求值的顺序一目了然。因为每个函数都有可能改变外部状态，所以执行顺序必须首先是somewhatLongOperation1，然后somewhatLongOperation2，最后是concatenate。在函数式语言中，则不一定非要按照这个顺序。
我们之前讲到，如果没有函数会修改或依赖于全局变量，那么somewhatLongOperation1和somewhatLongOperation2就可以并发执行。但如果我们不想并发执行它们，就必须顺序执行它们么？不一定。只有当另一个函数需要s1和s2的时候，我们才会执行这两个函数。因此在concatenate被调用之前，我们不需要执行它们——我们甚至可以将它们的求值延迟到concatenate函数中实际用到它们的位置。如果我们将concatenate替换成另外一个函数，而这个函数带有一个条件分支。如果该分支每次只会使用两个参数中的一个，。那么我们可能永远没有必要对另一个参数求值。Haskell就是这样一门支持惰性求值的语言。Haskell不能保证每一行代码都会被按顺序执行，甚至不能保证所有代码都会被执行。这是因为只有当一段代码在需要使用的时候，Haskell才会运行那段代码。
惰性求值有利有弊。我们先来说说优点，然后再讨论如何克服缺点。
The following part is not maintained anymore. Please go to 函数式程序设计的另类指南 for the whole translation.
以下内容不再更新，浏览全部翻译，请访问 函数式程序设计的另类指南
原文链接：Functional Programming For The Rest of Us
原文作者：Vyacheslav Akhmechet
我认识的很多人都读过四人帮（GOF）的《设计模式》。任何自恋的程序员都会告诉你，这本书中讨论的模式在软件工程中具有通用性，它和使用哪门语言无关。这个说法显得颇为高深，但是有违现实。
函数式编程极具表达能力。你不需要在函数式语言中使用设计模式，因为这种高级程序设计语言可以让你只进行概念编程，从而不再需要设计模式。适配器(Adapter)模式就是这样的一个例子(适配器和外观模式（Facade）有什么区别？某人可能需要在这里高谈扩论了)。一旦语言有了叫作currying的技术，我们就不再需要适配器模式了。
The following part is not maintained anymore. Please go to 函数式程序设计的另类指南 for the whole translation.
以下内容不再更新，浏览全部翻译，请访问 函数式程序设计的另类指南
原文链接：Functional Programming For The Rest of Us
原文作者：Vyacheslav Akhmechet
我记得即使在了解了上面种种优点之后，自己旧会想“恩，这些的确不错，但是如果让我在一个什么都是final的语言中编程的话，我宁可不用它。”其实你误解了我的意思。将所有变量都声明为final确实显得蹩脚，但是只有在像Java这样的命令式语言中，才会如此；在函数式语言中则不会。函数式语言提供了不同的抽象工具来让你忘记你曾经习惯于修改变量。高级函数就是这样一种工具。
The following part is not maintained anymore. Please go to 函数式程序设计的另类指南 for the whole translation.
以下内容不再更新，浏览全部翻译，请访问 函数式程序设计的另类指南
原文链接：Functional Programming For The Rest of Us
原文作者：Vyacheslav Akhmechet
你可能会认为我根本无法对上面那个变态的函数给出合理的解释。我开始学习函数式编程时，也这么想。不过事实证明我错了。有许多很好的理由来支持这样的写法，当然其中一些是主观因素。比如，有人号称函数式程序易于理解。我不会拿这些理由出来说事，因为小孩子都知道：情人眼里出西施。不过我还能找到很多客观理由。
The following part is not maintained anymore. Please go to 函数式程序设计的另类指南 for the whole translation.
以下内容不再更新，浏览全部翻译，请访问 函数式程序设计的另类指南
原文链接：Functional Programming For The Rest of Us
原文作者：Vyacheslav Akhmechet
函数式程序设计是对阿隆左·丘奇思想的一种实现。但并非所有的lambda演算都被实现了，因为lambda演算原本不是为有物理限制的计算机设计的。因此，函数式像面向对象程序设计一样，只是一系列理念，而不是严格的使用手册。如今有很多种函数式编程语言，它们各自采用了不同的方法。在本文中，我将使用Java来编写函数式程序，并且解释函数式语言的常用特性（的确，如果你有受虐倾向，你可以用Java写函数式程序）。在下面几章中，我将会对Java稍作修改，以使其成为一个可用的函数式编程语言。那我们开始吧。
The following part is not maintained anymore. Please go to 函数式程序设计的另类指南 for the whole translation.
以下内容不再更新，浏览全部翻译，请访问 函数式程序设计的另类指南
原文链接：Functional Programming For The Rest of Us
原文作者：Vyacheslav Akhmechet
再次启动时间机器，这次我们回到二十世纪30年代。大萧条正在蹂躏着那个新旧交替的时代。空前的经济下滑影响着几乎所有阶层的家庭。只有少数人还能够保持着饥谨危机前的安逸，比如普林斯顿大学的数学家们。
歌特式的新办公室给普林斯罩上天堂般的幸福光环。来自世界各地的逻辑学家被邀请到此成立一个新学部。那时的美国民众已很难弄到一块面包，但是在普林斯顿，你可以在高高的穹顶下、精致雕凿的木质墙饰边，整日的品茶讨论，或在楼外的林荫中款款慢步。
阿隆左·丘奇（Alonzo Church）就是其中一位享受这种近于奢华的数学家。他在普林斯顿获得本科学位后被邀继续留在研究生院攻读。阿隆左认为普林斯顿的建筑过于浮华，所以他很少一边喝茶一边与人讨论数学，他也不喜欢到林中散步。他有些孤僻，因为似乎只有一个人时他才能以最高的效率工作。尽管如此，他仍与另一些同样居住在普林斯顿的人保持着联系，比如阿兰·图灵（Alan Turing），约翰·冯·诺依曼（John von Neumann），和库尔特·冈特（Kurt Gödel）。
The following part is not maintained anymore. Please go to 函数式程序设计的另类指南 for the whole translation.
以下内容不再更新，浏览全部翻译，请访问 函数式程序设计的另类指南
原文链接：Functional Programming For The Rest of Us
原文作者：Vyacheslav Akhmechet
启动时间机器，我们来到两千多年前的一个公园里。具体时间大约是公元前380年的一个春光明媚的周日。在雅典城外的橄榄树树荫里，柏拉图（Plato）和一个英俊的奴隶小男孩正朝着学院走去。那天天气很好，晚饭也不错。他们边走边讨论一个哲学问题。
为了使问题更有教育意义，柏拉图小心地挑选着词句：“瞧这两个学生，你认为谁更高呢？”小男孩看了看那两个站在水池中的人，说，“他们俩差不多高”。柏拉图问：“你说‘差不多’是什么意思？”。“恩……我在这儿看他们是一样高的，不过我肯定如果走近些就会看出他们的差别。”
柏拉图笑着把这个孩子引向正确的思路。“那么你是说，这个世界上没有完全的相同的两个东西了？”小男孩想了一会儿回答，“对。我想，即使我们看不到，任何事物之间总有一些区别。”正中下怀！“那么如果这世上没有完全相同的两个东西，你怎么理解‘完全’相等这个概念呢？”小男孩有点被问住了，说：“我不知道”。