巴别塔-编程语言之旅

16 Jan 2014

1 说明

  1. 英文原版本:https://sites.google.com/site/steveyegge2/tour-de-babel
  2. 另外一个中文翻译版本:https://code.google.com/p/windows-config/wiki/TourDeBabel

作者是Steve Yegge,当时在亚马逊工作。

文章内容比较和我胃口,于是决定翻译。刚开始没细查,以为没有别的中文翻译。翻译一半后才发现有中译版本。但是还是决定继续翻译下去。在无法理解的地方或者拿不准的地方参考了上面的中文版本。在此感谢。

加加起来费了我3天的工作量,真是个大坑。

以上。哎呦,果然逼格感觉提高不少啊。

2 巴别塔

这是我自己混乱的编程语言之旅,原本准备这个月写给ADJ(Amazon Developers Journal),但是实在写的不像样,拿不出手。

首先,就是文章写的比较糙,自己吐槽起来也没个度,所以没法当作所谓的官样文章了。于是我就只能把这玩意放我的blog上了,反正也没人读,是吧。除了你么,没错,专为你私人定制,亲。

另外,也没有完全的完成。只是这写写那写写,没怎么润色。这么来看,放blog上也合适。不用注意文笔,也不用非得写的完整。就是我目前能想到的内容。亲,请过目。

我的编程语言的经历比较杂哈,包括C、C++、Lisp、Java、Perl(以上这些都是我们在AMZ用的),Ruby(我个人爱好),还有Python,这个么,后面会说,现在不急。

2.1 C

C你肯定得会。为什么呢?因为你没得选,这个地球上的计算机都是冯诺依曼机器,C就是针对冯诺依曼机器特点的轻量级、形象的语法描述。

冯诺依曼机器就是你平时用的计算机的架构:一个CPU,内存,硬盘,总线。当然多CPU也没什么区别。这货就是个实现简单、成本低、1950年代就能实现的图灵机。图灵机自然就是那个闻名于世的可以进行计算的抽象模型。

当然其实还有其他类型的机器,比如还有Lisp Machines,1950年代(译注:貌似Lisp机器不是1950年代出现的)的Lisp实现。Lisp就是门基于lambda算子的编程语言,这也是另外一个计算模型。不像图灵机,lambda算子更符合人类认知习惯。当然,两者的计算能力是等价的,都准确描述了计算机的能力。

Lisp机器不怎么常见,一般也就在车库大甩卖上能遇到。冯诺依曼自然是在更加流行。还有其他各种类型的机器,什么神经网络或者细胞自动机,现在也没怎么流行,也可能是时候未到。

所以你得会C。

另外一个原因就是Unix是C写的,额,还有Windows,还有差不多所有的操作系统。因为这些操作系统都是跑在冯诺依曼机器上的,你还能指望用其他的语言么?任何和C明显不同的特性,硬件都没法实现的太好,起码对上个世纪的操作系统来说是的,可惜,目前的这些系统都是上个世纪写的。

你也应该了解下Lisp。GNU的应用有不少是支持的不错的,当然,你平时工作估计用不上。最好学Scheme,小而纯粹的Lisp。GNU的实现叫做Guile

MIT和伯克利的新生都要先学Scheme一到两个学期,学生自然搞不懂干嘛学这种古怪的语言。实话实说,这货确实不适合当作入门语言来学,恩,也不适合当作第二门。不过你还是应该学一学,但是不要拿它来入门。

学Lisp还是比较难的,跨度比较大。指望用Lisp写C一样的程序是没辙的,也没什么意义。他们正好站在各自的对立面上,同时也相互互补。

C算是最接近计算机工作的语言,Lisp则是最接近计算的模型。你也用不着了解太多Lisp的东西。学好Scheme就够了,它是最简单而清晰的Lisp了。其他的Lisp都变成了臃肿复杂的开发环境了,和C++、Java一样,他们有丰富的程序库啦,他们有多彩的开发工具啦,以及各种各样的莫名其妙的东西,具体什么东西反正你也不用知道。你最好能用Scheme写程序,做完The Little Schemer 和The Seasoned Schemer里面的习题应该就算达到这个标准了。

你记得再选一门日常使用的语言,这你就得评估下他的库、文档、工具支持、与OS的集成、资源,还有那么一堆其实和计算机工作原理没什么关系的东西,以及,一堆和如何让人更好工作的紧密相关的东西。

目前还是有人用C写东西的,而且数量庞大。要记住这点。

2.2 C++

C++算是有史以来最傻逼的语言了,注意啊,我这个评价是十分客观不带私人感情的啊。他都没法知道他自己,因为他不是自省型的语言。虽说C也不是吧,但是C也不是面向对象的,犯不着需要程序了解自身。对象如同演员,所以面向对象的语言需要有运行时反射和动态类型,而C++没有这个能力,也就没有这个用法。

再说说C,为了支持在C的基础上构建类似自省机制的工具,你可以写一个新的C编译器,写C编译器的难度并不大。C++就不是这样了,语法复杂基本没法解析。如果你打算自己实现一个可以告诉你虚函数原型或者帮你重构代码的工具,呵呵,你肯定会死在使用某个人的工具集这步上。因为我百分百确定,你自己就没法写个C++的解析器。而全世界的解析C++的工具集都超级次。

C++傻逼,你不能指望用个傻逼语言就可以写出个聪明的系统来。语言决定了其实现的结果。傻逼语言注定产出傻逼系统。

所有的计算都是通过抽象来实现的,你不断的一层层的向上抽象,慢慢的通过层次的过度来控制复杂度。没人会直接用分子来建个城市。直接使用过于底层的抽象来实现程序,你就玩蛋去吧。

我们公司就正在玩蛋呢。

能用C写的最大的东西就是操作系统。其实操作系统的规模不算大。之所以大家都觉得操作系统好大,那是算上系统上的各种应用的。操作系统内容本身是很小巧的。

C++能写的最大的东西,也是操作系统。可能会稍微再大一点点吧,就算大三倍或者十倍吧。但是内核最多也就还是那么大,差不多一百万行代码的样子?所以我就算C++最多可以写个一千万行的系统吧。再多下去,整个系统就会开始出现问题,难以控制,如同一个黑洞。那时的你,就会有你的女人说出“我还要”这句的时候的感觉。

当然,前提是到那个时候你还能把这个系统给编译完成了。

我司就有五千万行的C++代码,现在应该更多了,反正我自己心里是没数了。上个圣诞节是九个月前了,那时候就这个规模了。开发的速度是每个季度八百万行代码,而且这个速度还越来越快。我操。

你还非得在这堆代码上继续写东西。我司的一个工程师就说过,我们的代码就像"一大坨屎山,而且还是你这辈子能看到的最雄伟的一座,你的工作就是每当需要修复问题的时候,巴拉巴拉的钻到这坨屎的最里面"。

兄弟,这还是四年前呀。那个工程师也已经换了个更加环保地上没多少屎的牧场继续工作了。真是可惜,那么优秀的基友就这么走了。

这都他妈是C++的错,别和我争,这绝对是铁打的结论。我们用着世界上最傻逼的语言。这就是所谓的元傻逼,是吧,你一定就是这么想的?

其实,还是可以写出漂亮的C++代码的。我的意思就是,大部分都保持C的风格,谨慎少量的使用一些C++的特性。不过没人这么做过。C++就是让你撒欢的大游乐场。你如果很了解它的话,就会显得自己很牛逼。所以你就会拼命的用各种C++的特性,可惜难度太大。因为C++本来就是一坨屎一般的语言,最后哪怕你是个优秀的工程师,照样写个一团糟的系统。

损得有些过分是吧,没错,就是他妈这么过分。当然,我还是要说一句,“爱过,大学的时候”。因为那时候的我年少无知,没见过世面。当我听说教计算机语言的教授,Craig Chamber,超级讨厌C++的时候,我当时还想着“这是怎么回事?我觉得她还是挺好的么”。当我听说STL的作者说他恨OOP的时候,我也觉得这货一定是脑子被驴踢了。怎么会有人恨OOP呢?何况他还是STL的作者?

人都说越了解对方就越讨厌对方,可惜计算机语言不是这样。你非要成为一个更加优秀的语言的专家才会开始讨厌那个你最了解的语言。

所以,你要是不鸟我之前对C++的血泪控诉。先成为一个更加优秀的语言的专家吧(我个人推荐Lisp),这样也好提升你的战斗力来和我争论。哈,不过倒时候恐怕你就不会和我争了,不好意思坑了你,让你从此不再喜欢C++。而且你还会因为我让你和自己最喜欢的前任语言分手而骂我。所以,就当我什么都没说吧。C++超牛逼,宇宙第一真理。就这样忘了我说的话吧,就这样。

2.3 Lisp

(下面的内容绝对叹为观止,前面你也看了这么多了,放心,后面更精彩) Amazon刚开始的时候,我们有超牛逼的工程师。虽然我不都认识吧,但是还是了解那么几个的。

要例子? Shel Kaphan, 牛逼闪闪。 Greg Linden,爆瞎你的眼。Eric Benson,来我司前就光芒耀眼了,不戴墨镜不行了吧。

他们写了Obidos web服务器,而Obidos则成就了Amazon。那些年,还是堆屎山的工程师和web开发(大部分都是前端,严格按照日程表产出垃圾,当然,他们的经理倒是很开心)来之前。那些年,Obidos还没有被这群人玷污。虽然后来有点堵河道的意思(译注:Obidos位于亚马逊河最窄水流最快的位置),但是它还是Amazon初期获得成功的重要基石。

最初的牛逼闪闪的兄弟姐妹都只允许两种语言存在于Amazon神圣的代码库里,那就是C和Lisp。

你们可能有些不相信。

他们全都用Emacs,那是必然的。Eric Benson自己就是XEmacs1的开发。优秀的工程师都在用Emacs,这些工程师都是改变世界级别的人。我说的不是你旁边工位的牛逼程序媛,也不是Fred,那个和你一层楼的厉害人物。我说的都是我们这行里面的最优秀的开发人员,他们都曾改变了我们行业的面貌。James Goslings, Donald Knuths, Paul Grahams2, Jamie Zawinskis, Eric Bensons,真工程师都用Emacs。要用好她是很费脑筋的,等你能驾驭她的时候,她就会让你变得难以置信的强大。不信?等Paul Nordstrom工作的时候你可以站在后面看看。你们这些一辈子只知道用什么Visual XX,.Net什么IDE的就会开开眼了。

Emacs身体健康、万寿无疆。

Shel, Eric, Greg还有那些我没能一起直接共事的工程师们,他们都不会允许C++的存在,恩,还有Perl(或者还有Java)。人家都是精英中精英,不会错的。

现在C++,Java还有Perl都被写入代码库了。老一辈们也都换到更加环保绿色的农场去了。

Shel用C写了个Mailman,然后客服中心就用Lisp包了一层,Emacs-Lisp写的。你没听说过Mailman?那些老员工,有些还是为了让客户开心的非技术人员都知道这个东西。因为某些你写的脑残特性崩了(八成都是C++写的),客户不高兴了,所以你就得赶紧修复,让客户满意。当年都需要和客户直接沟通交流,那些我们亲爱的狗屁不懂的还说不出个所以然的一直糊里糊涂的,永远提出“有益”建议的喜怒无常的客户,那些一个个都是实实在在的从我们这买了东西的人。那你就得用Mailman。

Mailman就是客服用来处理客户邮件的应用。大概用了4、5年?反正时间够长了。在Emacs里使用,每个人都爱用。

其实现在还有人爱着他。直到最近,我还会听到非技术人员长篇大论的和我说他们有多想念Mailman。上次圣诞节,我参加了一个Amazon的大扒提。我都不知道自己是怎么被邀请的,反正都是商务人士,各个光鲜亮丽,耀眼夺目,反正我自己还有那些和我一起在Furnace这个我司的大锅炉房里工作的同事在旁边一定相形见绌。4个年轻的女士发现我是客服部门的,于是就围过来,说了十五分钟,她们多么多么想念Mailman和Emacs,那个Arizona(我们花了好几年开发的JSP版本的Mailman的替代)到现在都和她们不默契。

有那么点难以置信吧,以至于我都觉得她们喝多了。

Shel是天才,Emacs也是。哪怕非技术人员都喜欢Emacs。我现在就在Emacs里面写东西,我还没主动在其他地方写过东西。Emacs是一个有各种别的地方没有的快捷键和文字编辑特性的效率提升工具。我在Emacs写纯文本的时候可以每分钟打字130-140个词,还没错误。这是我专门弄了一个Emacs的记录软件统计的结果。但是,Emacs还不止如此。

Emacs就是无印良品、业界良心啊。

我们撤了Mailman,那是因为我们成功的变成了有印品,大印上写着一个“次”。我们就是次,找不到擅长Emacs-Lisp的人来维护软件。现在倒是简单得多了,亚马逊有不少会Emacs Lisp的。当时,客服软件就没人有技术能维护,于是呢,大家就用自己手头上的技术再弄一套了,当时就是没有多少会Emacs-Lisp的人。有段时间还专门雇了Bob Glickstein,O'Reailly的那本长颈鹿书 Writing Gnu Emacs Extensions 的作者,就坐在证券大厦里面的小工作间里写Mailman的扩展。

客服应用组算是亚马逊的第一个双批萨团队,你懂的。不管以前还是现在,都是完全的没人鸟。没人和你聊聊天啊,也没人会专门来帮你,一切靠自己。没有web开发,没有支持工程师,地方也小的可怜。好歹还有坚若磐石的工程师和menter文化,这也是他们一直以来仅仅需要的东西。

最终还是撤掉了Mailman。可惜啊,真他妈可惜。现在我还是能听见别人在公司聚会上讨论对Mailman的相思之情。

我看,人均上客服应用组的Lisp黑客要比别的任何组都多。倒不是因为他们用Lisp比较多,而是如Eric Raymond所说,即使不用Lisp编程,学习Lisp会在你余生成为更好的工程师的道路上产生深远的影响。

马克思同志,宗教已经不再是群众的精神鸦片了。现在,IDE们才是。

2.4 Java

Java同时成为计算机行业过去十年以来最差也是最好的一件事情。

一方面,Java让你远离C++各种繁杂容易出错的细节。没有越界问题、没有core dump,异常抛出点可以精确的告诉你发生错误的代码位置,而且99%情况下说的都没错,对象打印也挺智能。等等等等的优点。

另一方面,作为一门语言、一个虚拟机、一坨子类库、一个安全模型、一种bytecode的格式,Java简直可以包揽你的一切,成为你的信仰。所以你没法相信一个深爱Java的人。雇佣一个优秀的Java程序员实在是难度比较大。

但是Java还是软件工程领域的一大步。

从C++过渡到Java,不仅仅是语法的变化。这是一个很大的编程范式的转变,需要一段时间才能深入。就像你突然有了个助理一般。你知道VP们是怎么整天开会还能知道公司如何运行,写漂亮的文档以及做其他的类似各种事情?VP们总是忘记其实他们是两个全职的人:他们自己,还有他们的助理。有一个助理的话,你就可以思考那些真正需要你解决的问题了。没有的话,你就要花费你自己一半的时间处理各种无聊的事情。换到Java就将你变成了两个程序员-一个处理那些你不再需要关心的事情,另外一个则可以集中精力在解决问题上。这一变化是巨大的,而且你很快就会习惯这个变化。

就像Jamie Zawinski在他著名的“java sucks”文章里说的:“首先谈谈优点:Java没有free()。这你不得不承认,其他的东西都不重要。就因为这一点我就可以原谅其他的任何不论多可怕的事情。就因为这一点,本文中的其他内容根本就不值一提。”

Jamie的文章写于1997年,对Java来说也是很久以前了,这么多年来Java已经有了很多改进,文中抱怨的部分内容也已经不再存在了。

另外大部分则还是那样。Java作为编程语言来说还是有点次。但是如Jamie所言,确实是“当今最好的语言,也就是说,相比那些烂得底儿掉的一堆语言,Java好歹还是可以接受的。”

上面这篇文章 你值得一读。

Java其他各方面都很优秀,除了作为语言本身这点,这也是Jamie批评最多的地方。但是这点却是个大问题。库很好也不能解决语言本身的问题。相信我,你或许在其他方面懂得比我多,但是我知道,库解决不了语言本身的问题,在Geoworks5年的汇编语言的地狱教会的我。

比起C++,Java也差不多。开玩笑了,其实好太多了。因为他有字符串,亲,一个语言没有一个良好的字符串支持你还怎么用?

当然,Java也缺少很多C++里不错的特性,比如传引用(函数调用时),typedef,宏,操作符重载。这些都是用起来很顺手的东西。

还有多继承,我一直很怀念的一个特性。你如果认为我这个观点 自以为是,是多态教条的一个经典例子的话,我可以举出好几个例子来说明为什么需要多继承,起码要有Ruby风格的mixins或者自动派遣。哪天你可以专门问问我曾经的那些经历,我可以给你好好讲上一讲。反正,接口就是个错误。

Gosling几年前说过,要是能把Java推翻重来,就根本不会用接口。

这恰恰也是Java的一个问题。当James说出那句话的时候,人们被雷到了。我甚至能感觉到那股雷劲儿。比如Sun公司的那些市场、法务的人,想要把他灭口,然后对大家说:”扯淡呢,没这回事“。

Java的问题就是天花乱缀的市场宣传让人们失去了判断力。这是像C++、Perl这种比较流行的语言的通病,这个问题也比较严重。因为语言需要宣传才能流行。要是哪个不识相的语言设计者说自己的语言其实设计的还是有那么一点问题的话,赶紧赏他一剂强效镇静剂,把会议先停了再说。

语言需要宣传才能生存。我希望是的各位不要因为宣传失去了自己的判断。

我就是喝了OOP的迷魂汤,还好自己迷途知返。我加入亚马逊的时候,就能给你说出一大堆之前学的各种咒语、溢美之词、神棍言论。都是些不顾思考和经验的宣言。每个人都说不好所以多继承不好,操作符重载不好,还有其他的各种。我自己有时还模糊的觉得自己知道原因,不过其实也不知道。后来我才慢慢的觉悟,不是多继承好不好的问题,而是开发者自己优秀与否的问题。我当时够次,虽说这么多年来我都在慢慢的提高吧,但现在我还是次货一个。

上周有个来面试的告诉我多继承不好,还举了个例子:你可以从头、手臂、腿、躯干来继承出来一个人的类型。他既对也错。这个多继承的例子确实有问题,但是问题在他自身。正常人一眼就明白这么做不对,要是他真这么实现了绝对是他的问题。

全世界开发者的主要组成部分基本上都是烂开发。你丢给他什么语言,他都能用这个语言写出烂代码。

当然,多继承也不是很容易的事情,mixin是稍微好点的解决方法,可惜,到现在也没有什么完全的解决方法。但是,就算没有多继承,Java还是要比C++好的。因为虽然愿望很美好,但是现实中我总会发现身边会有不知道如何写代码的人,这些人用Java总比用C++好,起码破坏性要低了。

另外,Java也不仅仅就是编程语言本身,还有很多其他的内容。而且Java语言本身也一直在进化,速度很慢,但起码还是有希望的。所以我司用Java还是比较合适的。

对于任何语言,大部分人都是对语言环境了解的很不错,但是对于代码的品味、计算的原理等等等等其他重要的因素却了解的不多。所以招人的时候要注意。

如果拿不准主意,你可以雇那些懂得多种编程语言的Java程序员,他们会讨厌用一些难以理解的架构,比如J2EE和EJB,一般也会用Emacs。看起来有点武断是吧,放心,看疗效吧。

2.5 Perl

Perl,不怎么好说啊。

老朋友了,回想起来,我在1995年就开始写Perl了。快10年了,我用着也还不错。

就像你当年骑的大二八,总是那么有点感情的。等你换了俩更好更舒服的自行车,还是会怀念它。

Perl流行的原因就是以下三点:

  1. 可以很快的解决手上的问题,而往往时间就是金钱。
  2. Perl的营销是最好的。Perl的营销都可以专门拿出来写本书了。Sun拿钱砸出来的Java。Perl就纯粹靠着Larry Wall和他那帮小兄弟的天才营销一直紧跟着Java的势头。哈佛商学院的人就该好好研究研究人家的营销,绝对叹为观止。
  3. 哪怕到最近,准确说是到现在,也都没有竞争对手。

比Perl“好”的语言多的可以成捆成捆的卖,只要这里的“好”意思是“不疯狂”。Lisp、Smalltalk、Python,呵呵,我差不多能举出二三十中比Perl“好”的语言。但是都不像今年夏天台湾大街上爆炸的抹香鲸那样,内脏到处都是,汽车、摩托、行人,统统是满身的内脏。而Perl却具有这样的特点,也才是引人入胜的地方。

但同时Perl也有很多哪怕到现在其他语言也没有的特性,这就可以弥补其什么都暴露在外的不足。爆炸的鲸鱼里面照样都是宝,你可以从其中拿到材料做香水。Perl就像这头抹香鲸一样,十分有用。

其他的各种语言(尤其是Lisp和Smalltalk)都试图让操作系统对用户透明,于是你只能用他们的列表(Lisp)和对象(Smalltalk)来解决问题,Perl恰恰相反。Larry说过:“Unix和字符串处理才是王道”。

对大部分任务来说,他说的完全正确。因此Perl在和Unix的集成、字符串处理两个方面上无人能敌。除了另外一个最近才走上舞台的语言,来自哥斯拉的诞生地。后面我再细说这门语言。

可惜Larry过于看中与Unix集成和字符串处理,结果完全忽视了列表和对象,结果等到要想实现这些的时候都已经太晚了。实际上,早期在Perl的肚子里面…貌似用“设计”这个词说内脏不合适,暂时就叫做Perl的生命周期吧,Larry犯了几个关键错误。结果如果你想要在Perl中使用列表和对象,就必须化简为繁,花费很多额外的精力。

列表和对象也是很重要的Larry亲!

Perl之所以没办法处理列表,那是因为Larry早期犯了个没救的错误:Perl会将列表全部抹平。所以(1, 2, (3, 4))会奇怪的变成(1, 2, 3, 4),这样的结果你还能用么。当时这么做是因为Larry恰好为了解决一些问题图方便这么设计,但是从此Perl的数据结构就像爆炸的鲸鱼那样变成一滩了。

现在如果要读有关Perl的书、教材或者是PPT,你都得花三分之一的时间学习何为“引用”,这都是因为对Larry当年抹平列表的疯狂决定的蛋疼的化简为繁的修正。但是Perl的营销干的太漂亮了,搞得好像引用恰好是你遇到的最好的事情。任何东西的引用你都可以得到,有意思吧,闻起来也还不错呢。

Perl无法处理对象那是因为Larry就一直不怎么鸟它。不过这也没什么,我自己现在不也搞不懂我自己到底相信不相信对象么。为何Larry又非得加上他们呢?Perl的面向对象就是个半成品,社区里面也没人关注。OO就是没有字符串处理和Unix集成那样充满创造力。

当然,Perl还有一堆脑残的设计。比如说他的”上下文“,这就Larry的搞笑决定的可怕产物:要有多个不同的名字空间。像shell脚本那样,由sigils来最后决定。在Perl里面,每个操作、函数的行为表现都是六种里面的某一个,具体是哪一个,要看当时的“上下文”。没有具体的规则和推断,你不知道在给定的一个上下文中,一个操作到底会是什么结果。你只能把所有的可能都记住。

可以举个例子:在标量的上下文里,去取hash的话,会给你一个字符串类型的分数,分子是分配的键值数目,分母是hash结构中桶的数目。像炸开的鲸鱼内脏吧,我没说错吧。

如我所言,到目前为止Perl处理问题的方法还是那么的奇葩,无人能出其右。

2.6 Ruby

大概每15年左右,更好的语言就会替代原来的语言。C被C++替代,起码在大型应用开发这一领域,人们都迫切希望在保持性能的同时有不错的数据结构可以用。C++被Java替代,Java在7年之内肯定也会被其他更好的语言替代,当然,这要从Java完成C++的替代才开始算起,而这个替代貌似也不太可能完全实现,因为微软不会让Java在桌面端满地开花。不过在server端的开发,C++基本已经没戏了。

Perl也快了,因为新语言Ruby已经完全的翻译成英文了。它是日本人发明的,你肯定和其他人一样感觉意外,因为日本一直都是以硬件和制造业闻名,而非软件开发。大家肯定都不明就里,我估计都是打字的问题,我就没法想象他们之前是怎么能很快的打字的,日文里面的字符可是有上万个啊。不过Emacs倒是在几年前支持了多字节字符,所以我估计现在他们打字要快得多了。(没错,他们也用Emacs,日本人还是Emacs多字节支持的主要贡献者,而且写出来的质量也是十分优秀。)

Ruby偷学了Perl所有好的方面。其实Matz,Ruby的作者(我没记错的话,应该叫做Yukihiro Matsumoto,但是外号“Matz”),觉得自己偷学的有点太多了,结果把一些Perl里面的鲸鱼内脏也弄过来了。不好还好就一点,不算多。

最重要的是,Ruby原封不动的拿来了Perl的字符串处理和Unix集成,语法都是一样的,所以毋庸赘言,这时已经拥有了Perl最好部分了。这就是个不错的开始,尤其是你别拿来Perl剩下的部分。

更进一步Matz从Lisp中拿来了最优秀的列表处理,还有从Smalltalk和其他的语言那里拿来了面向对象,还有CLU的最好的迭代器,还有几乎各种语言的最优秀的东西。

更不可思议的是Matz还成功的将他们结合在一起,平时使用你都不会觉得这是一个超级大杂烩。相比其他的三四十门语言,我学Ruby的时间是最短的。3天,我就可以用Ruby用得和Perl一样顺手了。语言的一致性保持的很好,可以根据已知的一部分内容预测其他的内容,大部分情况下你都是对的。语言十分优美、使用起来十分有趣,而且都很实用。

如果将语言比作自行车,那么Awk就是就是个有白色小框的粉色儿童车,把手上还有饰带。Perl就是个beach cruiser(当年还是很拉风的),Ruby则是一辆价值七千五百刀的钛合金山地自行车。从Perl跨入Ruby如同从C++跨入Java这么爽,还不带任何缺点的。Ruby差不多就是Perl功能的一个超级,而Java还是从C++里去掉一些人们会怀念的东西,而且还没提供任何可以替代的方法。

将来我会多写点Ruby的东西。但是首先需要在酝酿酝酿。读一读 Why the Lucky Stiff(译注:笔名就是这样子) 的 Why's (poignant) Guide to Ruby (译注:书名就是这样子)。这本书很有启发性。你们可以都去读一读,绝对惊喜。我是没法理解这货是怎么写出来这本书的,但是书还是很有趣的、很切题,而且内容写的都是Ruby,反正都有那么点关系。去看看吧。

2.7 Python

额,Python么,这些年来一直在等待着自己的机会。Python社区都是在Perl母体中勇敢吞下红药丸觉醒的人们的避难所。

其实他们有点像Smalltalk世界的人们,永远的等待着替代C++,不想半路杀出个Java轻轻松松搅了局,以后算是没希望了。问题是,一夜之间突然你就发现:Ruby就正在这么搅着Python的局。

Python本来还是有机会一统江湖的,奈何自己有两个致命缺陷:空格问题,社区冷清。

空格问题很简单,就是Python利用缩进在决定代码块。这样就强迫用户的缩进都可以保持一致的格式,所有人的代码风格就比较接近了。万万没想到,不少程序员不买帐。因为他们觉得自己的自由被剥夺了;就像Python践踏了宪法赋予他们的随意缩进以及代码全压在一行的权利3

Python的作者,Guido Van Rossum,早期也犯了几个比较二的技术错误,当然没有Larry的那么严重,但是确实有那么几个确实很二。比如,Python最初没有词法作用域,问题是,它也没有动态作用域。Python的作用域就两个,要么是全局的,要么是本地的(函数范围)。妈的,Python在如此情况下还能实现一个“真”的面向对象系统,类根本都无法获得自己的实例。所以你就得传入一个“self”参数到每个实例的方法上,然后通过它才能获得实例里面的数据。所以Python里面就是到处都是self满天飞,就算你不怎么在乎空格不空格的缩进问题,self的问题就可以让你摔键盘了。

其他,我就不黑了。

但是我还是觉得啊,弄死Python自己的还是社区反馈冷清。这成功的阻止了Python成为首选脚本语言的良好心愿的实现,还有成为各种首选XX语言的心愿。看看,大家现在还在用Tcl作为内嵌的解释器,TLC,除了,是吧,社区冷清这个问题。

你可能会问我说的冷清到底是个什么意思?原本之前我这里还是写了很多很多非常非常尖酸刻薄的吐槽的。但是想想,用起Python来体验也还是很不错的(只要你可以忽略它的各种问题),做人要厚道,所以就不再费笔墨吐槽所谓的Python风格编程了。关于“冷清”这个问题,就是他们有那么点,可以说是态度冷冰冰的。为什么呢?

因为他们已经因为空格的问题烦的不行了!

这就是我为什么会认为Python的流行度永远都不会达到Perl的水平。当然,也可能是我瞎说。

2.8 结尾

这就是我想写给ADJ的内容,也可能是比较类似的内容吧。不知道为什么,我的真实感受都是早上3-6点失眠的时候蹦出来。我要洗洗睡了,2小时后我还要开个会。

(2004.09发布,2006.03.28修改)

Footnotes:

1

Eric告诉我,他们一起在Lucid工作的时候,基本都是Jamie Zawinski在写。

2

自从我写了这篇文章后就多次被人指出其实人家Paul Graham用的是vi。好伤心。

3

说明下,我个人不在意空格的问题。因为这个原因不喜欢Python,我觉得是很傻的。我的意思是有不少 其他 的程序员不喜欢空格问题。