Choose Right Programming Languages

一度,我只会一种程序设计语言,就是C++,而且直到现在,我也不认为自己会用C(因为真的没写过什么程序),只是知道一点语法而已。

现在,我会了一点Perl,又开始学习Emacs Lisp,并且打算再学习几种语言,多掌握几件趁手的兵器。程序设计语言就像是木匠工具箱里的工具,只有配合起来用才能做出像样的活计,只会用锤子的人也就能去钉钉子。Tour de Babel是一位前Amazon员工写的文章,谈了他对几种流行的程序设计语言的看法,颇具参考价值。值得注意的是,其中C++一节几乎全是负面评价,但我却感觉每句话都说在理上,下面这段话就引自这一节:

An Amazon engineer once described our code base as “a huge mountain of poop, the biggest mountain you’ve ever seen, and your job is to crawl into the very center of it, every time you need to fix something.”

另外,他对Perl的评价与我自己的感受很类似;而我也就是因为不喜欢Python那种使用空格的方式所以一直没有去学。现在看来,Ruby应该是我下一个准备学习的语言了。

说到选择合适的语言,不禁想起不久前看到的一篇文章——”Top Ten of Programming Advice to NOT follow“,其中第一条就是关于exception的,看了大呼过瘾。有一段时间特别想看一些开源软件的代码,尤其是C++写成的,但是看过几个之后发现,基本都会禁止使用exception(以及其它几个特性),甚至包括Firefox。当时感觉很郁闷,为什么要阉割一种语言,难道就没有一种语言恰好够用吗?如果没有,难道就不能发明出一个?

诚然,选择也要有选择的余地,能发明程序设计语言的毕竟是少数,只能在现有条件下做出最好的选择,几乎不会有人像Donald Knuth那样因为不喜欢人家的排版就自己写一套排版系统,这恐怕也是程序设计行业越来越平民化之后所面临的挑战——到底还有没有人愿意做精英。

Emacs Lisp Macros

断断续续地在看Emacs Lisp Reference Manual,卡在Macros一节下不去了,把Macros、Byte Compilation和Evaluation三节反反复复看了好几遍,终于弄明白了,原来此Macro非彼Macro,和C里面的宏完全是两码事。

Emacs Lisp里的Macro实际上是Code Generator,和C里面的文本替换完全不同,即Emacs Lisp Macro是一段可以执行的Lisp程序,其执行结果并非是一般的值,而是另一段可以执行的Lisp程序。所以,一个宏调用实际上包含两段Emacs Lisp程序的执行过程,首先调用宏,生成一段新的Lisp程序,再来执行这段新生成的代码。第一个阶段就是所谓的宏替换,Byte Compilation则只做第一阶段,而不去执行新生成的代码。

说穿了不过是一层窗户纸,可不明白的时候才叫郁闷呢。所以说,如果质量可以保证的话,有人教要比自己看书效率高的多,因为可以交互,不懂就问,而写书的人只能猜测读者的问题,比如我在这里就把我觉得容易忽略的词用了粗体,这些词正是我在读Emacs Lisp Reference Manual时忽略的。

说到这再跑两句题。最近在看苏福忠著的《译事余墨》,其中谈到英译汉的主要问题在于是否弄懂原文的意思,很可能一字一句都有玄机,稍有疏忽就会“差之毫厘、谬以千里”。联系到自己学Emacs Lisp Macro这么费劲,问题也全出在阅读理解上,这才意识到自己这点英语水平还远远不够,与其每次都浪费时间反复阅读,不如索性下点苦功夫提高英文水平。自从过了六级就没再认真学过英语,这回又有动力了。