谈lisp

The Lisp Curse ／Lisp魔咒

http://winestockwebdesign.com/Essays/Lisp_Curse.html 英文出处

http://www.soimort.org/posts/124/ 中文翻译的出处 谷幽

The power of Lisp is its own worst enemy.

Here's a thought experiment to prove it: Take two programming languages, neither of which are object-oriented. Your mission, if you choose to accept it, is to make them object-oriented, keeping them backward-compatible with the original languages, modulo some edge cases. Inserting any pair of programming languages into this thought experiment will show that this is easier with some languages than with others. That's the point of the thought experiment. Here's a trivial example: Intercal and Pascal.

Now make this thought experiment interesting: Imagine adding object orientation to the C and Scheme programming languages. Making Scheme object-oriented is a sophomore homework assignment. On the other hand, adding object orientation to C requires the programming chops of Bjarne Stroustrup.

The consequences of this divergence in needed talent and effort cause The Lisp Curse:

Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp.

Consider the case of Scheme, again. Since making Scheme object-oriented is so easy, many Scheme hackers have done so. More to the point, many individual Scheme hackers have done so. In the 1990s, this led to a veritable warehouse inventory list of object-oriented packages for the language. The Paradox of Choice, alone, guaranteed that none of them would become standard. Now that some Scheme implementations have their own object orientation facilities, it's not so bad. Nevertheless, the fact that many of these packages were the work of lone individuals led to problems which Olin Shivers wrote about in documenting the Scheme Shell, scsh.

Programs written by individual hackers tend to follow the scratch-an-itch model. These programs will solve the problem that the hacker, himself, is having without necessarily handling related parts of the problem which would make the program more useful to others. Furthermore, the program is sure to work on that lone hacker's own setup, but may not be portable to other Scheme implementations or to the same Scheme implementation on other platforms. Documentation may be lacking. Being essentially a project done in the hacker's copious free time, the program is liable to suffer should real-life responsibilities intrude on the hacker. As Olin Shivers noted, this means that these one-man-band projects tend to solve eighty-percent of the problem.

Dr. Mark Tarver's essay, The Bipolar Lisp Programmer, has an apt description of this phenomenon. He writes of these lone-wolf Lisp hackers and their

...inability to finish things off properly. The phrase 'throw-away design' is absolutely made for the BBM and it comes from the Lisp community. Lisp allows you to just chuck things off so easily, and it is easy to take this for granted. I saw this 10 years ago when looking for a GUI to my Lisp. No problem, there were 9 different offerings. The trouble was that none of the 9 were properly documented and none were bug free. Basically each person had implemented his own solution and it worked for him so that was fine. This is a BBM attitude; it works for me and I understand it. It is also the product of not needing or wanting anybody else's help to do something.

Once again, consider the C programming language in that thought experiment. Due to the difficulty of making C object oriented, only two serious attempts at the problem have made any traction: C++ and Objective-C. Objective-C is most popular on the Macintosh, while C++ rules everywhere else. That means that, for a given platform, the question of which object-oriented extension of C to use has already been answered definitively. That means that the object-orientated facilities for those languages have been documented, that integrated development environments are aware of them, that code libraries are compatible with them, and so forth.

Dr. Mark Tarver's essay on bipolar Lispers makes the point:

Now in contrast, the C/C++ approach is quite different. It's so damn hard to do anything with tweezers and glue that anything significant you do will be a real achievement. You want to document it. Also you're liable to need help in any C project of significant size; so you're liable to be social and work with others. You need to, just to get somewhere.

And all that, from the point of view of an employer, is attractive. Ten people who communicate, document things properly and work together are preferable to one BBM hacking Lisp who can only be replaced by another BBM (if you can find one) in the not unlikely event that he will, at some time, go down without being rebootable.

Therefore, those who already know C don't ask "What object system should I learn?" Instead, they use C++ or Objective-C depending on what their colleagues are using, then move on to "How do I use object-oriented feature X?" Answer: "Goog it and ye shall find."

Real Hackers, of course, have long known that object-oriented programming is not the panacea that its partisans have claimed. Real Hackers have moved on to more advanced concepts such as immutable data structures, type inferencing, lazy evaluation, monads, arrows, pattern matching, constraint-based programming, and so forth. Real Hackers have also known, for a while, that C and C++ are not appropriate for most programs that don't need to do arbitrary bit-fiddling. Nevertheless, the Lisp Curse still holds.

Some smug Lisp-lovers have surveyed the current crop of academic languages (Haskell, Ocaml, et cetera) and found them wanting, saying that any feature of theirs is either already present in Lisp or can be easily implemented — and improved upon — with Lisp macros. They're probably right.

Pity the Lisp hackers.

Dr. Mark Tarver — twice-quoted, above — wrote a dialect of Lisp called Qi. It is less than ten thousand lines of macros running atop Clisp. It implements most of the unique features of Haskell and OCaml. In some respects, Qi surpasses them. For instance, Qi's type inferencing engine is Turing complete. In a world where teams of talented academics were needed to write Haskell, one man, Dr. Tarver wrote Qi all by his lonesome.

Read that paragraph, again, and extrapolate.

Exercise for the reader: Imagine that a strong rivalry develops between Haskell and Common Lisp. What happens next?

Answer: The Lisp Curse kicks in. Every second or third serious Lisp hacker will roll his own implementation of lazy evaluation, functional purity, arrows, pattern matching, type inferencing, and the rest. Most of these projects will be lone-wolf operations. Thus, they will have eighty percent of the features that most people need (a different eighty percent in each case). They will be poorly documented. They will not be portable across Lisp systems. Some will show great promise before being abandoned while the project maintainer goes off to pay his bills. Several will beat Haskell along this or that dimension (again, a different one in each case), but their acceptance will be hampered by flame wars on the comp.lang.lisp Usenet group.

Endgame: A random old-time Lisp hacker's collection of macros will add up to an undocumented, unportable, bug-ridden implementation of 80% of Haskell because Lisp is more powerful than Haskell.

The moral of this story is that secondary and tertiary effects matter. Technology not only affects what we can do with respect to technological issues, it also affects our social behavior. This social behavior can loop back and affect the original technological issues under consideration.

Lisp is a painfully eloquent exemplar of this lesson. Lisp is so powerful, that it encourages individual independence to the point of bloody-mindedness. This independence has produced stunningly good innovation as in the Lisp Machine days. This same independence also hampers efforts to revive the "Lisp all the way down" systems of old; no "Lisp OS" project has gathered critical mass since the demise of Symbolics and LMI.

One result of these secondary and tertiary effects is that, even if Lisp is the most expressive language ever, such that it is theoretically impossible to make a more expressive language, Lispers will still have things to learn from other programming languages. The Smalltalk guys taught everyone — including Lisp hackers — a thing or two about object oriented programming. The Clean programming language and the Mozart/Oz combo may have a few surprises of their own.

The Lisp Curse does not contradict the maxim of Stanislav Datskovskiy: Employers much prefer that workers be fungible, rather than maximally productive. Too true. With great difficulty does anyone plumb the venality of the managerial class. However, the last lines of his essay are problematic. To wit:

As for the “free software” world, it eagerly opposes industrial dogmas in rhetoric but not at all in practice. No concept shunned by cube farm hells has ever gained real traction among the amateur masses.

In a footnote, he offers Linux as an example of this unwillingness to pursue different ideas. To be sure, he has a point when it comes to operating systems (the topmost comment, in particular, is infuriatingly obtuse). He does not have a point when it comes to programming languages. Python and Ruby were influenced by Lisp. Many of their fans express respect for Lisp and some of their interest has augmented the Lisp renaissance. With some justice, JavaScript has been described as "Scheme in C's clothing" despite originating in those cube farm hells.

Nevertheless, in spite of this influence, in both the corporate and open source worlds, Lisp still has only a fraction of the developer mind share which the current crop of advanced scripting languages have attracted. The closed-mindedness of MBA's cannot be the only explanation for this. The Lisp Curse has more explanatory power.

The free development environments available for Lisp further exemplify the Lisp Curse.

It's embarrassing to point this out, but it must be done. Forget about the Lisp Machine; we don't even have development systems that match what the average Smalltalk hacker takes for granted ("I've always felt Lisp is the superior language and Smalltalk is the superior environment." - Ramon Leon). Unless they pay thousands of dollars, Lisp hackers are still stuck with Emacs.

James Gosling, the author of the first Emacs that ran on Unix, has correctly pointed out that Emacs has not fundamentally changed in more than twenty years. This is because the Emacs maintainers are still layering code atop a design which was settled back when Emacs was a grad-student project at the MIT AI Lab, i.e., when Emacs development was still being indirectly financed by the national debt. A Slashdotter may object that Emacs is already quite capable and can do anything that any other development environment can do, only better. Those who have used Lisp Machines say otherwise.

So why don't the Lisp hackers put the Smalltalk guys in their proper place? Why don't they make a free development system that calls to mind some of the lost glories of the LispM, even if they can't reproduce another LispM?

The reason why this doesn't happen is because of the Lisp Curse. Large numbers of Lisp hackers would have to cooperate with each other. Look more closely: Large numbers of the kind of people who become Lisp hackers would have to cooperate with each other. And they would have to cooperate with each other on a design which was not already a given from the beginning. And there wouldn't be any external discipline, such as a venture capitalist or other corporate master, to keep them on track.

Every project has friction between members, disagreements, conflicts over style and philosophy. These social problems are counter-acted by the fact that no large project can be accomplished otherwise. "We must all hang together, or we will all hang separately." But the expressiveness of Lisp makes this countervailing force much weaker; one can always start one's own project. Thus, individual hackers decide that the trouble isn't worth it. So they either quit the project, or don't join the project to begin with. This is the Lisp Curse.

One could even hack Emacs to get something that's good enough. Thus, the Lisp Curse is the ally of Worse is Better.

The expressive power of Lisp has drawbacks. There is no such thing as a free lunch.

这篇文章的标题叫“The Lisp Curse”。

我给它加了一个副标题，叫“对Lisp的非技术性吐槽”。

毫无疑问，这是一篇非技术性质的文章，可是它也许比不少技术文章能更好地解释一些疑问。列举几个无聊的的命题：“为何世界上最好的编程语言没有获得它应有的地位”、“为何自底向上支撑着咱们我的计算机乃至整个网络的Unix / BSD / GNU / GTK+ / Qt / Linux / Apache / MySQL...不是用Lisp/Scheme写的”、“为何王垠批完Google批学术界却没作多少牛逼哄哄的项目”或者“为何说‘孤狼黑客’对开源软件的生态环境是有害的”……诸如此类。

顺便说一句，我最初是在@yukihiro_matz的推上看到这篇文章的分享的。所谓的“孤狼黑客”，并非指Matz和Van Rossum这些人——至少从Python和Ruby发布到社区的一刻起就再也不是了。

再补充一句，我相信无论是这篇文章的原做者仍是翻译君本人，都没有任何对Lisp社区不敬的意思——只是就一项事实陈述和复述某种观点而已。

好了，废话少说，如下是正文内容。

这篇文章是另外一次尝试，旨在解释Lisp语言在具有强大力量的同时、为什么Lisp社区却没法重现它们在“AI之冬”以前的辉煌。毫无疑问，即使在式微以后，Lisp语言仍然是各类奇思妙想的重要来源。这一事实，加之各类Lisp实现的优异架构，还有现在在长达十年以后Lisp的复兴、显示着那些Lisp拥护者们是多么须要为本身的得意之做找到一点优越感；尽管有这一切，他们却没能成功地把Lisp的力量转换成一场压倒性的技术革新。

在本文中，我将阐述这样一个论点：Lisp那极其强大的表达能力，其实是如何成为它缺少前进动力的致命诱因的。

Lisp的力量也是它自身最危险的天敌。

要证实这件事情，试想一个简单的思惟实验：选择两种非面向对象的程序语言。你的任务，若是你愿意接受的话，就是为它们提供面向对象编程范式的支持，而且保持它们与原语言向后兼容——排除一些边界状况之外。把任意两种语言放到这个思惟实验的设定当中，你会很容易发现一些语言较另外一些语言更容易完成任务。这正是这个思惟实验的要点。随手举个简单的例子：INTERCAL和Pascal。

如今让咱们把这个思惟实验变得更有说服力些。想象一下给C和Scheme添加面向对象的支持。让Scheme支持面向对象不过是个稍微费点脑筋的家庭做业。另外一方面，让C支持面向对象，你恐怕得有Bjarne Stroustrup的本事才能办到。

这种对于解决问题所需才能和努力程度上的分歧，形成了Lisp的魔咒：

Lisp是如此强大，以致于在其余编程语言中的技术问题，到了Lisp中变成了社会问题。

想想Scheme的情形吧。由于让Scheme支持面向对象是如此垂手可得，许多Scheme黑客都完成过这件事情，更准确地说，是许多独立的Scheme黑客都完成过。这就致使了在20世纪90年代，这个语言的面向对象支持包像工厂量产出来的库存清单同样数不胜数。想一想选择谬论就知道，没有哪个包可以成为正式的标准。现在某些Scheme实现已经有了它们本身的面向对象功能，这还不算太坏。尽管如此，那些五花八门的由不一样独立开发者开发出来的包所形成的问题，正如Olin Shivers在给Scheme Shell（scsh）写文档的时候所提到的同样。

独立黑客们写出来的程序基本上遵循“抓痒模型”。这些程序解决了写程序的黑客们本身关心的问题，可是却未必能很好地处理对于其余人来讲有用的部分功能。何况，虽然说这些程序无疑能够在这个黑客本身的环境配置上运行得很好，但却不必定能移植到其余的Scheme实现、甚至不一样平台上的同一Scheme实现上。文档可能会极度匮乏。从现实的角度讲，一个黑客用本身挤出来的空闲时间作出来的项目，固然也可能会由于黑客本身的现实生活问题而烂尾。正如Olin Shivers指出的那样，这些我的性质的项目更倾向于解决整个问题的百分之八十。

Mark Tarver博士的文章，The Bipolar Lisp Programmer（双面Lisp程序员），对这种现象有一个确切的表述。他写道，这些“孤狼”式的Lisp黑客以及他们：

……不能把事情恰当地作完收尾。所谓的“用过就扔设计”绝对和拉屎这件事儿没什么两样（注：原文如此），而它来源于Lisp社区。Lisp容许你如此有始无终地告终一件事，并且还让你问心无愧地这么去作。十年前，我有一次须要给个人Lisp程序写一个GUI。没问题，我找到了9个GUI库。麻烦在于这9个库没有一个拥有足够完整的文档，并且它们所有是bug充斥的。基本上，每一个人都实现了他们本身的一套解决方案，对于他们来讲能用就行。这是一种拉屎式的态度（注：原文如此）；反正我作到了，我消化它了。这一样也是无须在他人帮助下便可获得的产物。

那么再想想C语言在上述思惟实验中的情形吧。因为在C上面实现面向对象支持的困难程度，只有两个严肃的解决方案摆上了台面：C++，以及Objective-C。Objective-C在Mac上最为流行，而C++几乎统治了其余一切平台。这意味着，给定一个平台，如何让C支持面向对象的扩展几乎已经被惟一肯定了。这意味着这些语言的面向对象支持将拥有完善的文档，高度集成的IDE，和兼容性良好的库，等等。

Mark Tarver博士的文章说到这一点：

如今与之相反，C/C++的作事方式彻底不一样。用镊子和胶水一步步搭建成一个东西实在太他妈困难了，因此你所作的一切都是实实在在的成就。你想要为它好好地写些文档。你会在作一个规模可观的C语言项目时候须要他人的帮助；所以你也更加容易变得社会性、学会去与他人合做。你须要作到这些，由于你须要完成某件事情。

而所有的这些，从一个雇主的角度来说，是很是吸引人的。十个可以相互交流、写文档与团队协做的人显然会比一个像拉翔同样本身去hack些Lisp代码的人更有用，而这种翔的替代品只能是另外一坨翔，这些翔们随时均可能由于某些我的的问题、本身退出项目而丢下一个不可收拾的烂摊子。

因此说，那些懂C的人不会去纠结“我应该用哪一种面向对象系统？”相反，他们会去选择C++或者Objective-C，就像他们的同事所选择的同样，而后他们会提问“我该怎样使用面向对象的功能X？”答案很简单：“咕狗一下，你就知道。”

真正的黑客，固然早就知道面向对象并不是如它的拥趸们所宣称的那样是解决一切问题的灵丹妙药。真正的黑客已经在探寻更加高阶的概念，诸如不可变数据结构、类型推断、惰性求值、monad、arrow、模式匹配、约束编程，等等。真正的黑客也都知道，C/C++对于写大部分不须要进行任意位操做的程序来讲并不合适。尽管如此，Lisp的魔咒仍然存在。

一些沾沾自喜的Lisp发烧友，调研了当前学术界编程语言的硕果（Haskell、OCaml等等）后，发现它们所缺失的一些特性，要么就是已经在Lisp中存在、要么就是能够用Lisp很轻易地实现——而且能够改进——基于Lisp宏。他们也许是对的。

可是太惋惜了，Lisp黑客们。

Mark Tarver博士——在上面已经两次引用过——曾经设计过一个Lisp的方言，叫作Qi。它仅仅由少于一万行的宏组成，基于Clisp运行。它实现了绝大部分Haskell和OCaml所独有的特性。从某个方面来讲，Qi甚至超越了它们。举个例子说吧，Qi的类型推断引擎自己是图灵彻底的。在这样的一个由天才科学家组成的杰出团队才能开发出Haskell语言的世界中，Tarver博士，他彻底是一我的作出来了Qi。

再看一眼上面这段话。仔细想一想，是否是可怕极了。

给读者的习题：假想Haskell与Common Lisp之间发生了激烈的对抗，下一步将会发生什么？

答案：Lisp魔咒应验了。每两个或者三个Lisp黑客就会开发出一套属于本身的惰性求值、纯函数式、arrow、模式匹配、类型推断等等的实现。大部分这种项目都是孤狼式开发。于是，它们具有大部人所须要的80%功能（虽然这80%的定义会随状况不一样而各异）。它们的文档一般会不好。它们没法在不一样的Lisp系统上移植。有些项目可能起初信誓旦旦地会维护下去，直到开发者决定本身跑到别处赚钱去了，结果丢下一个没法收拾的烂摊子。有一些可能会在某种程度上多多少少地战胜Haskell，可是它的承认度会被comp.lang.lisp新闻组里面的口水战淹没。

故事的结局：任意一个传统的Lisp黑客的宏可以拼凑成一个文档匮乏的、不可移植的、bug充斥的80%的Haskell实现，仅仅由于Lisp是一种比Haskell表达力更增强大的语言。

这个故事的教育意义在于，次级效应和三级效应相当重要。技术不仅是影响咱们解决技术问题的方式，它也影响着咱们的社会行为。而社会行为会反馈并施加影响于咱们最初试图解决的技术问题。

Lisp是一个活生生的事例。Lisp是如此强大有力，它鼓励我的的、狂热的特立独行。在Lisp机器曾经盛极一时的年代，这种特立独行产生了举世瞩目的成果。但也正是一样的特立独行，阻碍了所谓“自底而上纯Lisp实现”的计算机系统的复苏；自Symbolics和LMI夭折以后，再也没有一个“Lisp操做系统”项目达到过值得使人关注的高度。

这些次级和三级效应的一个后果是，即便Lisp是有史以来最富于表达力的编程语言，以致于理论上几乎不可能创造出比它更具表达力的语言，Lisper们将仍然有许多从其余编程语言那里学习的东西。Smalltalk程序员们教会了每一个人——包括那些Lisp黑客们——多多少少一点关于面向对象的概念。Clean语言和Mozart/Oz也有着一些本身的奇特之处。

Lisp魔咒并不违背Stanislav Datskovskiy的至理名言：雇主们更喜欢能够被取代的雇员，而不是生产率最高的雇员。说得太实在了。你早该醒悟到那些管理学课程只是骗钱的把戏。然而，他这篇文章的最后几行彷佛存在问题。请看：

在“自由软件”的世界里，工业界教条仅仅是在口头上被激烈地批判，但却从未在实践中被反对过。那些“办公隔间地狱”里被惟恐避之不及的概念，一样也不曾在业余爱好者中间获得过青睐。

在脚注中，他将Linux做为一个拒绝追求新奇想法的实例。为了例证，他将操做系统做为本身的一个论点（下面评论的1L是SB）。他并无提到编程语言。Python和Ruby都受到了Lisp的影响。不少它们的饭表示了对Lisp的尊重，而他们的一些兴趣则促进了Lisp的复兴。公正地讲，JavaScript也曾被描述为“披着C外衣的Scheme”，尽管它诞生在那些办公隔间地狱中间。

即使有如此大的影响力，在工业和开源界里，Lisp也仅仅只吸引了一部分程序员的一部分注意力，而这也是拜最近脚本语言的兴起所赐。那些拿着MBA学位的高富帅码农们的思惟封闭并非惟一的缘由。“Lisp魔咒”自己能解释更多的事情。

提供给Lisp的、可用的自由开发环境能够做为“Lisp魔咒”的一个例证。

尽管说出来让人难堪，但必须得有人去作这件事情。忘掉Lisp机器吧；咱们甚至尚未一个能达到算得上Smalltalk黑客小康标准的开发环境（“我总赶脚到Lisp是一个牛逼的语言，而Smalltalk是一个牛逼的环境。”——Ramon Leon如是说）。除非他们愿意付上千刀美圆，不然Lisp黑客们仍然会受制于Emacs。（翻译君：比肾还贵的LispWorks，包邮哦亲，欲购从速哦）

James Gosling，第一个在Unix上运行的Emacs的做者，恰当地指出了Emacs已经长达二十年没有任何基础上的变更。这是由于，Emacs维护者们只是不断地在这个当年由一个MIT的AI实验室的研究生作的设计上垒代码，那时Emacs项目仍然间接地从国债那里得到资助。也许Slashdot喷子会反驳说Emacs已经无所不能，它能够完成其它任何开发环境所能作的事情，并且只会完成得更好。否则那些当年曾经用过Lisp机器的也要这么说。

那么，为何Lisp黑客们没有把那些Smalltalk家伙们给完全战胜呢？为何他们没有作出一个自由的开发环境，能够从某种程度上唤回Lisp机器曾经的辉煌，即便他们不可以重现出另外一个Lisp机器？

这件事没有发生的缘由来自于Lisp魔咒。大量的Lisp黑客应该去协做。说得更详细些：大量成为Lisp黑客的人们应该去协做。并且他们应该学会合做去作一个新的设计、而非听从一个从一开始就写死了的现有设计。这过程当中不该该有任何来自外界的压力，例如风险资本家或者企业雇主，来干涉他们作事的方式。

每一个项目都会存在参与者的分歧，诸如意见不合、风格或哲学上的冲突。若是这些社会性的问题持续下去，任何大的项目都没法完成，这就产生了一个让它们倾向于解决的副作用力。“要么咱们团结一心，要么咱们都会被吊死在同一棵树上”。而Lisp的强大表达能力削弱了这个副作用力；一我的总能够着手去自搞一套。这样，刚愎自用的黑客们认为不值得去应付观点分歧带来的麻烦；所以他们要么退出了合做项目，要么就干脆不参加已有的项目、而选择自力更生从头开始。这就是Lisp魔咒。

咱们甚至能够本身去hack Emacs，为了追求我的理念中所谓的“足够好”。因而乎，Lisp诅咒差很少就变成了“坏便是好（Worse is Better）”的同义词。