很難預測人們的生活在一百年后會是什么樣子，我們只能給很少的事物一個確切的預測。我們知道到那時候每個人都將駕駛氣墊轎車，地方法規將對建造上百層的高樓無所制約，大部分時間都將日月無光，女人們都將精通武術（martial arts）……在這里，讓我們把這幅圖景的一個細節放大來看看：那時候人們用什么編程語言來寫那些氣墊轎車的控制軟件呢？

這是一個值得思考的問題，其意義不在于我們一定要用這種語言，而是在于據此我們可以選擇可能發展成那種語言的語言——如果我們夠幸運的話。

我認為，語言就像物種一樣，會形成進化樹，沒有前途的分支將枯死脫落。我們已經看到了這種事情發生：Cobol——曾幾何時風光無限，現如今沒有一個像樣的后代，它就是在進化中被淘汰的“穴居人”語言。（譯注：穴居人是石器時代的歐洲大陸的主宰，大約3萬年前滅絕。穴居人又叫尼安德特人，其發聲系統不發達。）

我預測Java的氣數也跟這種語言差不多。有人不時發郵件跟我說：“你怎么能說Java不可能成為一種成功的語言呢？它現在已經是一種相當成功的語言了。”那么我承認這一點——如果你衡量成功的標準是關于Java的書籍（特別是個人著作）在書架上占去的空間的大小，或者是為了找工作不得不學習Java的大學生的數量的多少的話。我所說Java不可能成為一種成功的語言，意思是從物種進化的角度來看，Java將會走向窮途末路，就像Cobol一樣。

這只是一個猜想，我也許會猜錯。我在此的重點不是要討論Java，而是要提出進化樹的論點并引發人們來問自己：“X語言在進化樹上的什么位置？”之所以提出這個問題，不僅為了避免百年后去后悔，更主要是因為跟緊語言發展的主流對于當前選擇好的編程語言有積極的啟發意義。

假如你生活在舊石器時代，任何時候你大概都會因為自己“處在進化樹的主干上”（譯注：石器時代地球上生活著智人在內的多個人種，后來其他人種都滅絕了，只有智人在競爭中生存下來，成為現代人類的祖先）而感到無比幸福，雖然還有大量的穴居人——他們也是這個世界的居民，并且克魯馬努人（譯注：舊石器時代晚期在歐洲的高加索人種）不時會來襲擊你，還偷走你的食物。

因此我也想知道編程語言在一百年以后會是什么樣子，從而決定現在該把賭注押在哪個“樹枝”上。

編程語言的進化過程又不同于物種的進化過程，因為編程語言的分支可能會匯聚。譬如Fortran這個分支，似乎正在漸漸并入到Algol的后代中。理論上講這對于物種來說也是可能的，但是這種可能性很小，似乎從來就沒有發生過。

集中化對于語言的進化更有可能，部分原因是語言進化的走向空間比較小，還有部分原因是對語言的進化來說，突變不是隨機的。語言的設計者總會有意識地吸取其他語言的思想。

對于語言設計者來說，考慮一下編程語言的進化方向就特別有意義，因為他們可以據此把握好設計取向。在那種情況下，“處在進化樹的主干上”就不只是選擇一個好的語言了，而是從中得到啟發，以對語言的設計做出正確的決策。

任何編程語言都可以分為兩個部分：作為公理（axiom）的一個基本運算符（operator）集和語言的其他部分，其他部分原則上可以根據基本語素寫出來。我想基本語素集是一種語言在其漫長的生存期中最重要的部分了，而其他部分可能會改變。這就好比買一幢房子，原則上你應該首先考慮房子的地理位置，其他的任何因素你都可以調整，但是你不能調整位置。

我認為好的公理的選擇很重要，但是公理要盡量少，這一點同樣重要。數學家們對于這一點感受應該更深刻：公理越少越好。我認為也確實如此。

最近，人們仔細核查起編程語言的核心，看看是不是有什么“公理”是可以除去的，這已經成為一項有益的實踐。我發現在我長期的職業生涯里，自己經常像個笨蛋一樣，用垃圾堆積著垃圾（譯注：原文cruft breeds cruft，隨著軟件的發展，以及經歷了修改bug和更新的若干周期，它的部分代碼已不再使用但仍然保留在源碼中。這種代碼稱為cruft。 cruf可能是一兩行無用代碼或整個源文件模塊。由于很難識別cruft，去除cruft 往往很困難。）并且我發現同樣的事情在軟件里隨時隨地都在發生。

我有一個預感，軟件進化樹的主干會貫穿于某些編程語言中，這些語言有著最小、最干凈的“核”。一種語言越能用它自己來寫自己，就越好。

當然，在提出一百年后編程語言會是什么樣子的問題的時候，我做了一個很大的假設。一百年后我們還寫程序嗎？我們不是只需要告訴計算機我們希望他們做什么就可以了嗎？到現在為止，這方面還沒有大的進展。我想此后的一百年里，人們還是要通過現在這樣手工編寫的程序來告訴計算機去做什么。或許有的問題我們現在需要寫程序來解決，而一百年后這些問題不必再寫程序來解決，但是我想我們還是要面對很多我們今天編程所面臨的同樣的問題。

誰要說他能預測某一技術在一百年后將是什么樣子，我們都會覺得他在吹牛。但是不要忘記我們已經有了五十年的經驗，當我們反思過去的五十年里語言的進化是多么緩慢的時候，再來展望一下一百年后的情況就是一件可以理解的事。

語言進化緩慢，是因為它們并不是技術，語言只是符號。程序只是告訴計算機你要解決的問題的形式化的描述。編程語言的進化的速度并不像搬運或傳遞，倒更像數學符號的進化速度——數學符號也在進化，但是如你所見，卻不像它所支持的技術一樣有巨大而飛快的變化。

無論一百年后計算機是什么材料做的，可以很肯定地預測它將比現在運行更快。如果摩爾定律（Moor’s Law）繼續有效的話，它的速度將是現在的7,379億億（quintillion）（73,786,976,294,838,206,464）倍，這是難以想象的。不可否認，對于速度的預測摩爾定律很可能失效，任何事物如果每18個月就增長一倍的話，長到最后就很可能違背某些基本的極限。但是這不妨礙我們去相信計算機會比現在快得多，即使它最后只比現在快那么小小的一百萬倍，也會從本質上改變編程語言的基本規則。到那時候，那些當前被認為是運行速度緩慢、不能生成高效率生成碼的語言就會得到更多的空間。

固然有一些應用還將追求速度。因為我們用計算機解決的一些問題本身是由計算機引起的，比如你要處理的視頻圖像的速率依賴于另一臺產生視頻圖像的速率。另外還存在一些可以無限吃掉機時的問題，例如圖像描述、加密、仿真等。

如果一些應用逐漸降低對效率的要求，而另一些應用繼續要求占用最新的硬件能提供的所有速度。那么更快的計算機就意味著語言必須覆蓋一個更廣泛的效率范圍。我們已經看到了這種事的發生，一些用新近流行的語言來實現的程序如果用幾十年前的標準來衡量的話，那對機時的“浪費”是驚人的。

這不只是發生在編程語言上的一個現象，而是一個普遍的歷史趨勢。當技術更新換代了以后，后一代都能做前一代會認為是浪費的事情。三十年前的人肯定會覺得我們隨心所欲地打長途電話是件令人驚訝的事，一百年前的人們一定會更驚訝于從波士頓經過孟菲斯到達紐約的包裹一天就能送到。

我現在就可以告訴你，一百年后當我們有了更快的硬件以后那些新增的處理能力都做了些什么？它們都將被“浪費”掉！

我從計算機能力還很珍貴的時候開始學習編程。我還記得那時候從我的Basic程序中節省出所有能節省的空間以便裝入一個4K大小的TRS－80，在這個無止境的重復上我花費了很大的精力，把機器的能力發揮到極限，最終還是受不了這種低效。但是現在看來，我那時拼命節約機器資源的直覺是錯誤的——就如同一個從小受過貧窮的煎熬的人，連去看醫生這樣很重要的事情也不舍得花錢。

某些浪費固然是可恥的，譬如SUVs（譯注：Sport Utility Vehicle，運動型多功能轎車）就被證明是一種拙劣的產品，即使它載油量很大且不會產生污染。SUV之所以拙劣，是因為它為了解決一個拙劣的問題——怎么讓一輛小型貨車看上去更威猛。不過不是所有的浪費都是壞的。我們有證據來支持這一點，打長途電話的時候你不會繁瑣地一分鐘一分鐘地數時間，如果有足夠的資源，無論是打長途還是短途，你可能會覺得都是一樣的。

有好的浪費，也有不好的浪費。我對好的浪費感興趣，就是那種花更多的開銷，但是能獲得更簡單的設計。我們如何從浪費更新、更快的硬件的機時中獲取好處呢？

在這個計算機處理能力很弱的時代，對速度的渴求在我們心中早已根深蒂固，我們應該有意識地克服這種想法。在語言設計中，我們應該有意識地尋找一切機會，用執行效率來換取哪怕很小的使用便利性。

大多數數據結構都是由于速度的原因而存在。譬如，當今很多語言都既有字符串又有列表（list）。從語義上講，字符串是列表的一個子集——其元素為字符，因此你為什么需要一種單獨的數據類型呢？真的不需要。字符串的存在，只是因為效率的原因。但是這種用擾亂語言語義的手法來使程序運行更快的做法是沒有說服力的。語言中包含字符串類型就是一種不成熟的優化。

如果我們把語言的核心看成是一組公理集，那么只簡單地為了效率的好處而往這個公理集里面添加公理，卻不能增加語言的表達力的話，這種添加就是丑陋的。效率是很重要，但是我不認為那種獲取效率的方法是正確的。

我認為解決問題的正確方法是將程序的內涵與它的實現細節分離。不要既有列表又有字符串，只要有列表就夠了，如果有必要，可以通過某種方式給編譯器以建議，允許編譯器把字符串按照相鄰字節來存放。

既然速度在程序的絕大部分地方都無關緊要，那么你通常就不必為這種小事操心了，這一點隨著計算機速度越來越快，將越來越正確。

人們很少注意到程序的實現也應當使程序變得更有彈性。一個程序往往在編寫的過程中會發生需求變化，這是不可避免的，也是應當受到歡迎的。

“essay”（譯注：企圖；小品文）一詞源于法語的一個動詞“essayer”，意思是“嘗試”，也指為了“試圖”推演出某一結論而寫的東西。軟件也跟essay一樣，作者往往并不確知哪些才是他們真正要表達的東西，我認為一些最好的程序也是essay。

Lisp（譯注：一種表處理語言，用于處理包含有表格的數據的編程語言，被廣泛地運用于人工智能研究）黑客（hacker，譯注：黑客指掌握尖端電腦技術的人，而不是人們常說的網絡入侵者,下同）們已經了解到彈性數據結構的價值，我們傾向于在程序的第一個版本中用列表（list）來處理一切數據。這種最初的版本是如此驚人地低效，因為它有意地避免去想它到底要做什么的細節，就像——至少對我來說——是吃牛排的時候有意避免去想它來自哪里一樣。

一百年后程序員將需要什么語言？最可能是那種只需要最少的精力就寫出 “非常低效”的“第一版程序”就搞定問題的語言。至少，我們目前可以如此描述這種語言。而用他們的話說，他們需要一種容易編程的語言。

低效的軟件不是拙劣的，真正拙劣的是使程序員做不必要的工作的語言。浪費機器時間不是低效，浪費程序員的時間才是真正的低效。這個道理隨著計算機越來越快，也將會越來越明白。

我想去掉字符串（string）這種數據結構已經指日可待了。我們在Arc（譯注：Lisp的一種方言）中就已經是這么做的，而且成功了。一些用正則表達式描述起來相當拙劣的操作，在Arc中用遞歸函數就很容易描述了。

像這種扁平的數據結構還能存在多久？我審慎而全面地思考了各種可能性，結果連我都大吃一驚。譬如，我們將會放棄數組嗎？畢竟，數組只是一種以整數向量為鍵值的哈希表（hash table），而我們會連哈希表都用列表來取代嗎？

有的預測甚至比這個更駭人聽聞。譬如McCarthy在1960就描述過的Lisp語言中連數字（number）都沒有。邏輯上講，你并不一定需要一個關于數字的單獨的符號，因為你可以用列表來表示數字，整數n可以用一個n個元素的列表來表示，你可以用這種方式進行數學計算。只不過這樣不堪其低效。

現實中沒有人被建議用列表來實現數字操作，事實上McCarthy在1960年的論文在那時也根本沒有指望被實現。那只是一項理論探討，只是嘗試給圖靈機（Turing Machine）創造一種優雅的替代。出人意料的是，有人卻根據那篇文章做出了一個可工作的Lisp解釋器。不過數字不是用列表來表示，而是跟其他語言里一樣，用二進制的方式來表示的。

編程語言會發展到去掉數字這種基本數據類型的程度嗎？我這么問不是信口開河地制造聳人聽聞的未來問題。情況就如同無堅不摧的矛遇到了無所不克的盾——在這里是無比低效的代碼遇到了無比豐富的硬件資源。我認為這完全有可能，因為未來還相當長。如果某種做法可以減少語言的核心公理的數目，那么它隨著時光飛逝會越來越值得“下注”。如果某種想法在一百年后依然是荒唐的，在一千年后或許未必荒唐。

必須聲明，我并不是建議所有的數值計算統統用列表來實現。我只是建議語言在沒有為應用而增加任何額外的符號之前的核心部分這樣來定義。實際上任何需要數學計算的程序大多會用二進制來表示數字，但是這只是一個優化，并在語言的核心語義范圍中。

另外應用程序和硬件之間軟件的多層次性也消耗了很多計算機機時。這也是我們已經看到的發展趨勢：許多軟件只是被編譯成字節碼，運行在字節碼解釋器上。Bill Woods曾經告訴我，每一層解釋器大概最起碼要消耗10％的速度，這些額外的開銷換來的是你程序的彈性。

Arc的最初版本就是這種軟件分多層以獲取彈性的極端的例子。那是一個建立在Common Lisp上的經典的“元循環”（metacircular）解釋器，與McCarthy最初的Lisp論文中的eval函數（eval function）有一定的共同性。整個Arc只有200余行代碼，所以非常易于理解和修改。而我們所用的Common Lisp，即CLisp本身又運行在一個字節碼解釋器上。因此這里就存在兩層解釋器，其中一層（上面的那一層）是驚人的低效，但是Arc仍然能用。雖然我承認它用起來很勉強，但是畢竟能用。

在應用程序方面，把軟件分層是一項了不得的技術。自底向上編程意味著一層一層地寫程序，每一層作為“語言”供上一層使用。這種方式有利于生成小而靈活的程序，也是取得可復用性這座“圣杯”（holy grail）的最佳途徑——“語言”定義上的可復用性。在你寫某種類型的應用程序的時候，越是能把你的應用下壓到“語言”中，你的軟件的可復用性也就越高。

不知何故可復用性的思想在1980年代被牽扯到面向對象編程中，并且看來還沒有要把它解放出來的反對性的跡象。然而雖然某些面向對象軟件是可復用的，但是使程序可復用的并不是面向對象，而是它的自底向上特性。想想庫函數：它們可復用使因為它們是“語言”，無論它們是不是采用了面向對象的方法。

順便說一句，我并不是預測面向對象編程的滅亡。雖然我認為它不能給好的程序員更多的幫助，但是在某些專門的領域，一些大型組織還是離不開它。面向對象編程提供了一種可行的方式去獲得意大利面條式的代碼，它允許你把一系列代碼碎片拼合成程序。大型組織通常愿意用這種方式開發軟件，我認為一百年后情況也還是如此。

在我們談論未來的時候，最好也談談并行計算，因為那時候這種想法將成為現實。也就是說，并行計算看來一定會實現，無論你說那是什么時候。

未來能趕上并行計算嗎？人們近20年來都在說并行計算即將實現，可是它到如今也還沒有對編程產生實質影響。真的沒有影響嗎？芯片設計者們不得不考慮它，試圖寫在多CPU電腦上的系統軟件的人們也不得不考慮它。

真正的問題在于，并行化會在抽象的道路上走多遠?一百年后它會影響到應用軟件的程序員嗎？還是只是編譯器編寫者們才考慮它，而一般應用軟件的源代碼里看不見其蹤影？

很有可能的倒是大多數并行化的機會都會被浪費。這是我所作的關于我們所獲得大多數額外的計算能力將會被浪費的預測的一個特例。我認為，隨著將來硬件處理速度的巨大提升，并行化將不會很常用，除非你確實需要它。這表明我們一百年后的并行化（除了特定的應用以外）都不會是大規模的并行化。我認為對普通程序員來說，更可能是生成一些并行運行的子進程。

這就像在程序生命的晚期你改變一個數據結構的精確實現一樣，你只是在試圖優化它。“第一版程序”通常會忽略并行計算帶來的好書，就像忽略數據的精確表述帶來的好處一樣。

因此，除了某些特定的應用軟件以外，一百年內并行化將不會普遍在程序里使用。如果用了，將會是一種不成熟的優化。

一百年后將還存在多少種編程語言？最近似乎有大量新的編程語言出現。部分原因是更快的硬件允許程序員們在速度和便利性之間根據應用做出不同的折中。如果語言的增多是一個真實的趨勢，那么一百年后我們擁有的硬件只會增長這種趨勢。

不過也許一百年后只剩下幾種廣泛使用的語言。我這樣說，部分原因是我的樂觀：如果你真的干得好，你可能設計出某種語言，它既適合寫出 “慢而便利”的“第一版程序”，也可以在需要的時候通過給編譯器一些適當的優化建議，讓它產生非�？斓纳�成碼。因為我的樂觀，我還可以預測不管“可接受”的效率與“最高效”的效率之間的 “鴻溝”有多寬，一百年后程序員都將擁有合適的語言跨越它們。

隨著“鴻溝”的變寬，性能評測器（profiler）將會越來越重要�，F在軟件性能評測方面關注的太少了，許多人都還相信編寫出能產生快的生成碼的編譯器是讓程序運行更快的途徑。隨著“可接受性能”與“最優性能”之間的“鴻溝”的變寬，人們也越來越清楚獲得更快的應用軟件的正確途徑是要有一個從“可接受”到“最優”的指引，就是性能評測器。

當我說未來只會剩余幾種語言的時候，并不包括那些特定領域的“小語言”。我認為這些嵌入式語言是偉大的，我也希望它們能夠越來越多。但是我希望它們寫出來的東西能夠像薄薄的外皮一樣，讓用戶能夠看到下面更通用的語言。

誰來設計未來的語言呢？過去十年里一個最振奮人心的趨勢是Perl、Python、Ruby等開放源碼語言興起，黑客們接過了語言設計的任務。迄今為止結果雖然凌亂，但還算可嘉。例如，Perl里面就有一些極好的新穎的想法。雖然也有許多還很不足的地方，但是大家都在執著地努力。如果保持現在的轉變速度，天知道一百年后Perl會進化成一個什么樣的語言。

一般來講可實踐者也是傳授者（我認識一些最優秀的黑客都是教授），但是有許多領域傳授者卻不是實踐者，所謂“學術”一向以堂皇的職業等級欺騙視聽。在任何學術領域都有一些主題是被認可的而另外一些主題卻不是，不幸的是被認可的主題與不被認可的主題之間的區別往往在于它在研究論文中的描述聽起來多么有難度，而不是取得一個好的結果的意義有多么重要。像文藝作品就是一個明顯的例子，研究文藝作品的人很少說對作者哪怕有一丁點用處的話。

雖然在科學里情況要好一些，但是你可以做的事情很多，可以產生好的語言的事情卻很少，之間的重疊少得可憐。（Olin Shivers曾經痛批過這一點。）例如，數據類型的研究一直以來都是研究論文的不竭的題材源泉，但是對于靜態類型將要排除宏類型（我認為，如果沒有宏，將沒有哪種語言值得使用）的事卻不聞不問。

看當前語言發展趨勢，語言設計正在趨于被當作開源項目來開發而不是當作研究課題來做，而且開發者也正在趨于編寫應用程序的程序員而不是編譯器的編寫者。這是一個好的趨勢，我希望它繼續下去。

不像物理學——幾乎不可能預測它一百年后的樣子，我認為原則上是可能現在設計一種語言符合一百年后的用戶需要的。

可能的設計出那種語言的方式是僅憑你的意愿寫下程序，不用考慮是否有編譯器可以解釋它，也不用考慮是否有硬件能運行它。當你寫程序的時候你可以假想有無限的資源（我想我們現在應該可以想象得到一百年后有無限資源的情景）。

人們會憑意愿寫出什么樣的程序呢？應該是所需的最少的勞動。要徹底的最少：在你的思維還沒有被你現在習慣了的編程的語言影響的“前提”下所想到的所需的最少的勞動。不過你已經習慣了的編程語言的影響是如此的普遍深刻，以致于你不得不做出巨大的努力來克服它。你可以盡量想象一下我們這些懶鬼怎么去用最少的努力表達一個程序。事實上，因為我們所有的想法是如此受到我們的思維所用的語言的限制，所以程序的簡潔一點的表達都讓我們非常吃驚。你需要做的是發現和覺醒，不是自然而然地陷入其中。

一個有用的訣竅是用程序的長度來作為你編程勞動的多少的近似值——當然不是按字符來計算的長度，而是按獨立語法元素（基本上就是是解析樹的大小）來計算的長度。要說最短的程序就標志是你最少編程勞動也不完全準確，但是它作為一個簡潔性的指標是寥勝于無的。那么，語言設計的法則就變成了：看看一個程序并問一問，是否還有別的方法可以把程序寫得更短？

實際上，用不可想象的百年語言寫程序會根據你接近它的內核的程度不同其結果也有所不同。你可以現在就寫出排序程序，但是很難預測一百年后將需要什么樣的代碼庫（library），大概會出現許多新領域的代碼庫。譬如，如果到時候SETI@home(譯注：Search for Extra Terrestrial Intelligence at home,是由美國加州大學伯克利分校建立的一項旨在利用連入Internet的成千上萬臺計算機的閑置能力搜尋地外文明的巨大試驗)還有效，我們就將需要與外星人（alien）通信的代碼庫。當然前提是他們也足夠發達，也能用XML來溝通。

極端一點，我認為你今天就有可能設計出那種核心語言。有人可能會說，實際上它已經早在1958年（譯注：J.McCarthy于1958年提出了Lisp的想法，并于同年跟他的學生們一起進行最初的實現工作。）就被設計好了。

假設我們今天就可以用所謂百年語言，我們會用它來編程嗎？為了回答這個問題，讓我們回顧一下從前，如果我們當前所用的編程語言在1960年就可用，那時的人們會用它們嗎？

從各個方面來講，答案都是否定的。當今的語言是建立在1960年還不存在的一些基礎上的。例如，像Python這種語言中每行的縮進是很有意義的規定，但是這種規定在那時候的打印終端上是行不通的。這樣的問題暫且不說，試想一下，那時候的程序都是寫在紙上的，1960年代的程序員們會喜歡用我們今天所用的語言來寫程序么？

我認為還是會的。雖然對于那些已經把史前古老的語言根深蒂固地融入到他們對計算機程序的認識中的缺乏想象力的人來說，確實很難。（天哪！沒有指針方法那怎么操縱數據？沒有goto怎么實現流程圖？）但是我認為最聰明的程序員們將很自然地使用我們當今所用的大多數語言——如果他們當時有這些語言的話。

如果我們現在就擁有了百年語言，起碼它會產生偉大的偽代碼。用它來寫程序又會怎么樣呢？既然百年語言需要生成快的生成碼以適應某些應用，那么大概它應該也能生成足夠可接受的高效的生成碼來適應我們現在的硬件。只是我們或許不得不比一百年后的用戶要給出更多的優化建議，但那也是劃算的。

我們現在有了兩個觀念，如果你把他們結合起來，會產生有趣的可能性：（1）原則上講，百年語言是可以在今天被設計出來的；（2）這種語言如果今天已經存在，那么用它來編程應當是不錯的。當你看到像這樣明擺著的兩個觀念，就不難想到：為什么不現在就試著用百年語言來編程呢？

如果你是做語言設計工作的，我認為你最好有這種目標，并且把它牢記于心。當你學駕駛的時候，他們教給你的基本原則之一就是不要只是讓你的引擎蓋對準道路上的行道線，而是要把目光瞄準遠處。哪怕你只是在意下一個10英尺會發生的事，也應該這樣。我想我們在編程語言方面可以也應該這樣做。

Notes

我相信Lisp語言中的Machine Lisp是第一個將“聲明（動態變量除外）只是優化建議，而不會改變正確程序的意義”這一原理具體化的語言，而Common Lisp首次將其明確地闡釋了出來。

感謝Trevor Blackwell，Robert Morris 和Dan Giffin，他們閱讀了本文的初稿，感謝Guido van Rossum，Jeremy Hylton和Python社團的其他全體成員，是他們邀請我在Python大會上講話。