编程的宗派总是有人喜欢争论这类问题,到底是“函数式编程”(FP)好,还是“面向对象编程”(OOP)好。既然出了两个帮派,就有人积极地做它们的帮众,互相唾骂和鄙视。然后呢又出了一个“好好先生帮”,这个帮的人喜欢说,管它什么范式呢,能解决问题的工具就是好工具!我个人其实不属于这三帮人中的任何一个。 面向对象编程(Object-Oriented Programming)如果你看透了表面现象就会发现,其实“面向对象编程”本身没有引入很多新东西。所谓“面向对象语言”,其实就是经典的“过程式语言”(比如Pascal),加上一点抽象能力。所谓“类”和“对象”,基本是过程式语言里面的记录(record,或者叫结构,structure),它本质其实是一个从名字到数据的“映射表”(map)。你可以用名字从这个表里面提取相应的数据。比如 所谓“对象思想”(区别于“面向对象”),实际上就是对这种数据访问方式的进一步抽象。一个经典的例子就是平面点的数据结构。如果你把一个点存储为:
那么你用
这样你可以用 这就是“对象思想”的价值,它让你可以通过“间接”(indirection,或者叫做“抽象”)来改变 这种抽象有时候是个好主意,它甚至可以跟量子力学的所谓“不可观测性”扯上关系。你觉得这个原子里面有10个电子?也许它们只是像 “对象思想”作为数据访问的方式,是有一定好处的。然而“面向对象”(多了“面向”两个字),就是把这种本来良好的思想东拉西扯,牵强附会,发挥过了头。很多面向对象语言号称“所有东西都是对象”(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函数:
很多函数式程序员可能看到那几个赋值操作就皱起眉头,然而他们看不到的是,这是一个真正意义上的“纯函数”,它在本质上跟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] 你知道它是做什么的吗?也许你一秒钟之后就凭经验琢磨出,它是在对 与fold类似的白象,还有currying,Hindley-Milner类型推导等特性。看似很酷,但等你仔细推敲才发现,它们带来的麻烦,比它们解决的问题其实还要多。有些特性声称解决的问题,其实根本就不存在。现在我把一些函数式语言的特性,以及它们包含的陷阱简要列举一下:
好好先生很多人避免“函数式vs面向对象”的辩论,于是他们成为了“好好先生”。这种人没有原则的认为,任何能够解决当前问题的工具就是好工具。也就是这种人,喜欢使用shell script,喜欢折腾各种Unix工具,因为显然,它们能解决他“手头的问题”。 然而这种思潮是极其有害的,它的害处其实更胜于投靠函数式或者面向对象。没有原则的好好先生们忙着“解决问题”,却不能清晰地看到这些问题为什么存在。他们所谓的问题,往往是由于现有工具的设计失误。由于他们的“随和”,他们从来不去思考,如何从根源上消灭这些问题。他们在一堆历史遗留的垃圾上缝缝补补,妄图使用设计恶劣的工具建造可靠地软件系统。当然,这代价是非常大的。不但劳神费力,而且也许根本不能解决问题。 所以每当有人让我谈谈“函数式vs面向对象”,我都避免说“各有各的好处”,因为那样的话我会很容易被当成这种毫无原则的好好先生。 符号必须简单的对世界建模从上面你已经看出,我既不是一个铁杆“函数式程序员”,也不是一个铁杆“面向对象程序员”,我也不是一个爱说“各有各的好处”的好好先生。我是一个有原则的批判性思维者。我不但看透了各种语言的本质,而且看透了它们之间的统一关系。我编程的时候看到的不是表面的语言和程序,而是一个类似电路的东西。我看到数据的流动和交换,我看到效率的瓶颈,而这些都是跟具体的语言和范式无关的。 在我的心目中其实只有一个概念,它叫做“编程”(programming),它不带有任何附加的限定词(比如“函数式”或者“面向对象”)。我研究的领域称叫做“Programming Languages”,它研究的内容不局限于某一个语言,也不局限于某一类语言,而是所有的语言。在我的眼里,所有的语言都不过是各个特性的组合。所以最近出现的所谓“新语言”,其实不大可能再有什么真正意义上的创新。我不喜欢说“发明一个程序语言”,不喜欢使用“发明”这个词,因为不管你怎么设计一个语言,所有的特性几乎都早已存在于现有的语言里面了。我更喜欢使用“设计”这个词,因为虽然一个语言没有任何新的特性,它却有可能在细节上更加优雅。 编程最重要的事情,其实是让写出来的符号,能够简单地对实际或者想象出来的“世界”进行建模。一个程序员最重要的能力,是直觉地看见符号和现实物体之间的对应关系。不管看起来多么酷的语言或者范式,如果必须绕着弯子才能表达程序员心目中的模型,那么它就不是一个很好的语言或者范式。有些东西本来就是有随时间变化的“状态”的,如果你偏要用“纯函数式”语言去描述它,当然你就进入了那些monad之类的死胡同。最后你不但没能高效的表达这种副作用,而且让代码变得比过程式语言还要难以理解。如果你进入另一个极端,一定要用对象来表达本来很纯的数学函数,那么你一样会把简单的问题搞复杂。Java的所谓design pattern,很多就是制造这种问题的,而没有解决任何问题。 关于建模的另外一个问题是,你心里想的模型,并不一定是最好的,也不一定非得设计成那个样子。有些人心里没有一个清晰简单的模型,觉得某些语言“好用”,就因为它们能够对他那种扭曲纷繁的模型进行建模。所以你就跟这种人说不清楚,为什么这个语言不好,因为显然这个语言对他是有用的!如何简化模型,已经超越了语言的范畴,在这里我就不细讲了。 我设计Yin语言的宗旨,就是让人们可以用最简单,最直接的方式来对世界进行建模,并且帮助他们优化和改进模型本身。 |