摘要：這篇文章曾經叫做《初學者程序語言的選擇》，但是后來我發現，這里給出的看法其實不只是給初學者看的，甚至可能會讓初學者看不懂。而就我在 Google 實習的時候的觀察看來，很多寫了幾十年程序的資深程序員，可能也沒有明白這里指出的道理。所以我把題目改了一下，并且加入了新的內容，希望對新手和老手都有所幫助。

學習程序語言是每個程序員的必經之路。可是這個世界上有太多的程序語言，每一種都號稱具有最新的“特性”。所以程序員的苦惱就在于總是需要學習各種稀奇古怪的語言，而且必須緊跟“潮流”，否則就怕被時代所淘汰。

　　作為一個程序語言的研究者，我深深的知道這種心理產生的根源。程序語言里面其實有著非常簡單，永恒不變的原理。看到了它們，就可以一勞永逸的掌握所有的程序語言，而不是只見樹木不見森林。我想寫一本書，試圖用最簡單的方式來解釋程序語言（以至于計算機科學）的根本性原理，從而讓人可以在非常短的時間內掌握所有程序語言的精髓。但是在還沒有完成之前，我想先提出一些建議和參考書。

　　對程序語言的各種誤解

　　學習程序語言的人，經常會出現以下幾種心理，以至于他們會覺得有學不完的東西，或者走上錯誤的道路。以下我把這些心理簡要分析一下，希望可以消除一些疑惑。

　　1. ?追求“新語言”。

　　基本的哲學告訴我們，新出現的事物并不一定是“新事物”，它們有可能是歷史的倒退。事實證明，新出現的語言，很多還不如早就存在的。正視這個事實吧，現代語言的多少“新概念”不存在于最古老的一些語言里呢？程序語言就像商品，每一家其實都是在打廣告。而絕大多數的設計，包括某些最“艱深”最“理論”的語言里面的概念，都可能是膚淺而短命的。如果你看不透這些東西的設計，就會被它們蒙蔽住。過度的熱情和過多的宣傳，往往意味著膚淺。很多語言設計者其實并不真的懂得程序語言設計的原理，所以常常在設計中重復的犯前人犯過的錯誤。但是為了推銷自己的語言和系統，他們必須夸夸其談，進行宗教式的宣傳。

　　2. ?“存在即是合理”。

　　記得某名人說過：“不能帶來新的思維方式的語言，是沒有必要存在的。”他說的是相當正確的。世界上有這么多的語言，有哪些帶來了新的思維方式呢？其實少之又少。絕大部分的語言給世界帶來的不過是混亂。有人可能反駁說：“你怎么能說 A 語言沒必要存在？我要用的那個庫 L，別的語言不支持，只能用 A。”但是注意，他說的是存在的“必要性”。

　　如果你把存在的“事實”作為存在的“必要性”，那就邏輯錯亂了。就像如果二戰時我們沒能打敗希特勒，現在都做了他的奴隸，然后你就說：“希特勒應該存在，因為他養活了我們。”顯然這個邏輯有問題，因為如果歷史走了另外一條路（即希特勒不存在），我們會過上自由幸福的生活，所以希特勒不應該存在。對比一個東西存在與不存在的兩種可能的后果，然后做出判斷，這才是正確的邏輯。按照這樣的推理，如果設計糟糕的 A 語言不存在，那么設計更好的 B 語言很有可能就會得到更多的支持，從而實現甚至超越 L 庫的功能。

　　3. ?追求“新特性”。

　　程序語言的設計者總是喜歡“發明”新的名詞，喜歡炒作。普通程序員往往看不到，大部分這些“新概念”其實徒有高深而時髦的外表，卻沒有實質的內涵。常常是剛學會一個語言 A，又來了另一個語言 B，說它有一個叫 XYZ 的新特性。于是你又開始學習 B，如此繼續。在內行人看來，這些所謂的“新特性”，絕大部分都是新瓶裝老酒。很多人寫論文喜歡起這樣的標題：《XYZ：A Novel Method for ...》。這造成了概念的爆炸，卻沒有實質的進步。可以說這是計算機科學最致命的缺點。

　　4. ?追求“小竅門”。

　　很多編程書喜歡賣弄一些小竅門，讓程序顯得“短小”。比如它們會跟你講 "(i++) - (++i)" 應該得到什么結果；或者追究運算符的優先級，說這樣可以少打括號；要不就是告訴你“if 后面如果只有一行代碼就可以不加花括號”，等等。殊不知這些小竅門，其實大部分都是程序語言設計的敗筆或者歷史遺留問題。它們帶來的不是清晰的思路，而是是邏輯的混亂和認知的負擔。比如 C 語言的 ++ 運算符，它的出現是因為 C 語言設計者們當初用的計算機內存小的可憐，而 "i++" 顯然比 "i=i+1" 少 2 個字符，所以他們覺得可以節省一些空間。現在我們再也不缺那點內存，可是 ++ 運算符帶來的混亂和迷惑，卻流傳了下來。現在最新的一些語言，也喜歡耍這種語法上的小把戲。如果你追求這些小竅門，往往就抓不住精髓。

　　5. ?針對“專門領域”。

　　很多語言沒有新的東西，為了占據一方土地，就號稱自己適合某種特定的任務，比如文本處理，數據庫查詢，Web編程，游戲設計，并行計算，或者別的什么專門的領域。但是我們真的需要不同的語言來干這些事情嗎？其實絕大部分這些事情都能用同一種通用語言來解決，或者在已有語言的基礎上做很小的改動。只不過由于各種政治和商業原因，不同的語言被設計用來占領市場。就學習而言，它們其實是無關緊要的，而它們帶來的“多語言協作”問題，其實差不多掩蓋了它們帶來的好處。其實從一些設計良好的通用語言，你可以學會所有這些“專用語言”的精髓。后面我會推薦一兩個這樣的語言。

　　我必須指出，以上這些心理不但對自己是有害的，而且對整個業界有很大的危害。受到這些思想教導的人進入了公司，就會開始把他們曾經懼怕的這些東西變成教條，用來篩選新人，從而導致惡性循環。

　　如何掌握所有的程序語言

　　可以老實的說，對幾乎所有風格的程序語言，我都有專家級的見解。它們在我的頭腦里如此簡單，以至于我不再是任何語言（包括函數式語言）的“支持者”。但是我花費了太多的時間去摸索這條道路，我希望能夠提取出一些“竅門”，可以幫助人們在短時間內達到這種通用的理解。具體的細節足夠寫成一本書，我現在只在這里提出一些初步的建議。

　　1. 專注于“精華”和“原理”。

　　就像所有的科學一樣，程序語言最精華的原理其實只有很少數幾個，它們卻可以被用來構造出許許多多紛繁復雜的概念。但是人們往往忽視了簡單原理的重要性，匆匆看過之后就去追求最新的，復雜的概念。他們卻沒有注意到，絕大部分最新的概念其實都可以用最簡單的那些概念組合而成。而對基本概念的一知半解，導致了他們看不清那些復雜概念的實質。比如這些概念里面很重要的一個就是遞歸。國內很多學生對遞歸的理解只停留于漢諾塔這樣的程序，而對遞歸的效率也有很大的誤解，認為遞歸沒有循環來得高效。而其實遞歸比循環表達能力強很多，而且效率幾乎一樣。有些程序比如解釋器，不用遞歸的話基本沒法完成。

　　2. 實現一個程序語言。

　　學習使用一個工具的最好的方式就是制造它，所以學習程序語言的最好方式就是實現一個程序語言。這并不需要一個完整的編譯器，而只需要寫一些簡單的解釋器，實現最基本的功能。之后你就會發現，所有語言的新特性你都大概知道可以如何實現，而不只停留在使用者的水平。實現程序語言最迅速的方式就是使用一種像 Scheme 這樣代碼可以被作為數據的語言。它能讓你很快的寫出新的語言的解釋器。我的 GitHub 里面有一些我寫的解釋器的例子（比如這個短小的代碼實現了 Haskell 的 lazy 語義），有興趣的話可以參考一下。

　　幾種常見風格的語言

　　下面我簡要的說一下幾種常見風格的語言以及它們的問題。注意這里的分類不是嚴格的學術性質的分類，有些在概念上可能有所重疊。

　　1. 面向對象語言

　　事實說明，“面向對象”這整個概念基本是錯誤的。它的風靡是因為當初的“軟件危機”（天知道是不是真的存在這危機）。設計的初衷是讓“界面”和“實現”分離，從而使得下層實現的改動不影響上層的功能。可是大部分面向對象語言的設計都遵循一個根本錯誤的原則：“所有的東西都是對象（Everything is an object）。”以至于所有的函數都必須放在所謂的“對象”里面，從而不能直接被作為參數或者變量傳遞。這導致很多時候需要使用繁瑣的設計模式(design patterns) 來達到甚至對于 C 語言都直接了當的事情。而其實“界面”和“實現”的分離，并不需要把所有函數都放進對象里。另外的一些概念，比如繼承，重載，其實帶來的問題比它們解決的還要多。

　　“面向對象方法”的過度使用，已經開始引起對整個業界的負面作用。很多公司里的程序員喜歡生搬硬套一些不必要的設計模式，其實什么好事情也沒干，只是使得程序冗長難懂。不得不指出，《Design Patterns》這本書，是這很大一部分復雜性的罪魁禍首。不幸的是，如此膚淺，毫無內容，偷換概念的書籍，居然被很多人捧為經典。

　　那么如何看待具備高階函數的面向對象語言，比如 Python，JavaScript，Ruby，Scala？當然有了高階函數，你可以直截了當的表示很多東西，而不需要使用設計模式。但是由于設計模式思想的流毒，一些程序員居然在這些不需要設計模式的語言里也采用繁瑣的設計模式，讓人哭笑不得。所以在學習的時候，最好不要用這些語言，以免受到不必要的干擾。到時候必要的時候再回來使用它們，就可以取其精華，去其糟粕。

　　2. 低級過程式語言?

　　那么是否 C 這樣的“低級語言”就會好一些呢？其實也不是。很多人推崇 C，因為它可以讓人接近“底層”，也就是接近機器的表示，這樣就意味著它速度快。這里其實有三個問題：

• 接近“底層”是否對于初學者是好事？
• “速度快的語言”是什么意思？
• 接近底層的語言是否一定速度快？

　　對于第一個問題，答案是否定的。其實編程最重要的思想是高層的語義(semantics)。語義構成了人關心的問題以及解決它們的算法。而具體的實現(implementation)，比如一個整數用幾個字節表示，雖然還是重要，但卻不是至關重要的。如果把實現作為學習的主要目標，就本末倒置了。因為實現是可以改變的，而它們所表達的本質卻不會變。所以很多人發現自己學會的東西，過不了多久就“過時”了。那就是因為他們學習的不是本質，而只是具體的實現。

　　其次，談語言的“速度”，其實是一句空話。語言只負責描述一個程序，而程序運行的速度，其實絕大部分不取決于語言。它主要取決于 1)算法?和 2)編譯器的質量。編譯器和語言基本是兩碼事。同一個語言可以有很多不同的編譯器實現，每個編譯器生成的代碼質量都可能不同，所以你沒法說“A 語言比 B 語言快”。你只能說“A 語言的 X 編譯器生成的代碼，比 B 語言的 Y 編譯器生成的代碼高效”。這幾乎等于什么也沒說，因為 B 語言可能會有別的編譯器，使得它生成更快的代碼。

　　我舉個例子吧。在歷史上，Lisp 語言享有“龜速”的美名。有人說“Lisp 程序員知道每個東西的值，卻不知道任何事情的代價”，講的就是這個事情。但這已經是很久遠的事情了，現代的 Lisp 系統能編譯出非常高效的代碼。比如商業的 Chez Scheme 編譯器，能在5秒鐘之內編譯它自己，編譯生成的目標代碼非常高效。它的實現真的令人驚嘆，因為它的作者 R. Kent Dybvig 幾乎不依賴于任何已有的軟件和設計。這個編譯器從最初的 parser，到宏擴展，語義分析，寄存器分配，各種優化，…… 一直到匯編器，函數庫，全都是他一個人寫的。它可以直接把 Scheme 程序編譯到多種處理器的機器指令，而不通過任何第三方軟件。它內部的一些算法，其實比開源的 LLVM 之類的先進很多。但是由于是商業軟件，這些算法一直被作為機密沒有發表。

　　另外一些函數式語言也能生成高效的代碼，比如 OCaml。在一次程序語言暑期班上，Cornell 的 Robert Constable 教授講了一個故事，說是他們用 OCaml 重新實現了一個系統，結果發現 OCaml 的實現比原來的 C 語言實現快了 50 倍。經過 C 語言的那個小組對算法多次的優化，OCaml 的版本還是快好幾倍。這里的原因其實在于兩方面。第一是因為函數式語言把程序員從底層細節中解脫出來，讓他們能夠迅速的實現和修改自己的想法，所以他們能夠迅速的找到更好的算法。第二是因為 OCaml 有高效的編譯器實現，使得它能生成很好的代碼。

　　從上面的例子，你也許已經可以看出，其實接近底層的語言不一定速度就快。因為編譯器這種東西其實可以有很高級的“智能”，甚至可以超越任何人能做到的底層優化。但是編譯器還沒有發展到可以代替人來制造算法的地步。所以現在人需要做的，其實只是設計和優化自己的高層算法。

　　3.?高級過程式語言

　　很早的時候，國內計算機系學生的第一門編程課都是 Pascal。Pascal 是很好的語言，可是很多人當時都沒有意識到。大一的時候，我的 Pascal 老師對我們說：“我們學校的教學太落后了。別的學校都開始教 C 或者 C++ 了，我們還在教 Pascal。”現在真正理解了程序語言的設計原理以后我才真正的感覺到，原來 Pascal 是比 C 和 C++ 設計更好的語言。

　　它不但把人從底層細節里解脫出來，沒有面向對象的思維枷鎖，而且含有函數式語言的一些特征（比如可以嵌套函數定義）。可是由于類似的誤解和誤導，Pascal 這樣的語言已經幾乎沒有人用了。這并不很可惜，因為它的精髓，其實已經存在于像 Scheme 這樣的函數式語言里。Scheme 也有賦值語句，所以它實質上含有 Pascal 的所有功能。所以現在的含有賦值語句的函數式語言，可以被看作是是高級過程式語言的“改良版本”。

　　4.?函數式語言

　　函數式語言相對來說是當今最好的設計，因為它們不但讓人專注于算法和對問題的解決，而且沒有面向對象語言那些思維的限制。但是需要注意的是并不是每個函數式語言的特性都是好東西。它們的支持者們經常把缺點也說成是優點，結果它們其實還是被掛上一些不必要的枷鎖。比如 OCaml 和 SML，因為它們的類型系統里面有很多不成熟的設計，導致你需要記住太多不必要的限制。

　　很多人推崇“純函數式”語言（比如 Haskell，Clean），而極力反對其它的帶有“賦值”語句的語言（比如 Scheme 和 ML）。這其中的依據其實是站不住腳的。如果你寫過一個函數式語言的編譯器，你就會了解如何把一個純函數式語言翻譯成機器指令。這些高級的編譯器變換（比如 CPS 和 ANF），其實在本質上揭示了純函數式語言的本質。它們其實與帶有賦值語句的語言沒有本質上的區別，但是由于沒有賦值語句，一些事情必須拐彎抹角的實現。理智的使用局部變量或者數組的賦值，會使程序更加簡單，容易理解，甚至更加高效。

　　5.?邏輯式語言

　　邏輯式語言（比如 Prolog）是一種超越函數式語言的新的思想，所以需要一些特殊的訓練。邏輯式語言寫的程序，是能“反向運行”的。普通程序語言寫的程序，如果你給它一個輸入，它會給你一個輸出。但是邏輯式語言很特別，如果你給它一個輸出，它可以反過來運行，給你所有可能的輸入。其實通過很簡單的方法，可以順利的把程序從函數式轉換成邏輯式的。但是邏輯式語言一般要在“pure”的情況下（也就是沒有復雜的賦值操作）才能反向運行。所以學習邏輯式語言最好是從函數式語言開始，在理解了遞歸，模式匹配等基本的函數式編程技巧之后再來看 Prolog，就會發現邏輯式編程簡單了很多。

　　從何開始

　　可是學習編程總要從某種語言開始。那么哪種語言呢？其實每種語言都有自己的問題，以至于在我未來的書里，會使用一種非常簡單的語言，它含有所有語言的精髓，卻不帶有多余的東西。可是在我完成這本書之前，我想先推薦一兩個現成的語言。

　　就我的觀點，首先可以從 Scheme 入門，然后學習一些 Haskell (但不是全部)，之后其它的也就觸類旁通了。你并不需要學習它們的所有細枝末節，而只需要學習最精華的部分。所有剩余的細節，會在實際使用中很容易的被填補上。我后面會提一下哪些是精華的，哪些是最開頭沒必要學的。

　　從 Scheme（而不是 Haskell）作為入門的第一步，是因為：

Scheme 沒有像 Haskell 那樣的靜態類型系統 (static type system)。并不是說靜態類型不好，但是我不得不說，Haskell 那樣的靜態類型系統，還遠遠沒有發展到可以讓人可以完全的寫出符合事物本質的程序來。比如，一些重要的概念比如 Y combinator，沒法用 Haskell 直接寫出來。當然你可以在 Haskell 里面使用作用類似 Y combinator 的東西(比如 fix，或者利用它的 laziness)，但是這些并不揭示遞歸的本質，你只是在依靠 Haskell 已經實現的遞歸來進行遞歸，而不能實際的體會到遞歸是如何產生的。而用 Scheme，你可以輕松的寫出 Y combinator，并且實際的投入使用。

Scheme 不需要 monad。Haskell是一個“純函數式” (purely functional) 的語言，所有的“副作用”(side-effect)，比如打印字符到屏幕，都得用一種故作高深的概念叫 monad 實現。這種概念其實并不是本質的，它所有的功能都可以通過“狀態傳遞” (state passing) 來實現。通過寫狀態傳遞程序，你可以清楚的看到 monad 的本質。可以說 monad 是 Haskell 的一個“設計模式”。過早的知道這個東西，并不有助于理解函數式程序設計的本質。

　　那么為什么又要學 Haskell？那是因為 Haskell 含有 Scheme 缺少的一些東西，并且沒有 Scheme 設計上的一些問題。比如：

模式匹配：Scheme 沒有一個標準的，自然的模式匹配(pattern matching)?系統，而 Haskell 的模式匹配是一個優美的實現。也有些 Scheme 的擴展實現（比如 Racket）具有相當好的模式匹配機制。

類型：Scheme 把所有不是 #f (false）的值都作為 true，這是不對的。Haskell 里面的 Boolean 就只有兩個值：True 和 False。Scheme 程序員聲稱這樣可以寫出簡潔的代碼，因為 (or x y z) 可以返回一個具體的值，而不只是一個布爾變量。但是就為了在少數情況下可以寫出短一點的代碼，是否值得付出如此沉痛的代價？我看到這個設計帶來了很多無需有的問題。

宏系統：宏 (macro) 通常被認為是 Lisp 系列語言的一個重要優點。但是我要指出的是，它們并不是必要的，至少對于初學者是這樣。其實如果一個語言的語義設計好了，你會幾乎不需要宏。因為宏的本質是讓程序員可以自己修改語言的設計，添加新的構造。可是宏的主要缺點是，它把改變語言這種極其危險的“權力”給人濫用了。其實只有極少數的人具有改變一個語言所需的智慧和經驗。如果讓普通程序員都能使用宏，那么程序將變得非常難以理解。所以其實一般程序員都不需要學習宏的使用，也不必為略過這個東西而產生負罪感。等你進步到可以設計自己的程序語言，你自然會明白宏是什么東西。

　　（注意，這些是我自己的觀點，并不代表 Scheme 設計者們的觀點。）

　　推薦的書籍

　　《The Little Schemer》：我覺得 Dan Friedman 的?The Little Schemer?(TLS) 是目前最好，最精華的編程入門教材。它的前身叫《The Little Lisper》。很多資深的程序語言專家都是從這本書學會了 Lisp。雖然它叫 "The Little Schemer"，但它并不使用 Scheme 所有的功能，而是忽略了上面提到的 Scheme 的毛病，直接進入最關鍵的主題：遞歸和它的基本原則。這本書不但很薄，很精辟，而且相對于其他編程書籍非常便宜（在美國才賣 $23）。

　　《SICP》：The Little Schemer?其實是比較難的讀物，所以我建議把它作為下一步精通的讀物。Structure and Interpretation of Computer Programs?比較適合作為第一本教材。但是我需要提醒的是，你最多只需要看完前三章。因為從第四章開始，作者開始實現一個 Scheme 解釋器，但是作者的實現并不是最好的方式。你可以從別的地方更好的學到這些東西。具體在哪里學，我還沒想好（也許我自己寫個教學也說不定）。不過也許你可以看完 SICP 第一章之后就可以開始看 TLS。

　　《A Gentle Introduction to Haskell》：對于 Haskell，我最開頭看的是?A Gentle Introduction to Haskell，因為它特別短小。當時我已經會了 Scheme，所以不需要再學習基本的函數式語言的東西。我從這個文檔學到的只不過是 Haskell 對于類型和模式匹配的概念。Real World Haskell?是一本流行的教材，但是它試圖包羅萬象，所以很多地方過于冗長。最根本的函數式編程概念，還是 TLS 講的透徹。

　　過度到面向對象語言

　　那么如果從函數式語言入門，如何過渡到面向對象語言呢？畢竟大部分的公司用的是面向對象語言。如果你真的學會了函數式語言，你真的會發現面向對象語言已經易如反掌。函數式語言的設計比面向對象語言簡單和強大很多，而且幾乎所有的函數式語言教材（比如 SICP）都會教你如何實現一個面向對象系統。

　　你會深刻的看到面向對象的本質以及它存在的問題，所以你會很容易的搞清楚怎么寫面向對象的程序，并且會發現一些竅門來避開它們的局限。你會發現，即使在實際的工作中必須使用面向對象語言，也可以避免面向對象的思維方式，因為面向對象的思想帶來的大部分是混亂和冗余。

　　深入本質和底層

　　那么是不是完全不需要學習底層呢？當然不是。但是一開頭就學習底層硬件，就會被紛繁復雜的硬件設計蒙蔽頭腦，看不清楚本質上簡單的原理。

　　在學會高層的語言之后，可以進行語義學和編譯原理的學習。簡言之，語義學 (semantics) 就是研究程序的符號表示如何對機器產生“意義”，通常語義學的學習包含 lambda calculus 和各種解釋器的實現。編譯原理 (compilation) 就是研究如何把高級語言翻譯成低級的機器指令。

　　編譯原理其實包含了計算機的組成原理，比如二進制的構造和算術，處理器的結構，內存尋址等等。但是結合了語義學和編譯原理來學習這些東西，會事半功倍。因為你會直觀的看到為什么現在的計算機系統會設計成這個樣子：為什么處理器里面有寄存器(register)，為什么需要堆棧(stack)，為什么需要堆(heap)，它們的本質是什么。

　　這些甚至是很多硬件設計者都不明白的問題，所以它們的硬件里經常含有一些沒必要的東西。因為他們不理解語義，所以經常不明白他們的硬件到底需要哪些部件和指令。但是從高層語義來解釋它們，就會揭示出它們的本質，從而可以讓你明白如何設計出更加優雅和高效的硬件。

　　這就是為什么一些程序語言專家后來也開始設計硬件。比如 Haskell 的創始人之一 Lennart Augustsson，后來設計了 BlueSpec，一種高級的硬件描述語言，可以 100% 的合成 (synthesis) 為硬件電路。Scheme 也被廣泛的使用在硬件設計中，比如 Motorola，Cisco 和曾經的 Transmeta，它們的芯片設計里面含有很多 Scheme 程序。

　　這基本上就是我對學習程序語言的初步建議。

總結

以上是生活随笔為你收集整理的如何掌握程序语言(转自王垠Blog)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。