幾個月前，一個同事問我，應該如何選擇程式語言，或者有沒有什麼固定的選擇模式，當時我便打算寫點什麼。上週在矽谷開會，這我是第一次跟 “hack3rs”的創業狂以及技術狂們打交道。我學會了很多前所未聞的髒話，也有所得–即便是追求精簡的初創企業也傾向於把問題過份複雜化。
將真正領悟精簡精神的人甄別出來並不困難。谷歌，Facebook以及Akamai的程師們的講座魅力十足。他們從一個更巨集觀的角度思考和解決問題。這跟公司的財力，規模沒有關係，他們特意剪除細枝末節，以便將注意力集中在問題的根本。
我自己也曾一味要求手下考慮使用高階程式語言甚至全物件導向語言，我發現許多的新時代初創企業也還沒領悟其精髓。他們用Javascript、Python和Ruby程式設計，卻不明白為什麼要用這些語言。
不可否認，把迴圈寫得緊湊或者避免使用模板固有其道理。但如果這是你選擇一門程式語言的唯一理由，那麼你就大錯特錯了。日常工作中，與其用基於深度 優化的向量化C++語言構建的多核並行非同步map-reduce架構去做一個卷積離散傅立葉變換（correlation-DFT），我寧願用BASIC 來做一個快速傅立葉變換（FFT）。
那麼到底應該根據什麼來選擇程式語言呢？唯一檢驗標準：是否言而達意。
拋開語言的執行效率和功能等等不談，一門語言必須能夠讓你描述自己的意圖，不光是對編譯器而言，更是對未來的讀者而言。我相信軟體維護中99%的問 題都是由於最初寫程式碼的人沒能準備表述他們的意圖造成的。如果言不達意，文件就不叫文件。如果言不達意，UML圖就不是UML圖。如果無法描述某種資料型 適用於哪些操作符的話，物件導向程式設計就不是物件導向程式設計。言而達意不是指C風格的ModifyWindowEx（HWND wnd）不易讀而Window.modify（）告訴了你和編譯器這個window可以和不可以做什麼。關鍵是要表明你的意圖。
Fortran如今已大大落後，因為它用下面這種方式描述一個算式：
MOV AX, $5D ADD AX, $6F MOV $7F, AX其實完全可以寫成這樣：
c = a + b如此你就知道是a加上b，結果存到c，即便你不懂計算機也能看懂。
一個常見的誤解是：函數語言程式設計語言表達你要什麼（what you want）而指令式程式設計語言表達你想怎樣（how you want）。
這是一種糟糕的理解。因為有時候“你想怎樣”恰恰是你想表達的意思。
按照我一貫的博文風格，請你問自己一個基本問題，當面臨語言的選擇時：
“我是否把意思說清楚了？”
如果你無法回答這個問題，那麼你沒有用最佳語言。如果你不得不寫文件或者做註釋，這說明你的程式碼沒能描述你的意圖。看看這個函式原型：
char* reverseString(const char *foo);在缺少關於空指標，空字串以及其他異常處理文件的幫助下，根本沒法理解作者到底想幹什麼。這不太好。當然，函式內部可能對輸入做了無數的驗證，但你必須寫一堆針對各種特定輸入的單元測試以確保你的假設是正確的。
我所指的“把意思說清楚”是什麼意思呢？假設C++在原型中支援以下虛擬語法：
char* @Nullable reverseString(@NonNullable const char *foo);函式原型中加上這些註解有兩個好處：
- 1. 你不需要事先測試foo是不是null。編譯器保證會給你一個非null。
- 2. 明確地告訴呼叫者你不容忍null。這種表述方式編譯器能夠明白，優秀的靜態分析工具可以檢測到這類bug，這是C語言做不到的。
雖然這看起來只不過是增強了一下語法，實際不僅如此，它還增強了語義。如此不論是人或是機器就明白foo這個變數不可為null，否則函式很生氣，後果很嚴重。而且，你給這個函式劃定了界限，再不用擔心foo可否為null了。
函數語言程式設計並不是萬金油：
大家對我的另外一個常見誤解是我推崇純函式式語言。我的確有理由喜歡它們。看到上面那個式子了嗎？
c = a + b如果我想把expr1和expr2的值相加該如何表達呢？
c = (expr1) + (expr2)如果expr1有附加操作而且會影響expr2的值又該如何表達呢？這並不罕見：
c = (a++) + (a + b);這裡的問題不是你想的那樣。我知道你在想什麼：“天知道這門語言會如何解釋這個式子。萬一計算的順序反了怎麼辦？”
你想錯了。正是由於人們會產生那樣的想法，程式語言才會有這樣的特點。要解答你的疑問很簡單，看看編譯手冊就知道了。
上面式子的根本問題是我無法知道那樣的計算順序是偶然的還是有意的。我確切地知道上面式子的會做什麼，但我無法確定的是，它的計算順序是不是有意 的？我能不能優化那個式子，放到一個迴圈裡去？我能不能在多核多執行緒的情況下呼叫它？假設有人問我，如果給z賦值10而不是20，會不會影響c的值，我無 法回答。
理論上是無法回答上面那個問題的。當然了我們可以根據經驗做加一些斷言（assertion）。在斷言出了一堆或者一個警告後，理性地說，我們仍然不知道z會不會影響a或者b，最終影響到c。
為什麼這很重要
程式碼的可維護性是建立在程式碼的可閱讀性的基礎上的。你知道為什麼CSS不好嗎？如果僅僅是程式設計師寫錯了或者設計者把字型和佈局規則混淆了，地球人都知道那還不算太壞。CSS壞就壞在如果不加上大量的註釋，人們就無法通過字面上的意思來理解程式碼的意圖。
別忘了基於規則的宣告式語言並不是新概念，更不是革命。50年前Prolog就提供了類似CSS的宣告方式。今天的Erlang也提供了這類方式，並在業界得到廣泛應用。
請看下面這行程式碼：
div .title #subtitle {color: blue}如果不載入試一下的話，我敢打賭你完全想不到這會對頁面產生怎樣的效果。字面上完全看不出跟其它規則的關係，也看不出它如何處理匹配衝突。因此對於汝等Ruby/Python/Node.js程式設計師而言，我的建議是，如果你真想超凡脫俗的話，學學谷歌和Facebook。他們使用一些 實驗性技術，並不是為了取代for-loops，而是用來表明for-loops的意圖。快速原型的話選擇簡單的語言就可以了，當需要準確描述意圖的時候 才考慮更換程式語言。
命令式語言的必要性：
最後，我想解釋一下為什麼命令式語言是必要的。看看下面這個驅動程式例子：
setlpt1(00000000b); setlpt1(00010000b); setlpt1(00000000b);這是我假想的串列埠命令協議。這幾行程式碼是按照先後順序排列的。哪怕200年以後，它們的意圖也不會發生什麼變化。必要的時候使用命令型語言，明確地 告訴讀者不要打亂這些程式碼。你不應該改變它們的順序。你也不會把他們用在某些抽象的埠上，它們只適用於串列埠或者所謂印表機口。
用函式式語言來實現上面的功能，並且加上同步原語來保證它們按照順序執行，是愚蠢的。
結論：
如果說這篇文章有一點點值得總結的東西的話，那便是：下次你寫任何程式碼/規範/程式的時候，問問自己，意圖是否清楚表達？未來的維護者看到你寫的東西，是否能明白它?
相關閱讀
評論(2)