时间的女儿[转]

   我想，SICP是The Little Schemer（TLS）之后，一个不错的选择。TLS关注于Scheme最美的那个部分，而且在读者感到厌倦之前就结束了。相比之下，SICP要直到4.1章才讲Scheme解释器。我读TLS觉得有点味道了，并且能把TLS的程序调通，才决心去写写SICP上的code。如果让我一上来就读SICP，也许也会不知所云，不知道重点在哪里。
　　
　　SICP对读者的要求很高。比如，第一章可以称为“如何用Scheme解数学题”。而且这些数学也不简单，数值分析，数论，微积分，矩阵，信号分析等等，虽然说都是这些学科的初步知识，但对于想学Scheme但没有背景知识的读者来说有相当大的难度。理工科大学生要花四年时间在这些数学问题上，而且等他们毕业以后，能够记住，理解和真正应用的内容，可能还没有SICP里提到的多。如果让我在大学时，做SICP的题目，估计大部分都做不了，也看不懂。
　　
　　假设大多数读者从第一章开始读，线性地往下读，而且还要做些题目，平均阅读长度是多少，我很怀疑。我现在读到3.3章，几乎作了每道题（有170道了），开始觉得力不从心了。FP本身的难度要比C/C++语言编程难得多，尤其是那些higher function，虽然看起来漂亮的很，但要仔细想的话，简直是一些要人绞尽脑汁的技巧。你再去看看公司里的那些代码，要多dirty有多dirty，也没有人说不好，唉。
　　
　　 * * *
　　
　　顺便谈谈对Lisp/Scheme的感觉。
　　
　　我的第一感觉是，这一类语言必死无疑，它们和C语言这一类语言简直是两个极端。C语言是基于机器设计的，所以有大量诸如pointer，memory management的东西，可以说是dirty的很（也可以说hackable的很），把硬件底层的细节大多暴露给了用户。而Lisp是基于McCarthy的数学模型设计的，所以抽象的很，最怪的是把所有的函数都写成(f x y z ...)的形式，在这一点上倒是和汇编语言有点像。
　　
　　在这个Object-Oriented横行的年代，Functional Programming除了在传说中的多核（或者hardware level multi-threading）上有一点优势，还有symbol program和晦涩的call/cc和越来越不好用的macro，还有什么？这仅有的一些优势也会被FP天生的编程困难所抵消。在我熟悉的硬件语言领域（Hardware language），也有语言竞争的现象，结论是像/C++/Java的语言胜出，他们不一定多好，只是工程师熟悉这种模式罢了。绝大多数工程师是随大流的，所有功成名就的老板都是随大流的。再举一个熟悉的例子，Matlab和C比较像，而Mathmatica和Lisp几乎同宗，最后也是Matlab占领了大多数的工程市场，这个市场可要比学术界大许多。
　　
　　Scheme的用户应该都在大学里，而且可能只在Boston附近的那几个大学里，出了学校还有用户吗？谁会自讨没趣到用递归形式或者诸如map之类higher function的写循环？谁会用一个竟然没有name space的语言开发大型程序？谁会看一些满是学术用语，诸如lambda，continuation等晦涩关键词的程序？习惯了用满篇=赋值，能容忍没有这些好东西吗（Scheme有let，set!之类的东西，但远没有=好用）？Scheme的命运令人担忧，虽然有学术界的支持，但没有广大的群众基础。广大的开发人员需要的是“Dirty and Quick”的开发语言，有足够的，简单易懂的库，拿来就能用，他们才没有闲暇来欣赏什么“Beautiful Code”，“Elegent Language”，明天就是deadline，老板的脸色重要，还是代码漂亮重要，不言而喻。
　　
　　 * * *
　　
　　在Lisp大家族里，最有影响力的，也许不是Common Lisp，也不是Scheme，而是Elisp（Emacs Lisp），从用户群就可以看出来。我认识的许多和计算机打交道的朋友都会用Emacs，它上手也比vi简单。我原来用vi，现在用Emacs的vi mode。看看Emacs的配置文件，不知不觉中，就会学到一些Lisp的语法，如果本来懂一些编程知识，那就更没有问题了。
　　
　　事实表明，Emacs用户比VI用户更知道如何扩展editor，对它的原理也理解的更清楚（不包括redisplay之类的复杂算法）。在许多人的印象中，Emacs就像就像它的作者Richard Stallman（RMS，计算机名人堂中的重量级人物，许多hacker心目中的英雄）一样白发苍苍。我在用VIM的时候，也对Emacs不屑一顾。它甚至没有所有“现代流行”的editor都有的tab和dialog，GUI看起来像是70，80年代的老古董。但当我通过TLS和SICP熟悉Lisp这一类语言之后，我才开始阅读扩展Emacs，体会它的设计优点（当然，也许RMS在设计时并没有考虑这些）。举一个简单的例子，大多数的editor都会用one buffer one tab的模式，也就是每开一个文件，就对应一个buffer和tab。但当你开了超过20乃至30，40个文件之后，tab就开始失去它的作用了，也就是想要从tab来选择一个文件变得很困难。而Emacs有一些extension使得这种选择变得十分方便。
　　
　　Emacs和SICP一样，对初学者来说相当困难，并引起初学者的反感。具有讽刺意味的是，这种困难来源作者的一片好意，作者试图将整个系统透明化，告诉用户每一个Key Binding对应那个function，每一个mode对应了那些function re-binding，以及每一个function的实现细节和文档。这对于有经验的工程师是一笔巨大的财富（Emacs包含了上千个function和超过百万行Elisp代码，以及每个function包含的docstring），但对于初学者和熟悉商用IDE环境的用户，却是头痛的。对于习惯于被束缚在一种开发环境下的用户，透明，自由，灵活，反而无法习惯了（虽然我现在在伟大的WinXP下写这篇文章，但我还是要说，这些也是Microsoft这位Big Brother给我们带来副产品）。正是这些特点，使得工程师可以在Emacs下开发org-mode，gud，email/news client，而用vim的script（vim scirpt与elisp相比，可以说是10岁和30岁的差距），几乎完全可以肯定无法实现这些extension。
　　
　　世界上，采用Lisp和承认采用Lisp的公司不多。如Paul Graham所说，前者和后者不同。其一，大多数用户和股东只知道popular language，如果让他们知道公司竟然用不popular的language开发项目，一定会引起恐慌。其二，项目经理怕招不到Lisp programmer接班，他的恐惧是对的。其三，公司将Lisp作为秘密武器，放烟雾弹，让对手用popular language，自己悄悄用Lisp开发。
　　
　　所以，也许读过SICP，写过Scheme程序之后，再也没有机会在项目中写Lisp程序。项目所用的语言是由许多因素共同决定的，主要因素是随大流。然而，无法用自己喜欢并且投入大量精力学习的语言写程序，是一件令人遗憾的事。所以也许，能够更好地理解和使用Emacs才是学习SICP和Lisp的（可能是唯一的，不包括Autodesk用户）最实际的目的。
　　
　　
　　 * * *
　　
　　让我们回到1989年，那时Lisp工作站渐渐被PC取代，各种以写Lisp系统为生的公司不得不写起了C++系统。Gabriel（McCarthy的弟子，在Parallel Lisp方面有贡献）在自己创办的公司里与员工们闲聊时，哀叹“Worse is better”（其实他是想说Simpler is better，或者dirty and quick is better）。这句戏言预言了之后二十年Lisp的宿命，一方面，各种新语言从Lisp吸取养分，另一方面，Lisp本身的用户数量却激剧缩小。人们逐渐把Lisp称为计算机语言里的拉丁语，连许多学校在开发项目时也放弃用Lisp。大家都有一个疑问，Lisp这么强大，为什么没人用？就好像问，“这个女孩这么美，为什么没男朋友”，或者“战争与和平这么好，为什么没人读”一样。这样的问题没法回答。英谚云，真相是时间的女儿（Truth is the daughter of time）。究竟“Better is worse”还是“Better is better”？还要时间来作出评价。