面向对象编程的问题
面向对象的问题在于它对“对象”的定义，它试图将所有事情就纳入到这个概念里。这种做法极端化后，你就得出来一个一切皆为对象思想。但这种思想是错误的，因为
有些东西不是对象。函数就不是对象。
也许你会反驳，在Python和Scala语言里，函数也是对象。在Python中，所有的含有一个叫做__call__的方法的对象其实都是函数。类似的，在Scala语言里，函数是拥有一个叫做apply方法的对象。但是，经过认真的思考后，你会发现，它混淆了源祖和衍生物的概念。函数是源祖，包含函数的对象实际是衍生物。__call__和apply它们自身首先就是要定义的所谓“函数对象”。Python和Scala实际上是绑架了函数，把它们监禁在“对象”里，然后打上“__call__” 和 “apply” 标签，把它们称作“方法”。当然，如果你把一个函数封装到对象里，你可以像使用一个函数那样使用对象，但这并不意味着你可以说”函数也是对象“。

大多数的面向对象语言里都缺乏正确的实现一等(first-class)函数的机制。Java语言是一个极致，它完全不允许将函数当作数据来传递。你可以将全部的函数都封装进对象，然后称它们为“方法”，但就像我说的，这是绑架。缺乏一等函数是为什么Java里需要这么多“设计模式”的主要原因。一旦有了一等函数，你将不再需要大部分的这些设计模式。

还有，纯函数编程语言会带来巨大的认知成本。如果你深入观察它们，你会看到monads使程序变得复杂，难于编写，而且monad的变体都是拙劣的修改。monads跟Java的“设计模式”具有相同的精神本质。使用monad来表现副作用就像是visitor模式来写解释器。你是否发现，在很多其它语言里很简单的事情，放到Haskell语言就变成了一个课题来研究如何实现？你是否经常会看到一些有着诸如“用Monadic的方式解决一个已经解决的问题”这样标题的论文？有趣的是，Amr Sabry先生一起合著了这样一篇论文。他试图用Haskell语言重新实现Dan Friedman的miniKanren，但他不知道如何构造这些monads。他向Oleg Kiselyov——公认的世界上对Haskell类型系统知识最渊博的人——求教。而且你可能不知道，Amr Sabry先生应该是世界上对纯函数编程语言知识最渊博的人了。他们在 Oleg 的帮助下解决了疑难后一起合著了这篇论文。讽刺的是，Dan Friedman——这个程序的原作者——在使用Scheme语言开发时却没有遇到任何问题。我在Dan的代码基础上重新实现了miniKanren，增加了一个复杂的负操作。为了实现这个，我需要使用约束式逻辑编程和其它一些高级的技巧。鉴于用Haskell语言重写基本的miniKanren将两位世界级程序员都难倒了的事实，我不敢想象如果用Haskell的monads如何能实现这些。

有些人认为monads的价值在于，它们“圈定”了副作用的范围。但如果monads不能真正的使程序变得易于分析或更安全，这种“圈定”有什么用呢？事实上就是没用处。本身就跟副作用一样难于分析理解。没有一种东西可以说monads能使其简单而静态分析办不到的。所有的静态分析研究者都知道这点。静态分析利用了monads的本质，但却去除了程序员编写monads代码的负担——而不是增加负担。当然，过度的副作用会使程序很难分析，但你也可以使用C语言写出纯函数，例如：
int f(int x) {
int y = 0;
int z = 0;
y = 2 * x;
z = y + 1;
return z / 3;
}
你用汇编语言也能做到这些。纯函数并不专属于纯函数式编程语言。你可以用任何语言写出纯函数，但重要的是，你必须也应该允许副作用的存在。

回首历史，你会发现，数学上的理想主义是纯函数编程语言的背后推动力。数学函数简单漂亮，但不幸的是，它们只是在你构建原始纯粹的模型时才好用。否者它们会变得很丑陋。不要被“范畴论”等标语吓倒。我对范畴论了解很多。即使是范畴理论学家自己也称其为“抽象无意义”，因为它们基本上就是用一种怪诞的方式告诉你一些你已经知道的事情！如果你读过Gottlob Frege的文章Function and concept，你会吃惊的发现，在他的这篇论文前的大多数数学家都错误的理解了函数，而这仅仅是刚刚100多年前的事。事实上，数学语言上的很多事情都是有问题的。特别是微积分方面。编程语言的设计者们没有理由要盲目的学习数学界。

不要盲目的爱上你的模型
无论任何事情，当走向极端时都是有害的。极端化时，面向对象编程和函数式编程都试图把整个世界装入它们的特有模型中，但这个世界是在完全不依赖我们的大脑思考的情况下运转的。如果以为你有一个锤子，就把所有东西都当成钉子，这明显是不对的。只有通过认清我们的真实世界，才能摆脱信仰对我们的束缚。