说起来函数式编程 (Functional programming) 这个话题基本是个无底洞，属于在常青藤高校也能开几年课挂掉无数人的领域。如何在短短一个多小时的时间内，让听众有一些直观印象，进而有兴趣继续深入学习下去，这是让我最为头疼的事情。因此我基本放弃了对那些较为复杂概念的介绍，甚至连 Closure 都只敢简单提及，跟别提什么 Monad 这种我自己都挠头的概念。

开讲前在几十个听众中做了个简单调查，果然是听说过和使用过 FP 的人基本都是个位数。这基本上可以说是天朝 CS/EE 教育失败的体现，要知道欧美大学第一年就会讲 Structure and Interpretation of Computer Programs 这种被 Joel 视为是否适合就读 CS 专业过滤器的 BT 课程 (在线课程)。

因此在一开始的时间里，基本上都是集中在对 FP 的鼓吹上，基本集中在 (1) 应对复杂性，(2) 降低维护成本和 (3) 增强自信心三个角度。前面两个基本上是洗脑用套话，个人最赞同也最想灌输的是第三点。

如果实际参与开发过代码量上百万行，代码维护历史在5-7年以上，先后参与人数几十上百的产品，最直观的感受是应该就是对其自身复杂性的本能恐惧。因为对绝大多数技术人员来说，我们更倾向于参与具有确定性的工作，也就是说我们潜意识里认为，我们做的事情应该是有可预测结果的。但一旦代码复杂到了一定程度，解耦没有到位过过于到位，我们就会发现所有的修改，都有可能引发不确定的影响。为了缓解这种影响，我们搞出了各种各样的最佳实践，TDD、CI、peer review，blabla；但归根结底我们只是试图用这些尝试来确保，我们有胆量继续修改那些我们自己也逐渐无法控制的代码，就好象在黑夜中无助的抓住一个火把，却又大声喊叫说自己不怕黑暗。

FP 在这方面可以说具有天然的优势，在去除 side effect 和复杂控制逻辑后，我们通过 Pure functions 和 Recursion 表达的是我们真正的计算目的，而非达成目标的方法。这也是声明式语言 (Declarative programming) 与命令式语言 (Imperative programming) 最大的差别所在。这也是为啥我在开发 rabbitmq-memcached 时，真正能把大部分时间用在编写代码上的原因，实际上线调试反而只是简单而且直接的结果而非过程。