百年語言(轉載)

Paul Graham 2003年4月

（本文出自2003年Python大會上的一篇主題講話）

很難預測人們的生活在一百年後會是什麼樣子，咱們只能給不多的事物一個確切的預測。咱們知道到那時候每一個人都將駕駛氣墊轎車，地方法規將對建造上百層的高樓無所制約，大部分時間都將日月無光，女人們都將精通武術（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）將會愈來愈重要。如今軟件性能評測方面關注的太少了，許多人都還相信編寫出能產生快的生成碼的編譯器是讓程序運行更快的途徑。隨着 「可接受性能」與「最優性能」之間的「鴻溝」的變寬，人們也愈來愈清楚得到更快的應用軟件的正確途徑是要有一個從「可接受」到「最優」的指引，就是性能評測器。

當我說將來只會剩餘幾種語言的時候，並不包括那些特定領域的「小語言」。我認爲這些嵌入式語言是偉大的，我也但願它們可以愈來愈多。可是我但願它們寫出來的東西可以像薄薄的外皮同樣，讓用戶可以看到下面更通用的語言。

誰來設計將來的語言呢？過去十年裏一個最振奮人心的趨勢是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大會上講話。