编程的宗派（OOP与FP孰优孰劣）--王垠

编程的宗派

老是有人喜欢争论这类问题，究竟是“函数式编程”（FP）好，仍是“面向对象编程”（OOP）好。既然出了两个帮派，就有人积极地作它们的帮众，互相唾骂和鄙视。而后呢又出了一个“好好先生帮”，这个帮的人喜欢说，管它什么范式呢，能解决问题的工具就是好工具！我我的其实不属于这三帮人中的任何一个。

面向对象编程（Object-Oriented Programming）

若是你看透了表面现象就会发现，其实“面向对象编程”自己没有引入不少新东西。所谓“面向对象语言”，其实就是经典的“过程式语言”（好比Pascal），加上一点抽象能力。所谓“类”和“对象”，基本是过程式语言里面的记录（record，或者叫结构，structure），它本质实际上是一个从名字到数据的“映射表”（map）。你能够用名字从这个表里面提取相应的数据。好比point.x，就是用名字x从记录point里面提取相应的数据。这比起数组来是一件很方便的事情，由于你不须要记住存放数据的下标。即便你插入了新的数据成员，仍然能够用原来的名字来访问已有的数据，而不用担忧下标错位的问题。

所谓“对象思想”（区别于“面向对象”），实际上就是对这种数据访问方式的进一步抽象。一个经典的例子就是平面点的数据结构。若是你把一个点存储为：

struct Point {
  double x;
  double y;
}

那么你用point.x和point.y能够直接访问它的X和Y坐标。但你也能够把它存储为“极坐标”方式：

struct Point {
  double r;
  double angle;
}

这样你能够用point.r和point.angle访问它的模和角度。但是如今问题来了，若是你的代码开头把Point定义为第一种XY的方式，使用point.x, point.y访问X和Y坐标，但是后来你决定改变Point的存储方式，用极坐标，你却不想修改已有的含有point.x和point.y的代码，怎么办呢？

这就是“对象思想”的价值，它让你能够经过“间接”（indirection，或者叫作“抽象”）来改变point.x和point.y的语义，从而让使用者的代码彻底不用修改。虽然你的实际数据结构里面根本没有x和y这两个成员，但因为.x和.y能够被从新定义，因此你能够经过改变.x和.y的定义来“模拟”它们。在你使用point.x和point.y的时候，系统内部其实在运行两片代码，它们的做用是从r和angle计算出x和y的值。这样你的代码就感受x和y是实际存在的成员同样，而其实它们是被临时算出来的。在Python之类的语言里面，你能够经过定义“property”来直接改变point.x和point.y的语义。在Java里稍微麻烦一些，你须要使用point.getX()和point.getY()这样的写法。然而它们最后的目的其实都是同样的——它们为数据访问提供了一层“间接”（抽象）。

这种抽象有时候是个好主意，它甚至能够跟量子力学的所谓“不可观测性”扯上关系。你以为这个原子里面有10个电子？也许它们只是像point.x给你的幻觉同样，也许宇宙里根本就没有电子这种东西，也许你每次看到所谓的电子，它都是临时生成出来逗你玩的呢？然而，对象思想的价值也就到此为止了。你见过的所谓“面向对象思想”，几乎无一例外能够从这个想法推广出来。面向对象语言的绝大部分特性，实际上是过程式语言早就提供的。所以我以为，其实没有语言能够叫作“面向对象语言”。就像一我的为一个公司贡献了一点点代码，并不足以让公司以他的名字命名同样。

“对象思想”做为数据访问的方式，是有必定好处的。然而“面向对象”（多了“面向”两个字），就是把这种原本良好的思想东拉西扯，牵强附会，发挥过了头。不少面向对象语言号称“全部东西都是对象”（Everything is an Object），把全部函数都放进所谓对象里面，叫作“方法”（method），把普通的函数叫作“静态方法”（static method）。实际上呢，就像我以前的例子，只有极少须要抽象的时候，你须要使用内嵌于对象以内，跟数据紧密结合的“方法”。其余的时候，你其实只是想表达数据之间的变换操做，这些彻底能够用普通的函数表达，并且这样作更加简单和直接。这种把全部函数放进方法的作法是本末倒置的，由于函数其实并不属于对象。绝大部分函数是独立于对象的，它们不能被叫作“方法”。强制把全部函数放进它们原本不属于的对象里面，把它们全都做为“方法”，致使了面向对象代码逻辑过分复杂。很简单的想法，非得绕好多道弯子才能表达清楚。不少时候这就像把本身的头塞进屁股里面。

这就是为何我喜欢开玩笑说，面向对象编程就像“地平说”（Flat Earth Theory）。固然你能够说地球是一个平面。对于局部的，小规模的现象，它没有问题。然而对于通用的，大规模的状况，它却不是天然，简单和直接的。直到今天，你仍然能够无止境的寻找证据，扭曲各类物理定律，自圆其说地平说的幻觉，然而这会让你的理论很是复杂，常常须要缝缝补补还难以理解。

面向对象语言不只有自身的根本性错误，并且因为面向对象语言的设计者们经常是半路出家，没有受到过严格的语言理论和设计训练却又自命不凡，因此常常搞出另一些奇葩的东西。好比在JavaScript里面，每一个函数同时又能够做为构造函数（constructor），因此每一个函数里面都隐含了一个this变量，你嵌套多层对象和函数的时候就发现无法访问外层的this，非得bind一下。Python的变量定义和赋值不分，因此你须要访问全局变量的时候得用global关键字，后来又发现若是要访问“中间层”的变量，没有办法了，因此又加了个nonlocal关键字。Ruby前后出现过四种相似lambda的东西，每一个都有本身的怪癖…… 有些人问我为何有些语言设计成那个样子，我只能说，不少语言设计者其实根本不知道本身在干什么！

软件领域就是喜欢制造宗派。“面向对象”当年就是乘火打劫，扯着各类幌子，成为了一种宗派，给不少人洗了脑。到底什么样的语言才算是“面向对象语言”？这样基本的问题至今没有确切的答案，足以说明所谓面向对象，基本都是扯淡。每当你指出某个OO语言X的弊端，就会有人跟你说，其实X不是“地道的”OO语言，你应该去看看另一个OO语言Y。等你发现Y也有问题，有人又会让你去看Z…… 直到最后，他们告诉你，只有Smalltalk才是地道的OO语言。这不是很搞笑吗，说一个根本没人用的语言才是地道的OO语言，这就像在说只有死人的话才是对的。这就像是一群政客在踢皮球，推卸责任。等你真正看看Smalltalk才发现，其实面向对象语言的根本毛病就是由它而来的，Smalltalk并非很好的语言。不少人至今不知道本身所用的“面向对象语言”里面的不少优势，都是从过程式语言继承来的。每当发生函数式与面向对象式语言的口水战，都会有面向对象的帮众拿出这些过程式语言早就有的优势来进行反驳：“你说面向对象很差，看它能作这个……” 拿别人的优势撑起本身的门面，却看不到事物实质的优势，这样的辩论纯粹是鸡同鸭讲。

函数式编程（Functional Programming）

函数式语言一直以来比较低调，直到最近因为并发计算编程瓶颈的出现，以及Haskell，Scala之类语言社区的大力鼓吹，它突然变成了一种宗派。有人盲目的相信函数式编程可以奇迹般的解决并发计算的难题，而看不到实质存在的，独立于语言的问题。被函数式语言洗脑的帮众，喜欢否认其它语言的一切，看低其它程序员。特别是有些初学编程的人，俨然把函数式编程当成了一天瘦二十斤的减肥神药，觉得本身从函数式语言入手，就能够对经验超过他十年以上的老程序员说三道四，仿佛别人不用函数式语言就什么都不懂同样。

函数式编程的优势

函数式编程固然提供了它本身的价值。函数式编程相对于面向对象最大的价值，莫过于对于函数的正确理解。在函数式语言里面，函数是“一类公民”（first-class）。它们能够像1, 2, "hello"，true，对象…… 之类的“值”同样，在任意位置诞生，经过变量，参数和数据结构传递到其它地方，能够在任何位置被调用。这些是不少过程式语言和面向对象语言作不到的事情。不少所谓“面向对象设计模式”（design pattern），都是由于面向对象语言没有first-class function，因此致使了每一个函数必须被包在一个对象里面才能传递到其它地方。

函数式编程的另外一个贡献，是它们的类型系统。函数式语言对于类型的思惟，每每很是的严密。函数式语言的类型系统，每每比面向对象语言来得严密和简单不少，它们能够帮助你对程序进行严密的逻辑推理。然而类型系统一是把双刃剑，若是你对它看得过重，它反而会带来没必要要的复杂性和过分工程。这个我在下面讲讲。

各类“白象”（white elephant）

所谓白象，“white elephant”，是指被人奉为神圣，价格昂贵，却没有实际用处的东西。函数式语言里面有很好的东西，然而它们里面有不少多余的特性，这些特性跟白象的性质相似。

函数式语言的“拥护者”们，每每认为这个世界原本应该是“纯”（pure）的，不该该有任何“反作用”。他们把一切的“赋值操做”当作低级弱智的做法。他们很在意所谓尾递归，类型推导，fold，currying，maybe type等等。他们以本身能写出使用这些特性的代码为豪。但是却不知，那些东西其实除了能自我安慰，制造高人一等的幻觉，并不必定能带来真正优秀可靠的代码。

纯函数

半壶水都喜欢响叮当。不少喜欢自吹为“函数式程序员”的人，每每并不真的理解函数式语言的本质。他们一旦看到过程式语言的写法就嗤之以鼻。好比如下这个C函数：

int f(int x) {
    int y = 0;
    int z = 0;
    y = 2 * x;
    z = y + 1;
    return z / 3;
}

不少函数式程序员可能看到那几个赋值操做就皱起眉头，然而他们看不到的是，这是一个真正意义上的“纯函数”，它在本质上跟Haskell之类语言的函数是同样的，也许还更加优雅一些。

盲目鄙视赋值操做的人，也不理解“数据流”的概念。其实无论是对局部变量赋值仍是把它们做为参数传递，其实本质上都像是把一个东西放进一个管道，或者把一个电信号放在一根导线上，只不过这个管道或者导线，在不一样的语言范式里放置的方向和样式有一点不一样而已！

对数据结构的忽视

函数式语言的帮众没有看清楚的另外一个重要的，致命的东西，是数据结构的根本性和重要性。数据结构的有些问题是“物理”和“本质”地存在的，不是换个语言或者换个风格就能够奇迹般消失掉的。函数式语言的拥护者们喜欢盲目的相信和使用列表（list），而没有看清楚它的本质以及它所带来的时间复杂度。列表带来的问题，不只仅是编程的复杂性。无论你怎么聪明的使用它，不少性能问题是根本无法解决的，由于列表的拓扑结构根本就不适合用来干有些事情！

从数据结构的角度看，Lisp所谓的list就是一个单向链表。你必须从上一个节点才能访问下一个，而这每一次“间接寻址”，都是须要时间的。在这种数据结构下，很简单的像length或者append之类函数，时间复杂度都是O(n)！为了绕过这数据结构的不足，所谓的“Lisp风格”告诉你，不要反复append，由于那样复杂度是O(n2)。若是须要反复把元素加到列表末尾，那么应该先反复cons，而后再reverse一下。很惋惜的是，当你同时有递归调用，就会发现cons+reverse的作法颠来倒去的，很是容易出错。有时候列表是正的，有时候是反的，有时候一部分是反的…… 这种方式用一次还能够，多几层递归以后，本身都把本身搞糊涂了。好不容易作对了，下次修改可能又会出错。然而就是有人喜欢显示本身聪明，喜欢自虐，迎着这类人为制造的“困难”一往无前 :)

富有讽刺意味的是，半壶水的Lisp程序员都喜欢用list，真正深邃的Lisp大师级人物，却知道何时应该使用记录（结构）或者数组。在Indiana大学，我曾经上过一门Scheme（一种现代Lisp方言）编译器的课程，授课的老师是R. Kent Dybvig，他是世界上最早进的Scheme编译器Chez Scheme的做者。咱们的课程编译器的数据结构（包括AST）都是用list表示的。期末的时候，Kent对咱们说：“大家的编译器已经能够生成跟个人Chez Scheme媲美的代码，然而Chez Scheme不止生成高效的目标代码，它的编译速度是大家的700倍以上。它能够在5秒钟以内编译它本身！” 而后他透露了一点Chez Scheme速度之快的缘由。其中一个缘由，就是由于Chez Scheme的内部数据结构根本不是list。在编译一开头的时候，Chez Scheme就已经把输入的代码转换成了数组同样的，固定长度的结构。后来在工业界的经验教训也告诉了我，数组比起链表，确实在某些时候有大幅度的性能提高。在何时该用链表，何时该用数组，是一门艺术。

反作用的根本价值

对数据结构的忽视，跟纯函数式语言盲目排斥反作用的“教义”有很大关系。过分的使用反作用固然是有害的，然而反作用这种东西，实际上是根本的，有用的。对于这一点，我喜欢跟人这样讲：在计算机和电子线路最开头发明的时候，全部的线路都是“纯”的，由于逻辑门和导线没有任何记忆数据的能力。后来有人发明了触发器（flip-flop），才有了所谓“反作用”。是反作用让咱们能够存储中间数据，从而不须要把全部数据都经过不一样的导线传输到须要的地方。没有反作用的语言，就像一个没有无线电，没有光的世界，全部的数据都必须经过实在的导线传递，这许多纷繁的电缆，必须被正确的链接和组织，才能达到须要的效果。咱们为何喜欢WiFi，4G网，Bluetooth，这也就是为何一个语言不该该是“纯”的。

反作用也是某些重要的数据结构的重要组成元素。其中一个例子是哈希表。纯函数语言的拥护者喜欢盲目的排斥哈希表的价值，说本身能够用纯的树结构来达到同样的效果。然而事实倒是，这些纯的数据结构是不可能达到有反作用的数据结构的性能的。所谓纯函数数据结构，由于在每一次“修改”时都须要保留旧的结构，因此每每须要大量的拷贝数据，而后依赖垃圾回收（GC）去消灭这些旧的数据。要知道，内存的分配和释放都是须要时间和能量的。盲目的依赖GC，致使了纯函数数据结构内存分配和释放过于频繁，没法达到有反作用数据结构的性能。要知道，反作用是电子线路和物理支持的高级功能。盲目的相信和使用纯函数写法，实际上是在浪费已有的物理支持的操做。

fold以及其余

大量使用fold和currying的代码，写起来貌似很酷，读起来却没必要要的痛苦。不少人根本不明白fold的本质，却老喜欢用它，由于他们以为那是函数式编程的“精华”，能够显示本身的聪明。然而他们没有看到的是，其实fold包含的，只不过是在列表（list）上作递归的“通用模板”，这个模板须要你填进去三个参数，就能够生成一个新的递归函数调用。因此每个fold的调用，本质上都包含了一个在列表上的递归函数定义。fold的问题在于，它定义了一个递归函数，却没有给它一个一目了然的名字。使用fold的结果是，每次看到一个fold调用，你都须要从新读懂它的定义，琢磨它究竟是干什么的。并且fold调用只显示了递归模板须要的部分，而把递归的主体隐藏在了fold自己的“框架”里。比起直接写出整个递归定义，这种遮遮掩掩的作法，实际上是更难理解的。好比，当你看到这句Haskell代码：

foldr (+) 0 [1,2,3]

你知道它是作什么的吗？也许你一秒钟以后就凭经验琢磨出，它是在对[1,2,3]里的数字进行求和，本质上至关于sum [1,2,3]。虽然只花了一秒钟，可你仍然须要琢磨。若是fold里面带有更复杂的函数，而不是+，那么你可能一分钟都琢磨不透。写起来倒没有费很大力气，可为何我每次读这段代码，都须要看到+和0这两个跟本身的意图毫无关系的东西？万一有人不当心写错了，那里其实不是+和0怎么办？为何我须要搞清楚+, 0, [1,2,3]的相对位置以及它们的含义？这样的写法其实还不如老老实实写一个递归函数，给它一个有意义名字（好比sum），这样之后看到这个名字被调用，好比sum [1,2,3]，你想都不用想就知道它要干什么。定义sum这样的名字虽然稍微增长了写代码时的工做，却给读代码的时候带来了方便。为了写的时候简洁或者很酷而用fold，其实增长了读代码时的脑力开销。要知道代码被读的次数，要比被写的次数多不少，因此使用fold每每是得不偿失的。然而，被函数式编程洗脑的人，却看不到这一点。他们太在意显示给别人看，我也会用fold！

与fold相似的白象，还有currying，Hindley-Milner类型推导等特性。看似很酷，但等你仔细推敲才发现，它们带来的麻烦，比它们解决的问题其实还要多。有些特性声称解决的问题，其实根本就不存在。如今我把一些函数式语言的特性，以及它们包含的陷阱简要列举一下：

1. fold。fold等“递归模板”，至关于把递归函数定义插入到调用的敌方，而不给它们名字。这样致使每次读代码都须要理解几乎整个递归函数的定义。

2. currying。貌似很酷，但是被部分调用的参数只能从左到右，依次进行。如何安排参数的顺序成了问题。大部分时候还不如直接制造一个新的lambda，在内部调用旧的函数，这样能够任意的安排参数顺序。

3. Hindley-Milner类型推导。为了不写参数和返回值的类型，结果给程序员写代码增长了不少的限制。为了让类型推导引擎开心，致使了不少彻底合法合理优雅的代码没法写出来。其实还不如直接要程序员写出参数和返回值的类型，这工做量真的很少，并且能够准确的帮助阅读者理解参数的范围。HM类型推导的根本问题其实在于它使用unification算法。Unification其实只能表示数学里的“等价关系”（equivalence relation），而程序语言最重要的关系，subtyping，并非一个等价关系，由于它不具备对称性（symmetry）。

4. 代数数据类型（algebraic data type）。所谓“代数数据类型”，其实并不如普通的类型系统（好比Java的）通用。不少代数数据类型系统具备所谓sum type，这种类型其实带来过多的类型嵌套，不如通用的union type。盲目崇拜代数数据类型的人，每每是由于盲目的相信“数学是优美的语言”。而其实事实是，数学是一种历史遗留的，毛病不少的语言。数学的语言根本没有通过系统的，全球协做的设计。每每是数学家在黑板上随便写个符号，说这个表示XX概念，而后就定下来了。

5. Tuple。有代数数据类型的的语言里面常常有一种构造叫作Tuple，好比Haskell里面能够写(1, "hello")，表示一个类型为(Int, String)的结构。这种构造常常被人看得过于高尚，以致于用在超越它能力的地方。其实Tuple就是一个没有名字的结构（相似C的structure），并且结构里面的域也没有名字。临时使用Tuple貌似很方便，由于不须要定义一个结构类型。然而由于Tuple没有名字，并且里面的域无法用名字访问，一旦里面的数据多一点就发现很麻烦了。Tuple每每只能经过模式匹配来得到里面的域，一旦你增长了新的域进去，全部含有这个Tuple的模式匹配代码都须要改。因此Tuple通常只能用在大小不超过3的状况下，并且必须确信之后不会增长新的域进去。

6. 惰性求值（lazy evaluation）。貌似数学上很优雅，但其实有严重的逻辑漏洞。由于bottom（死循环）成为了任何类型的一个元素，因此取每个值，均可能致使死循环。同时致使代码性能难以预测，由于求值太懒，因此可能临时抱佛脚作太多工做，而平时浪费CPU的时间。因为到须要的时候才求值，因此在有多个处理器的时候没法有效地利用它们的计算能力。

7. 尾递归。大部分尾递归都至关于循环语句，然而却不像循环语句同样具备一目了然的意图。你须要仔细看代码的各个分支的返回条件，判断是否有分支是尾递归，而后才能判断这代码是个循环。而循环语句从关键字（for，while）就知道是一个循环。因此等价于循环的尾递归，其实最好仍是写成特殊的循环语句。固然，尾递归在另外一些状况下是有用的，这些状况不等价于循环。在这种状况下使用循环，常常须要复杂的break或者continue条件，致使循环不易理解。因此循环和尾递归，其实都是有必要的。

好好先生

不少人避免“函数式vs面向对象”的辩论，因而他们成为了“好好先生”。这种人没有原则的认为，任何可以解决当前问题的工具就是好工具。也就是这种人，喜欢使用shell script，喜欢折腾各类Unix工具，由于显然，它们能解决他“手头的问题”。

然而这种思潮是极其有害的，它的害处其实更胜于投靠函数式或者面向对象。没有原则的好好先生们忙着“解决问题”，却不能清晰地看到这些问题为何存在。他们所谓的问题，每每是因为现有工具的设计失误。因为他们的“随和”，他们历来不去思考，如何从根源上消灭这些问题。他们在一堆历史遗留的垃圾上缝缝补补，妄图使用设计恶劣的工具建造可靠地软件系统。固然，这代价是很是大的。不但劳神费力，并且也许根本不能解决问题。

因此每当有人让我谈谈“函数式vs面向对象”，我都避免说“各有各的好处”，由于那样的话我会很容易被当成这种毫无原则的好好先生。

符号必须简单的对世界建模

从上面你已经看出，我既不是一个铁杆“函数式程序员”，也不是一个铁杆“面向对象程序员”，我也不是一个爱说“各有各的好处”的好好先生。我是一个有原则的批判性思惟者。我不但看透了各类语言的本质，并且看透了它们之间的统一关系。我编程的时候看到的不是表面的语言和程序，而是一个相似电路的东西。我看到数据的流动和交换，我看到效率的瓶颈，而这些都是跟具体的语言和范式无关的。

在个人心目中其实只有一个概念，它叫作“编程”（programming），它不带有任何附加的限定词（好比“函数式”或者“面向对象”）。个人老师Dan Friedman喜欢把本身的领域称为“Programming Languages”，也是同样的缘由。由于咱们研究的内容，不局限于某一个语言，也不局限于某一类语言，而是全部的语言。在咱们的眼里，全部的语言都不过是各个特性的组合。在咱们的眼里，最近出现的所谓“新语言”，其实不大可能再有什么真正意义上的创新。咱们不喜欢说“发明一个程序语言”，不喜欢使用“发明”这个词，由于无论你怎么设计一个语言，全部的特性几乎都早已存在于现有的语言里面了。我更喜欢使用“设计”这个词，由于虽然一个语言没有任何新的特性，它却有可能在细节上更加优雅。

编程最重要的事情，实际上是让写出来的符号，可以简单地对实际或者想象出来的“世界”进行建模。一个程序员最重要的能力，是直觉地看见符号和现实物体之间的对应关系。无论看起来多么酷的语言或者范式，若是必须绕着弯子才能表达程序员心目中的模型，那么它就不是一个很好的语言或者范式。有些东西原本就是有随时间变化的“状态”的，若是你偏要用“纯函数式”语言去描述它，固然你就进入了那些monad之类的死胡同。最后你不但没能高效的表达这种反作用，并且让代码变得比过程式语言还要难以理解。若是你进入另外一个极端，必定要用对象来表达原本很纯的数学函数，那么你同样会把简单的问题搞复杂。Java的所谓design pattern，不少就是制造这种问题的，而没有解决任何问题。

关于建模的另一个问题是，你内心想的模型，并不必定是最好的，也不必定非得设计成那个样子。有些人内心没有一个清晰简单的模型，以为某些语言“好用”，就由于它们可以对他那种扭曲纷繁的模型进行建模。因此你就跟这种人说不清楚，为何这个语言很差，由于显然这个语言对他是有用的！如何简化模型，已经超越了语言的范畴，在这里我就不细讲了。

我设计Yin语言的宗旨，就是让人们能够用最简单，最直接的方式来对世界进行建模，而且帮助他们优化和改进模型自己。