幾個月前，一個同事問我，應(yīng)該如何選擇編程語言，或者有沒有什么固定的選擇模式，當(dāng)時我便打算寫點什么。上周在硅谷開會，這我是***次跟“hack3rs”的創(chuàng)業(yè)狂以及技術(shù)狂們打交道。我學(xué)會了很多前所未聞的臟話，也有所得–即便是追求精簡的初創(chuàng)企業(yè)也傾向于把問題過份復(fù)雜化。

將真正領(lǐng)悟精簡精神的人甄別出來并不困難。谷歌，F(xiàn)acebook以及Akamai的程師們的講座魅力十足。他們從一個更宏觀的角度思考和解決問題。這跟公司的財力，規(guī)模沒有關(guān)系，他們特意剪除細(xì)枝末節(jié)，以便將注意力集中在問題的根本。

我自己也曾一味要求手下考慮使用高級編程語言甚至全面向?qū)ο笳Z言，我發(fā)現(xiàn)許多的新時代初創(chuàng)企業(yè)也還沒領(lǐng)悟其精髓。他們用Javascript、Python和Ruby編程，卻不明白為什么要用這些語言。

不可否認(rèn)，把循環(huán)寫得緊湊或者避免使用模板固有其道理。但如果這是你選擇一門編程語言的唯一理由，那么你就大錯特錯了。日常工作中，與其用基于深度優(yōu)化的向量化C++語言構(gòu)建的多核并行異步map-reduce架構(gòu)去做一個卷積離散傅立葉變換（correlation-DFT），我寧愿用BASIC來做一個快速傅立葉變換（FFT）。

那么到底應(yīng)該根據(jù)什么來選擇編程語言呢？唯一檢驗標(biāo)準(zhǔn)：是否言而達(dá)意。

拋開語言的執(zhí)行效率和功能等等不談，一門語言必須能夠讓你描述自己的意圖，不光是對編譯器而言，更是對未來的讀者而言。我相信軟件維護(hù)中99%的問題都是由于最初寫代碼的人沒能準(zhǔn)備表述他們的意圖造成的。如果言不達(dá)意，文檔就不叫文檔。如果言不達(dá)意，UML圖就不是UML圖。如果無法描述某種數(shù)據(jù)型適用于哪些操作符的話，面向?qū)ο缶幊叹筒皇敲嫦驅(qū)ο缶幊?。言而達(dá)意不是指C風(fēng)格的ModifyWindowEx（HWND wnd）不易讀而Window.modify（）告訴了你和編譯器這個window可以和不可以做什么。關(guān)鍵是要表明你的意圖。

Fortran如今已大大落后，因為它用下面這種方式描述一個算式：

MOV AX, $5D
ADD AX, $6F
MOV $7F, AX

其實完全可以寫成這樣：

c = a + b

如此你就知道是a加上b，結(jié)果存到c，即便你不懂計算機(jī)也能看懂。

一個常見的誤解是：函數(shù)式編程語言表達(dá)你要什么（what you want）而命令式編程語言表達(dá)你想怎樣（how you want）。

這是一種糟糕的理解。因為有時候“你想怎樣”恰恰是你想表達(dá)的意思。

按照我一貫的博文風(fēng)格，請你問自己一個基本問題，當(dāng)面臨語言的選擇時：

“我是否把意思說清楚了？”

如果你無法回答這個問題，那么你沒有用***語言。如果你不得不寫文檔或者做注釋，這說明你的代碼沒能描述你的意圖。看看這個函數(shù)原型：

char* reverseString(const char *foo);

在缺少關(guān)于空指針，空字符串以及其他異常處理文檔的幫助下，根本沒法理解作者到底想干什么。這不太好。當(dāng)然，函數(shù)內(nèi)部可能對輸入做了無數(shù)的驗證，但你必須寫一堆針對各種特定輸入的單元測試以確保你的假設(shè)是正確的。

我所指的“把意思說清楚”是什么意思呢？假設(shè)C++在原型中支持以下虛擬語法：

char* @Nullable reverseString(@NonNullable const char *foo);

函數(shù)原型中加上這些注解有兩個好處：

1. 你不需要事先測試foo是不是null。編譯器保證會給你一個非null。

2. 明確地告訴調(diào)用者你不容忍null。這種表述方式編譯器能夠明白，優(yōu)秀的靜態(tài)分析工具可以檢測到這類bug，這是C語言做不到的。

雖然這看起來只不過是增強(qiáng)了一下語法，實際不僅如此，它還增強(qiáng)了語義。如此不論是人或是機(jī)器就明白foo這個變量不可為null，否則函數(shù)很生氣，后果很嚴(yán)重。而且，你給這個函數(shù)劃定了界限，再不用擔(dān)心foo可否為null了。

函數(shù)式編程并不是萬金油：

大家對我的另外一個常見誤解是我推崇純函數(shù)式語言。我的確有理由喜歡它們?？吹缴厦婺莻€式子了嗎？

c = a + b

如果我想把expr1和expr2的值相加該如何表達(dá)呢？

c = (expr1) + (expr2)

如果expr1有附加操作而且會影響expr2的值又該如何表達(dá)呢？這并不罕見：

c = (a++) + (a + b);

這里的問題不是你想的那樣。我知道你在想什么：“天知道這門語言會如何解釋這個式子。萬一計算的順序反了怎么辦？”

你想錯了。正是由于人們會產(chǎn)生那樣的想法，編程語言才會有這樣的特點。要解答你的疑問很簡單，看看編譯手冊就知道了。

上面式子的根本問題是我無法知道那樣的計算順序是偶然的還是有意的。我確切地知道上面式子的會做什么，但我無法確定的是，它的計算順序是不是有意的？我能不能優(yōu)化那個式子，放到一個循環(huán)里去？我能不能在多核多線程的情況下調(diào)用它？假設(shè)有人問我，如果給z賦值10而不是20，會不會影響c的值，我無法回答。

理論上是無法回答上面那個問題的。當(dāng)然了我們可以根據(jù)經(jīng)驗做加一些斷言（assertion）。在斷言出了一堆或者一個警告后，理性地說，我們?nèi)匀徊恢纙會不會影響a或者b，最終影響到c。

為什么這很重要

代碼的可維護(hù)性是建立在代碼的可閱讀性的基礎(chǔ)上的。你知道為什么CSS不好嗎？如果僅僅是程序員寫錯了或者設(shè)計者把字體和布局規(guī)則混淆了，地球人都知道那還不算太壞。CSS壞就壞在如果不加上大量的注釋，人們就無法通過字面上的意思來理解代碼的意圖。

別忘了基于規(guī)則的聲明式語言并不是新概念，更不是革命。50年前Prolog就提供了類似CSS的聲明方式。今天的Erlang也提供了這類方式，并在業(yè)界得到廣泛應(yīng)用。

請看下面這行代碼：

div .title #subtitle {color: blue}

如果不加載試一下的話，我敢打賭你完全想不到這會對頁面產(chǎn)生怎樣的效果。字面上完全看不出跟其它規(guī)則的關(guān)系，也看不出它如何處理匹配沖突。

因此對于汝等Ruby/Python/Node.js程序員而言，我的建議是，如果你真想超凡脫俗的話，學(xué)學(xué)谷歌和Facebook。他們使用一些實驗性技術(shù)，并不是為了取代for-loops，而是用來表明for-loops的意圖。快速原型的話選擇簡單的語言就可以了，當(dāng)需要準(zhǔn)確描述意圖的時候才考慮更換編程語言。

命令式語言的必要性：

***，我想解釋一下為什么命令式語言是必要的?？纯聪旅孢@個驅(qū)動程序例子：

setlpt1(00000000b);

setlpt1(00010000b);

setlpt1(00000000b);

這是我假想的串口命令協(xié)議。這幾行代碼是按照先后順序排列的。哪怕200年以后，它們的意圖也不會發(fā)生什么變化。必要的時候使用命令型語言，明確地告訴讀者不要打亂這些代碼。你不應(yīng)該改變它們的順序。你也不會把他們用在某些抽象的端口上，它們只適用于串口或者所謂打印機(jī)口。

用函數(shù)式語言來實現(xiàn)上面的功能，并且加上同步原語來保證它們按照順序運行，是愚蠢的。

結(jié)論：

如果說這篇文章有一點點值得總結(jié)的東西的話，那便是：下次你寫任何代碼/規(guī)范/程序的時候，問問自己，意圖是否清楚表達(dá)？未來的維護(hù)者看到你寫的東西，是否能明白它

原文鏈接：http://www.techug.com/why-programming-languages-matter