幾個月前，一個同事問我，應該如何選擇編程語言，或者有沒有什么固定的選擇模式，當時我便打算寫點什么。上周在硅谷開會，這我是第一次跟“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年以后，它們的意圖也不會發生什么變化。必要的時候使用命令型語言，明確地告訴讀者不要打亂這些代碼。你不應該改變它們的順序。你也不會把他們用在某些抽象的端口上，它們只適用于串口或者所謂打印機口。
用函數式語言來實現上面的功能，并且加上同步原語來保證它們按照順序運行，是愚蠢的。
結論：
如果說這篇文章有一點點值得總結的東西的話，那便是：下次你寫任何代碼/規范/程序的時候，問問自己，意圖是否清楚表達？未來的維護者看到你寫的東西，是否能明白它
