談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）」的同義詞。