python perl lisp_巴别塔-程式設計語言之旅【轉】——C、C++、Lisp、Java、Perl、Ruby、Python核心比較...

譯者：qinjian623原文作者：Steve Yegge

說明

但是由于文章内容比較和我胃口，還是決定再翻譯一個版本。

巴别塔

這是我自己混亂的程式設計語言之旅，原本準備這個月寫給ADJ(Amazon Developers Journal)，但是實在寫的不像樣，拿不出手。

首先，就是文章寫的比較糙，自己吐槽起來也沒個度，是以沒法當作所謂的官樣文章了。于是我就隻能把這玩意放我的blog上了，反正也沒人讀，是吧。除了你麼，沒錯，專為你私人定制，親。

另外，也沒有完全的完成。隻是這寫寫那寫寫，沒怎麼潤色。這麼來看，放blog上也合适。不用注意文筆，也不用非得寫的完整。就是我目前能想到的内容。親，請過目。我的程式設計語言的經曆比較雜哈，包括C、C++、Lisp、Java、Perl(以上這些都是我們在AMZ用的)，Ruby(我個人愛好)，還有Python，這個麼，後面會說，現在不急。

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寫東西的，而且數量龐大。要記住這點。

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++超牛逼，宇宙第一真理。就這樣忘了我說的話吧，就這樣。

Lisp

(下面的内容絕對歎為觀止，前面你也看了這麼多了，放心，後面更精彩)

Amazon剛開始的時候，我們有超牛逼的工程師。雖然我不都認識吧，但是還是了解那麼幾個的。

要例子？ Shel Kaphan, 牛逼閃閃。 Greg Linden，爆瞎你的眼。Eric Benson，來我司前就光芒耀眼了，不戴墨鏡不行了吧。

他們寫了Obidos web伺服器，而Obidos則成就了Amazon。那些年，還是堆屎山的工程師和web開發(大部分都是前端，嚴格按照日程表産出垃圾，當然，他們的經 理倒是很開心)來之前。那些年，Obidos還沒有被這群人玷污。雖然後來有點堵河道的意思(譯注：Obidos位于亞馬遜河最窄水流最快的位置)，但是 它還是Amazon初期獲得成功的重要基石。

最初的牛逼閃閃的兄弟姐妹都隻允許兩種語言存在于Amazon神聖的代碼庫裡，那就是C和Lisp。

你們可能有些不相信。

他們全都用Emacs，那是必然的。Eric Benson自己就是XEmacs

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們才是。

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。看起來有點武斷是吧，放心，看療效吧。

Perl

Perl，不怎麼好說啊。

老朋友了，回想起來，我在1995年就開始寫Perl了。快10年了，我用着也還不錯。就像你當年騎的大二八，總是那麼有點感情的。等你換了倆更好更舒服的自行車，還是會懷念它。Perl流行的原因就是以下三點：

可以很快的解決手上的問題，而往往時間就是金錢。

Perl的營銷是最好的。Perl的營銷都可以專門拿出來寫本書了。Sun拿錢砸出來的Java。Perl就純粹靠着Larry Wall和他那幫小兄弟的天才營銷一直緊跟着Java的勢頭。哈佛商學院的人就該好好研究研究人家的營銷，絕對歎為觀止。

哪怕到最近，準确說是到現在，也都沒有競争對手。

比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處理問題的方法還是那麼的奇葩，無人能出其右。

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，反正都有那麼點關系。去看看吧。

Python

額，Python麼，這些年來一直在等待着自己的機會。Python社群都是在Perl母體中勇敢吞下紅藥丸覺醒的人們的避難所。

其實他們有點像Smalltalk世界的人們，永遠的等待着替代C++，不想半路殺出個Java輕輕松松攪了局，以後算是沒希望了。問題是，一夜之間突然你就發現：Ruby就正在這麼攪着Python的局。

Python本來還是有機會一統江湖的，奈何自己有兩個緻命缺陷：空格問題，社群冷清。

空格問題很簡單，就是Python利用縮進在決定代碼塊。這樣就強迫使用者的縮進都可以保持一緻的格式，所有人的代碼風格就比較接近了。萬萬沒想到，不少程式員不買帳。因為他們覺得自己的自由被剝奪了；就像Python踐踏了憲法賦予他們的随意縮進以及代碼全壓在一行的權利

Python的作者，Guido Van Rossum，早期也犯了幾個比較二的技術錯誤，當然沒有Larry的那麼嚴重，但是确實有那麼幾個确實很二。比如，Python最初沒有詞法作用域，問 題是，它也沒有動态作用域。Python的作用域就兩個，要麼是全局的，要麼是本地的(函數範圍)。媽的，Python在如此情況下還能實作一個“真”的 面向對象系統，類根本都無法獲得自己的執行個體。是以你就得傳入一個“self”參數到每個執行個體的方法上，然後通過它才能獲得執行個體裡面的資料。是以 Python裡面就是到處都是self滿天飛，就算你不怎麼在乎空格不空格的縮進問題，self的問題就可以讓你摔鍵盤了。

其他，我就不黑了。

但是我還是覺得啊，弄死Python自己的還是社群回報冷清。這成功的阻止了Python成為首選腳本語言的良好心願的實作，還有成為各種首選XX語言的心願。看看，大家現在還在用Tcl作為内嵌的解釋器，TLC，除了，是吧，社群冷清這個問題。

你可能會問我說的冷清到底是個什麼意思？原本之前我這裡還是寫了很多很多非常非常尖酸刻薄的吐槽的。但是想想，用起Python來體驗也還是很不錯的(隻 要你可以忽略它的各種問題)，做人要厚道，是以就不再費筆墨吐槽所謂的Python風格程式設計了。關于“冷清”這個問題，就是他們有那麼點，可以說是态度冷 冰冰的。為什麼呢？

因為他們已經因為空格的問題煩的不行了！

這就是我為什麼會認為Python的流行度永遠都不會達到Perl的水準。當然，也可能是我瞎說。

結尾

這就是我想寫給ADJ的内容，也可能是比較類似的内容吧。不知道為什麼，我的真實感受都是早上3-6點失眠的時候蹦出來。我要洗洗睡了，2小時後我還要開個會。

(2004.09釋出，2006.03.28修改)

Footnotes:

Eric告訴我，他們一起在Lucid工作的時候，基本都是Jamie Zawinski在寫。

自從我寫了這篇文章後就多次被人指出其實人家Paul Graham用的是vi。好傷心。

說明下，我個人不在意空格的問題。因為這個原因不喜歡Python，我覺得是很傻的。我的意思是有不少其他的程式員不喜歡空格問題。