本文发表于《麻省理工科技创业》 2011年第10期,这里贴出的是完整版。
一位我非常喜欢的日本侦探小说家东野圭吾,曾经写过一篇小说:《超读书机器杀人事件》,其中介绍了一种非常先进的“高机能读书机”,不但能够写出一本小说的故事概要,更能够归纳书的内容、撰写心得并输出书评。最神奇的是,这个机器一共有五种评价模式可供选择,包括:“阿谀奉承”、“花言巧语”、“诚朴笃实”、“犀利毒舌”、“尖酸刻薄”。
在看Matz(松本行弘)这本书时,我的心情一直起伏不定,一会儿想写成“阿谀奉承”的模式,一会儿又想写成“尖酸刻薄”的模式,按理说作为一篇客观的书评,自然应该写成“诚朴笃实”的模式,但是,真的很难做到啊。最终,我决定将这篇书评,分为三个部分来写。
一、阿谀奉承篇
作为一个Ruby语言的fans,我在2005年的时候,就开始关注和推崇Ruby与Rails。到现在已经成为一个尽可能只用Ruby完成日常工作的Ruby程序员了。而Matz作为ruby语言之父,在我们这些fans的心目中,地位当然是至高无上的。Ruby之父写的书,怎么可以错过的?更何况,这还不是一般的Ruby语言介绍的书,而是“从一个编程语言设计者的角度去看待各种各样的流行编程语言,分析他们有哪些特点,以及Ruby编程语言是如何取舍的。”——摘自范凯(ITeye网站创始人)的推荐序。而Matz在前言中也说:“最好将本书看成是一幅粗略勾勒出了编程世界诸要素之间关系的‘世界地图’……我的愿望是这些知识能够激发读者学习新技术的求知欲。”。这样的一本书,我是绝对不能错过的!
本书的第一章,Matz介绍自己为什么开发Ruby,谈到的一些观点,深得我心:“编程语言会影响开发者的思想”。所以,在我看来,不同的语言社区,具有差异巨大的社区文化,也应该从语言的特性中去寻找根本原因。Matz设计的Ruby语言的目标是:轻松编程,进而提高开发效率。code
for fun是Ruby社区的基本特色。Ruby语言从一开始就制定的三个设计原则:“简洁性、扩展性、稳定性”,也进而引导Ruby社区,不断追求简洁、美观、方便扩展的代码与框架。整个社区也因此而欣欣向荣。
在谈到名字的重要性时Matz的一段话我非常认同:“我设计上的一个座右铭就是名字很重要,设计任一功能时,我首先会着重考虑它的名字。在我作为编程人员的生涯中,名字好的功能都成功了。”是的,Matz甚至偏执到“仅仅因为名字不好听,就不往Ruby的语言里添加一些别人要求的特性”,并且坦言“对于因为不喜欢名字而没有实现的功能,之后我也没有觉得后悔。”
嗯,我真喜欢这样的Matz!
还有一段话,我也觉得很值得抄出来给大家分享:Matz对于设计模式的看法,发生过几次转变,一开始也认为不过是GoF在夸夸其谈,后来认识到给最佳实践起一个好名字的重要性,并且认为:23个设计模式,应该只是一个开始,以后应该会有一个收录更多模式的目录之类。但是,Matz话锋一转,说到:“很遗憾,这种目录还没有出现,也许人们连现有的23种模式都没能够灵活运用,还没有进化到需要追求更多模式的阶段。”
哈哈,Matz真是个腹黑男啊!
二、尖酸刻薄篇
在阅读本书的过程中,我不时的会看着看着,大喊一声:“坑爹啊!”这本书,坑爹的部分无论是数量还是质量,都非常惊人。第二章谈面向对象,2.4节两个误解,Matz解释到:“对象是对现实世界中具体物体的反应,继承是对物体分类的反应。这个观点是错误。”另一个误解是:“多重继承是不好的,Mix-in不错。”在过去的书和言论者,Matz可能曾经引导过这样的误解,因此他打算再次讲解一下面向对象编程语言和多重继承。
但是,您就以这样的理由,把类似的内容再写一遍吗?2.3.12介绍了一遍Ruby的Mix-in,图2-20给了一段Ruby代码,解释include
module的用法。2.4.6、2.4.7再次介绍驯服多重继承的方法,在Ruby中采用了Mix-in,图2-25又给出了Ruby如何include
module。我觉得,这样的重复并无必要。
更加惊人的重复,出现在第三章。3.2.4节介绍Enumerable模块,列出表3-2中30多个方法,从P69到P70。到了3.3.4再次介绍Enumerable模块,表3-4中又一次列出了30多个一模一样的方法,从P79到P80。而从P71开始的对于Enumerable模块中各个方法的介绍,在P81以后,又以类似的例子再次出现。P72中的条件指定,与P82中的3.3.7用来指定条件的select方法,举的例子,写的代码都一模一样。我想问的是:Matz,您真的这么健忘?居然连10页前出现过的内容都忘记了?还是存心一样的内容多写两遍,以便加深我们的记忆?
翻译的同学,本书的编辑,在审稿的时候,有没有发现这些问题呢?有没有觉得这样是个问题呢?还是莫名其妙的写,糊里糊涂的翻,睁一眼闭一眼的审,最后就把书印出来卖了呢?
三、诚朴笃实篇
实话实说,我在阅读这本书的最初三章时,就出现了剧烈的情绪波动,等到我将后续的章节,以较为平和的心态阅读一遍之后,收获还是非常丰富的。
1、每一章的最后一段作者的话,通常相当精彩,是Matz多年经验的总结与提炼,值得细细品味。
2、相当多的章节,如果能够沉下心来阅读,都给我们带来很多有价值的思考。例如第六章,对于Rails背后的Ruby语言特性,特别是“猴子补丁”的分析,第七章,对于文字编码的背景介绍和梳理,以及第十四章第5小节,讨论为什么要开源的一些观点,都很有价值。
3、本书的很多章节,颇有草草而就的痕迹,例如第十四章名叫函数式编程,却混入了代码生成、垃圾收集、C语言扩展以及开源协议的内容,真正与函数式编程相关的,只有第一节。
总的来说,这本书如果以七五折以下的价格出售,就值得果断入手一本。如果能够仔仔细细的通读一遍,就一定值回票价的。
我也非常认同名字的重要性,不过我觉得Matz没有把它解释清楚。
我认为,一组好名字的背后,是程序作者对自己程序结构的清晰认识,和各部分之间协作关系的精确描述。当我们在代码中看到一组优雅的命名时,脑海里就能形成一个大致的软件的结构和协作关系,我们就十分欢迎这样的代码。
而当我们看到一堆平庸的命名时,不但获取不到结构信息,而且因为含混的字面意义,增加了理解复杂度,那么我们就有理由相信,程序的作者对自己的程序没有清晰的规划和理解,有可能是想到哪就写到哪,因此我们就会拒绝这样的代码。
不过对中国程序员来说,一个杯具是,即使我十分清楚程序的结构和协作关系,也有可能找不到合适的英文单词来描述。最近我开始总结那些好名字的单词组合规律,就算照葫芦画瓢了。
Matz在序里也说到过内容会有重复。这跟这本书的开成有很多关系。所以我觉得不算是一个缺陷吧