一百年後，人類怎樣程式設計？

　　很難預測一百年後的人類生活，只有少數幾件事是可以確定的。那時，汽車將具備低空飛行能力，城市規劃的法規將放寬，大樓可以造到幾百層，大街上一天到晚看不見太陽，女性個個都學過防身術。本文只想討論其中的一個細節：一百年後，人們使用什麼語言開發軟體？

 

　　為什麼這個問題值得思考？原因不是我們最終會用上這些語言，而是幸運的話，我們從現在開始就能用上這些語言。

　　

　　我認為，程式語言就像生物物種一樣，存在一個進化的脈絡，許許多多分支最終都會成為進化的死衚衕。這種現象已經發生了。 Cobol語言曾經流行一時，但是現在看來沒有任何後續語言繼承它的思想。它就像尼安德特人 一樣，進化之路已經走到了盡頭。

　　我預言 Java也會如此。有人寫信說：“你怎麼能說 Java不會成功呢？它已經成功了。”我覺得這要看你的成功標準是什麼。如果標準是相關書籍的出版量，或者是相信學會 Java就能找到工作的大學生數量，那麼 Java確實已經成功了。當我說 Java不會成功時，我的意思是它和 Cobol一樣，進化之路已經走到了盡頭。

　　這只是我的猜測，未必正確。這裡的重點不是看衰 Java，而是提出程式語言存在一個進化的脈絡，從而引導讀者思考，在整個進化過程中，某一種語言的位置到底在哪裡？之所以要問這個問題，不是為了一百年後讓後人感嘆我們曾經如此英明，而是為了找到進化的主幹。它會啟發我們去選擇那些靠近主幹的語言，這樣對當前的程式設計最有利。

　　無論何時，選擇進化的主幹可能都是最佳方案。要是你不幸選錯了，變成了一個尼安德特人，那就太糟了。你的對手克魯馬努人時不時就會來攻打你，把你的食物全部偷走。

　　這就是我想找出一百年後的程式語言的原因。我不願意押錯賭注。

　　

　　程式語言的進化與生物學進化還是有區別的，因為不同分支的語言會發生聚合。比如， Fortran分支看來正在與 Algol 的繼承者聚合。理論上，不同的生物物種也可能發生聚合，但是可能性很低，所以大概從來沒有真正出現過。

　　程式語言之所以可能出現聚合，一個原因是它的概率空間 比較小，另一個原因是它的突變不是隨機的。語言的設計者們總是有意識地借鑑其他語言的設計思想。

　　對於語言設計者來說，認清程式語言的進化路徑特別有用，因為這樣就可以照著樣子設計語言了。這時，認清進化的主幹就不僅有助於識別現存的優秀語言，還可以把它當作設計語言的指南。

　　

　　任何一種程式語言都可以分成兩大組成部分：基本運算子的集合（扮演公理的角色）以及除運算子以外的其他部分（原則上，這個部分可以用基本運算子表達出來）。

　　我認為，基本運算子是一種語言能否長期存在的最重要因素。其他因素都不是決定性的。這有點像買房子的時候你應該先考慮地理位置。別的地方將來出問題都有辦法彌補，但是地理位置是沒法變的。

　　慎重選擇公理還不夠，還必須控制它的規模。數學家總是覺得公理越少越好，我覺得他們說到了點子上。

　　你仔細審視一種語言的核心，考慮哪些部分可以被摒棄，這至少也是一種很有用的訓練。在長期的職業生涯中，我發現冗餘的程式碼會導致更多冗餘的程式碼，不僅軟體如此，而且像我這樣性格懶散的人，我發現在床底下和房間的角落裡這個命題也成立，一件垃圾會產生更多的垃圾。

　　我的判斷是，那些核心最小、最乾淨的程式語言才會存在於進化的主幹上。一種語言的核心設計得越小、越乾淨，它的生命力就越頑強。

　　

　　當然，猜測一百年後人們使用什麼程式語言，這本身就是一個很大的假設。也許一百年後人類已經不程式設計了，或者直接告訴計算機想做什麼，計算機就會自動完成。

　　不過，到目前為止，計算機智慧並沒有取得太大進展。我猜測一百年後，人們還是使用與現在差不多的程式指揮計算機。可能有一些我們今天需要程式設計解決的問題，那時已經不需要程式設計了，但是我想，那時還會存在大量與今天一樣的程式設計任務。

　　你可能認為只有那些自以為是的人才會去預言一百年後的技術。但是，請不要忘記，軟體發展的歷史已經走過了 50年。在這 50年中，程式語言的進化其實是非常緩慢的，因此展望一百年後的語言並不是虛無縹緲的想法。

　 　程式語言進化緩慢的原因在於它們並不是真正的技術。語言只是一種書寫法，而程式則是一種嚴格符合規則的描述，以書面形式記錄計算機應該如何解決你的問 題。所以，程式語言的進化速度更像數學符號的進化速度，而不像真正的技術（比如交通或通訊技術）的進化速度。數學符號的進化是緩慢的漸變式變化，而不是真 正技術的那種跳躍式發展。

　　

　　無論一百年後的計算機是什麼樣子，我們基本上可以斷定它們的執行速度一定會快得多。如果摩爾定律依然成立，一百年後計算機的執行速度將是現在的 74乘以 10的 18次方倍（準確地說是 73 786 976 294 838 206 464倍）。真是讓人難以想象。不過實際上更現實的預測並不是速度會提高這麼多，而是摩爾定律最終將不成立。不管是什麼東西，如果每 18個月就增長一倍，那麼最後很可能會達到極限。但那時的計算機比現在快得多大概是毫無疑問的。即使最後只是略微快了 100萬倍，也將實質性地改變程式設計的基本規則。如果其他條件不變，現在被認為執行速度慢的語言（即執行的效率不高）將來會有更大的發展空間。

　　那時，依然會有對執行速度要求很高的應用程式。我們希望計算機解決的有些問題其實是計算機本身引起的。比如，計算機處理視訊的速度取決於生成這些視訊的另一臺計算機。此外，還有一些問題本身就要求無限快的處理能力，比如影像渲染、加密 /解密、模擬運算等。

　 　既然在現實中一些應用程式本身的效率較低，而另一些應用程式會耗盡硬體提供的所有運算能力，那麼有了更快速的計算機就意味著程式語言不得不應付更多的極 端情況，涵蓋更大範圍的效率要求。我們已經看到這種情況發生了。要是以幾十年前的標準衡量，有一些使用新語言開發的熱門應用程式對硬體資源的浪費非常驚 人。

　　不僅程式語言有這種現象，這實際上是一種普遍的歷史趨勢。隨著技術的發展，每一代人都在做上一代人覺得很浪費的事情。 30年前的人要是看到我們今天如此隨意地使用長途電話，一定會感到震驚。 100年前的人要是看到一個普通的包裹竟然也能享受一天內從波士頓發件、途經孟菲斯、抵達紐約的待遇，恐怕就要更震驚了。

　　

　　我已經預測了，一旦未來硬體的效能大幅提高將會發生什麼事。新增加的運算能力都會被糟蹋掉。

　　在我學習程式設計的年代，計算機還是稀罕玩意。我記得當時使用的微機型號是 TRS-80，它的記憶體只有 4K，為了把 BASIC程 序裝入記憶體，我不得不把原始碼中的空格全部刪除。我一想到那些極其低效率的軟體，不斷重複某些愚蠢的運算，把硬體的計算能力全部佔用，就感到無法忍受。但 是，我的這種反應是錯的，我就像某個出身貧寒的窮孩子，一聽到要花錢就捨不得，即使把錢用在重要場合（比如去醫院看病）都覺得很難接受。

　　某些浪費確實令人厭惡。比如有人就很討厭 SUV（運動型多用途車），即使它採用可再生的清潔能源也改變不了看法，因為 SUV來自一個令人厭惡的想法（如何使得小貨車看上去更有男子漢氣概）。但是，並非所有的浪費都是壞的。既然如今的電信基礎設施已經如此發達，再掐著時間打長途電話就有點錙銖必較了。如果有足夠的資源，你可以將長途電話和本地電話視為同一件事，一切會變得更輕鬆。

　　浪費可以分成好的浪費和壞的浪費。我感興趣的是好的浪費，即用更多的錢得到更簡單的設計。所以，問題就變成了如何才能充分利用新硬體更強大的效能最有利地“浪費”它們？

　　對速度的追求是人類內心深處根深蒂固的慾望。當你看著計算機這個小玩意，就會不由自主地希望程式執行得越快越好，真的要下一番功夫才能把這種慾望剋制住。設計程式語言的時候，我們應該有意識地問自己，什麼時候可以放棄一些效能，換來一點點便利性的提高。

　　

　 　很多資料結構存在的原因都與計算機的速度有關。比如，今天的許多語言都同時有字串和列表。從語義上看，字串或多或少可以理解成列表的一個子集，其中 的每一個元素都是字元。那麼，為什麼還需要把字串單列為一種資料型別呢？完全可以不這麼做。只是為了提高效率，所以字串才會存在。但是，這種以加快運 行速度為目的、卻使得程式語言的語義大大複雜的行為，很不可取。程式語言設定字串似乎就是一個過早優化的例子。

　　如果我們把一種語言的核心設想為一些基本公理的集合，那麼僅僅為了提高效率就往核心新增多餘的公理，卻沒有帶來表達能力的提升，這肯定是一件很糟的事。沒錯，效率是很重要，但是我認為修改語言設計並不是提高效率的正確方法。

　　正確做法應該是將語言的語義與語言的實現予以分離。在語義上不需要同時存在列表和字串，單單列表就夠了。而在實現上做好編譯器優化，使它在必要時把字串作為連續位元組的形式處理。

　　對於大多數程式，速度不是最關鍵的因素，所以你通常不需要費心考慮這種硬體層面上的微觀管理。隨著計算機速度越來越快，這一點已經越發明顯了。

　　

　　語言設計時，對實現方式少作限制還會使得程式具備更大的靈活性。語言的規格發生變化不僅是無法避免的，也是合理的。通過編譯器的處理，按照以前規格開發的軟體就會照常執行，這就提供了靈活性。

　　 essay（論文）這個詞來自法語的動詞 essayer，意思是“試試看”。從這個原始意義來說，論文就是你寫一篇文章，試著搞清楚某件事。軟體也是如此。我覺得一些最好的軟體就像論文一樣，也就是說，當作者真正開始動手寫這些軟體的時候，他們其實不知道最後會寫出什麼結果。

　　 Lisp語 言的黑客早就明白資料結構靈活性的價值。我們寫程式的第一版時，往往會把所有事情都用列表的形式處理。所以，這些最初版本可能效率低下得驚人，你必須努力 剋制自己才能忍住不動手優化它們，這就好像吃牛排的時候必須努力剋制自己才能不去想牛排是從哪裡來的一樣，至少對我來說是這樣的。

　　一百年後的程式設計師最需要的程式語言就是可以讓你毫不費力地寫出程式第一版的程式語言，哪怕它的效率低下得驚人（至少按我們今天的眼光來看是如此）。他們會說，他們想要的就是很容易上手的程式語言。

　　效率低下的軟體並不等於很爛的軟體。一種讓程式設計師做無用功的語言才真正稱得上很爛。浪費程式設計師的時間而不是浪費機器的時間才是真正的無效率。隨著計算機速度越來越快，這會變得越來越明顯。

　　

　　我覺得，放棄字串型別已經是大家可以接受的想法了。 Arc語言已經這樣做了，看上去效果不錯。以前用正規表示式很難描述的一些操作，現在用迴歸函式可以表達得很簡單。

　　這種資料結構的扁平化趨勢會怎麼發展？我極其努力地設想各種可能，得到的結果甚至令我自己都嚇了一跳。比如，陣列會不會消失？畢竟陣列只是雜湊表的一個子集，其特點就是陣列的鍵全部都是整數向量。進一步說，雜湊表本身會不會被列表取代呢？

　　還有比這更驚人的預言。在邏輯上其實不需要對整數設定單獨的表示法，因為可以把它們也看作列表，整數 n可以用一個 n元素的列表表示。這一樣能完成數學運算，只是效率低得讓人無法忍受。

　 　程式語言會發展到放棄基本資料型別之一的整數這一步嗎？我這樣問並不是真的要你嚴肅思考這個問題，更多的是希望開啟你對未來的思路。我只是提出一種假想 的情況：如果一股不可抗拒的力量遇到了一個不可移動的物體，會發生什麼事。具體就本文而言：一種效率低得不可想象的語言遇到了效能強大得不可想象的硬體， 會發生什麼事。我看不出放棄整數型別有什麼不妥。未來相當漫長。如果我們想要減少語言核心中基本公理的數目，不妨把眼光放得遠一點，想一想如果時間變數 t趨向無限會怎麼樣。一百年是一個很好的參考指標，如果你覺得某個想法在一百年後仍然可能是難以令人接受，那麼也許一千年後它也依然難以令人接受。

　　讓我說清楚，我的意思不是說所有的整數運算都用列表來實現，而是說語言的核心（不涉及任何編譯器的實現）可以這樣定義。在現實中，任何進行數學運算的程式可能都是以二進位制形式表示數字，但是這屬於編譯器的優化，而不屬於語言核心語義的一部分。

　　

　　另一種消耗硬體效能的方法就是，在應用軟體與硬體之間設定很多的軟體層。這也是我們已經看到的一種趨勢，許多新興的語言就被編譯成位元組碼 。比爾•伍茲曾經對我說，根據經驗判斷，每增加一個解釋層，軟體的執行速度就會慢一個數量級。但是，多餘的軟體層可以讓程式設計靈活起來。

　　 Arc語言 最初的版本就是一個極端的例子，它的層很多，執行速度非常慢，但是確實帶來了相應的好處。 Arc是一個典型的“元迴圈”（ metacircular）直譯器，在 Common Lisp的基礎上開發，很像約翰•麥卡錫在他經典的 Lisp論文中定義的 eval函式。 Arc直譯器一共只有幾百行程式碼，所以很便於理解和修改。我們採用的 Common Lisp版本是 CLisp，它本身是在另一個位元組碼直譯器的基礎上開發的。所以，我們一共有兩層直譯器，最上面那層效率低下得驚人，但是語言本身是能用的。我承認只是勉強可用，但是確實能用。

　　

　　即使是應用程式，使用多層形式開發也是一種很強大的技巧。自下而上的程式設計方法意味著要把軟體分成好幾層，每一層都可以充當它上面那一層的開發語言。這種方法往往會產生更小、更靈活的程式。它也是通往軟體聖盃——可重用性（ reusability）——的最佳路線。從定義上看，語言就是可以重用的。在程式語言的幫助下，你的應用程式越是採用這種多層形式開發，它的可重用性就越好。

　　可重用性這個概念多多少少與 20世紀 80年 代興起的物件導向程式設計有些關聯。不管怎樣尋找證據，也不可能把這兩件事完全分開。某些使用物件導向程式設計開發出來的軟體確實具有可重用性，但是這不是因為它 使用了物件導向程式設計，而是因為它的開發方法是自下而上的。以函式庫為例，它們具有可重用性，是因為它們屬於語言的一部分，而不是因為它們採用物件導向或者 其他程式設計方法。

　　順便說一句，我不認為物件導向程式設計將 來會消亡。我覺得，除了某些特定的領域，這種程式設計方法其實沒有為優秀程式設計師帶來很多好處，但是它對大公司有不可抗拒的吸引力。物件導向程式設計使得你有辦法對 一團亂碼似的程式碼進行可持續性開發。通過不斷地打補丁，它讓你將軟體一步步做大。大公司總是傾向於採用這樣的方式開發軟體。我預計一百年後也是如此。

　　

　　既然是談論未來，最好談談平行計算（ parallel computation），因為看上去平行計算好像就是為未來而存在的。無論怎麼想，平行計算似乎都是未來生活的一部分。

　　它會在未來實現嗎？過去二十年，人們都在說平行計算馬上就會來臨。但是，到目前為止，它對程式設計實踐並沒有太大影響。這是真的嗎？晶片設計師已經不得不把它考慮在內，為多 CPU計算機開發系統軟體的程式設計師也是如此。

　　但是，真正的問題在於，平行計算到底能達到哪個抽象層次？一百年後它就會影響到開發應用軟體的程式設計師嗎？或者，它還只是編譯器作者需要考慮的事情，在應用軟體的程式碼中根本就無處尋覓？

　 　一種可能是，大多數可以用到平行計算的場合，人們都會放棄使用平行計算。雖然我總的預測是未來的軟體會揮霍掉大部分新增的硬體效能，但是平行計算是一個 特例。我估計隨著硬體效能得到驚人的提升，如果你明確地說想要平行計算，那麼肯定可以得到它，但是通常情況下你不會用到它。這意味著，除了一些特殊的應用 程式，一百年後的平行計算不會是那種大規模的平行計算（ massive parallelism）。我預料，對於普通程式設計師來說，一切更像對程式進行分叉，然後讓多個程式在後臺並行執行。

　　這是程式設計進行到很後期才要做的事情，屬於對程式的優化，類似於你想開發一種特定的資料結構來取代現有的資料結構。程式的第一個版本通常會忽略平行計算提供的各種好處，就好像程式設計開始時會忽略某種特定的資料結構給你帶來的好處一樣。

　　除了某些特定的應用軟體，一百年後，平行計算不會很流行。如果應用軟體真的大量使用平行計算，這就屬於過早優化了。

　　

　　一百年後會有多少種程式語言？從最近來看，出現了大量的新語言。硬體效能提高是一個原因，這就允許程式設計師根據使用目的在執行速度和程式設計便利性之間做出不同的取捨。如果這就是未來的趨勢，那麼一百年後強大的硬體只會使得語言數目變得更多。

　 　但是，另一方面，一百年後的常用語言可能只有很少幾種。部分原因是基於我的樂觀主義，我相信在未來，如果你的作品確實很出色，你可能選擇的是一種開發起 來很方便的語言。使用這種語言寫出來的軟體第一版的執行速度很慢，只有對編譯器進行優化設定後執行速度才會提升。既然我抱有這種樂觀主義，那麼我還要做一 個預言。有些語言可以達到機器的最高效率，另一些語言的效率則慢到剛剛可以執行而已，兩者之間存在巨大的差距。我預言一百年後，這段差距之間的各個點上都 會有對應的程式語言存在。

　　因為這段差距正在變得越來越大，所以效能分析器（ profiler） 將變得越來越重要。目前，效能分析並沒有受到重視。許多人好像仍然相信，程式執行速度提升的關鍵在於開發出能夠生成更快速程式碼的編譯器。程式碼效率與機器性 能的差距正在不斷加大，我們將會越來越清楚地看到，應用軟體執行速度提升的關鍵在於有一個好的效能分析器幫助指導程式開發。

　　我說將來可能只有很少幾種常用語言，但沒有把用於特定領域的“小眾語言”（ little language）算進去。我覺得，這些嵌入式語言的想法很不錯，一定會蓬勃發展。但是我判斷這些“小眾語言”會被設計成相當薄的一層，使得使用者可以一眼看出在底下作為基礎的通用型語言，這樣就減少了學習時間，降低了使用成本。

　　誰來設計這些未來的語言？過去 10年最激動人心的趨勢之一就是開源語言的崛起，比如 Perl、 Python和 Ruby。語言設計已經被黑客接管。到目前為止這樣到底是好是壞還看不清楚，但是發展勢頭令人鼓舞。比如， Perl就有一些絕妙的創新。不過，它也包含了一些很糟糕的想法。對於一種充滿進取心、大膽探索的語言來說，這也是很正常的事。以它現在這種變化的速率，大概只有上帝才知道一百年後 Perl會變成什麼樣。

　 　有一句俗話說，如果你自己做不到，那就去當老師。這在語言設計領域不成立，我認識的一些最出色的黑客就在當教授。但是，當老師的人確實有很多事情不能 做。研究性職位給黑客帶來了一些限制。在任何學術領域，都有一些題目是可以做的，另一些題目是不可以做的。不幸的是，這兩類題目的區別通常取決於它們寫成 論文後看上去是不是很高深，而不是取決於它們對軟體業的發展是否重要。最極端的例子可能就是文學，文學研究者的任何成果幾乎對文學創作者都毫無影響。

　　雖然科學領域的狀況要稍好一點，但是研究者可以做的題目與能夠對設計優秀語言有所幫助的題目之間的交集小得令人沮喪。（奧林• 希弗斯曾經對這一點表達不滿，而且說得頭頭是道。）比如，研究變數型別的論文好像多得無窮無盡，儘管事實上靜態型別語言看來無法真正支援巨集（在我看來，一種語言不支援巨集，那就不值得使用了）。

　　新語言更多地以開源專案的形式出現，而不是以研究性專案的形式出現。這是語言的一種發展趨勢。另一種發展趨勢是，新語言的設計者更多的是本身就需要使用它們的應用軟體作者，而不是編譯器作者。這似乎是好的趨勢，我期待它繼續保持下去。

　　

　　一百年後的物理學基本上不可能預測。但是計算機語言不一樣，現在就動手設計一種一百年後可以吸引使用者的新語言，這在理論上似乎是可能的。

　　設計新語言的方法之一就是直接寫下你想寫的程式，不管編譯器是否存在，也不管有沒有支援它的硬體。這就是假設存在無限的資源供你支配。不管是今天還是一百年後，這樣的假設好像都是有道理的。

　 　你應該寫什麼程式？隨便什麼，只要能讓你最省力地寫出來就行。但是要注意，這必須是在你的思維沒有被當前使用的程式語言影響的情況下。這種影響無處不 在，必須很努力才能克服。你也許覺得，對於人類這樣懶惰的生物，喜歡用最省力的方式寫程式是再自然不過的事情。但是事實上，我們的思想可能往往會受限於某 種現存的語言，只採用在這種語言看來更簡單的形式，它對我們思想的束縛作用會大得令人震驚。新語言必須靠你自己去發現，不能依靠那些讓你自然而然就沉下去 的思維定勢。

　　

　 　採用程式的長度作為它耗費工作量的近似指標是個很有用的技巧。這裡的程式長度當然不是指字元的數量，而是指各種句法元素的總長度，基本上就是整個解析樹 的大小。也許不能說最短的程式就是寫起來最省力的程式，但是當你一心想把程式寫得簡潔而不是鬆鬆垮垮時，你就更接近省力這個目標，你的日子也會變得好過得 多。所以，設計語言的正確做法就變成了，看著一段程式，然後問自己是不是能把它寫得更短一點？

　　實際上，用想象出來的一種一百年後的語言來寫程式，這件事情的可靠程度，取決於你對語言核心的估計是否足夠正確。常規的排序，你現在就可以寫出來。但是，想要預測一百年後的語言使用什麼函式庫就很難了。很可能許多函式庫針對的領域現在還根本不存在。比如，如果 SETI@home 計劃成功，我們就需要與外星人聯絡的函式庫了。當然，如果外星人的文明高度發達，已經到了用 XML格式交換資訊的地步，那就不需要新的函式庫了。

　　另一個極端是，我覺得今天你就能設計出一百年後的語言核心。事實上，在有些人看來，大部分語言核心在 1958年就已經設計出來了。

　　

　　如果今天就能使用一百年後的程式語言，我們會用它程式設計嗎？觀古而知今。如果 1960年就能使用今天的程式語言，那時的人們會用它們嗎？

　　在某些方面，回答是否定的。今天的程式語言依賴的硬體在 1960年並不存在。比如， Python這樣的語言，正確的縮排（ indentation）在編寫時很重要，但是 1960年的計算機沒有顯示器，只有印表機終端，所以編寫起來就不會很順利。但是，如果把這些因素排除在外（你可以假設，我們只在紙上程式設計）， 20世紀 60年代的程式設計師會喜歡用現在的語言程式設計嗎？

　　我想他們會的。某些缺乏想象力、深受早期程式語言思想影響的人可能會覺得不可能。（沒有指標運算，如何複製資料？沒有 goto語句，如何實現流程圖？）但是我想，那時最聰明的程式設計師一定能輕鬆地使用今天的大多數語言，假定他們能得到的話。

　　如果我們現在就能擁有一百年後的程式語言，那就至少能用來寫出優秀的偽碼 。我們會用它開發軟體嗎？因為一百年後的程式語言需要為某些應用程式生成快速程式碼，所以很可能它生成的程式碼能夠在我們的硬體上執行，速度也還可以接受。相比一百年後的使用者，我們也許不得不對這種語言做更多的優化，但是總的來看，它應該仍然會為我們帶來淨收益。

　　

　　現在，我們的兩個觀點就是：（ 1）一百年後的程式語言在理論上今天就能設計出來；（ 2）如果今天真能設計出這樣一種語言，很可能現在就適合程式設計，並且能夠產生更好的結果。如果我們把這兩個觀點聯絡起來，那就得出了一些有趣的可能性。為什麼不現在就動手嘗試寫出一百年後的程式語言呢？

　　當你設計語言的時候，心裡牢牢記住這個目標是有好處的。學習開車的時候，一個需要記住的原則就是要把車開直，不是通過將車身對齊畫在地上的分隔線，而是通過瞄準遠處的某個點。即使你的目標只在幾米開外，這樣做也是正確的。我認為，設計程式語言時，我們也應該這樣做。

 

摘自《 黑客與畫家 》