為什么說(shuō)選擇正確的編程語(yǔ)言很重要，以及如何正確的選擇
幾個(gè)月前，一個(gè)同事問(wèn)我，應(yīng)該如何選擇編程語(yǔ)言，或者有沒(méi)有什么固定的選擇模式，當(dāng)時(shí)我便打算寫(xiě)點(diǎn)什么。上周在硅谷開(kāi)會(huì)，這我是***次跟“hack3rs”的創(chuàng)業(yè)狂以及技術(shù)狂們打交道。我學(xué)會(huì)了很多前所未聞的臟話，也有所得–即便是追求精簡(jiǎn)的初創(chuàng)企業(yè)也傾向于把問(wèn)題過(guò)份復(fù)雜化。
將真正領(lǐng)悟精簡(jiǎn)精神的人甄別出來(lái)并不困難。谷歌，F(xiàn)acebook以及Akamai的程師們的講座魅力十足。他們從一個(gè)更宏觀的角度思考和解決問(wèn)題。這跟公司的財(cái)力，規(guī)模沒(méi)有關(guān)系，他們特意剪除細(xì)枝末節(jié)，以便將注意力集中在問(wèn)題的根本。
我自己也曾一味要求手下考慮使用高級(jí)編程語(yǔ)言甚至全面向?qū)ο笳Z(yǔ)言，我發(fā)現(xiàn)許多的新時(shí)代初創(chuàng)企業(yè)也還沒(méi)領(lǐng)悟其精髓。他們用Javascript、Python和Ruby編程，卻不明白為什么要用這些語(yǔ)言。
不可否認(rèn)，把循環(huán)寫(xiě)得緊湊或者避免使用模板固有其道理。但如果這是你選擇一門(mén)編程語(yǔ)言的唯一理由，那么你就大錯(cuò)特錯(cuò)了。日常工作中，與其用基于深度優(yōu)化的向量化C++語(yǔ)言構(gòu)建的多核并行異步map-reduce架構(gòu)去做一個(gè)卷積離散傅立葉變換（correlation-DFT），我寧愿用BASIC來(lái)做一個(gè)快速傅立葉變換（FFT）。
那么到底應(yīng)該根據(jù)什么來(lái)選擇編程語(yǔ)言呢？唯一檢驗(yàn)標(biāo)準(zhǔn)：是否言而達(dá)意。
拋開(kāi)語(yǔ)言的執(zhí)行效率和功能等等不談，一門(mén)語(yǔ)言必須能夠讓你描述自己的意圖，不光是對(duì)編譯器而言，更是對(duì)未來(lái)的讀者而言。我相信軟件維護(hù)中99%的問(wèn)題都是由于最初寫(xiě)代碼的人沒(méi)能準(zhǔn)備表述他們的意圖造成的。如果言不達(dá)意，文檔就不叫文檔。如果言不達(dá)意，UML圖就不是UML圖。如果無(wú)法描述某種數(shù)據(jù)型適用于哪些操作符的話，面向?qū)ο缶幊叹筒皇敲嫦驅(qū)ο缶幊?。言而達(dá)意不是指C風(fēng)格的ModifyWindowEx（HWND wnd）不易讀而Window.modify（）告訴了你和編譯器這個(gè)window可以和不可以做什么。關(guān)鍵是要表明你的意圖。
Fortran如今已大大落后，因?yàn)樗孟旅孢@種方式描述一個(gè)算式：
MOV AX, $5D ADD AX, $6F MOV $7F, AX
其實(shí)完全可以寫(xiě)成這樣：
c = a + b
如此你就知道是a加上b，結(jié)果存到c，即便你不懂計(jì)算機(jī)也能看懂。
一個(gè)常見(jiàn)的誤解是：函數(shù)式編程語(yǔ)言表達(dá)你要什么（what you want）而命令式編程語(yǔ)言表達(dá)你想怎樣（how you want）。
這是一種糟糕的理解。因?yàn)橛袝r(shí)候“你想怎樣”恰恰是你想表達(dá)的意思。
按照我一貫的博文風(fēng)格，請(qǐng)你問(wèn)自己一個(gè)基本問(wèn)題，當(dāng)面臨語(yǔ)言的選擇時(shí)：
“我是否把意思說(shuō)清楚了？”
如果你無(wú)法回答這個(gè)問(wèn)題，那么你沒(méi)有用***語(yǔ)言。如果你不得不寫(xiě)文檔或者做注釋，這說(shuō)明你的代碼沒(méi)能描述你的意圖?？纯催@個(gè)函數(shù)原型：
char* reverseString(const char *foo);
在缺少關(guān)于空指針，空字符串以及其他異常處理文檔的幫助下，根本沒(méi)法理解作者到底想干什么。這不太好。當(dāng)然，函數(shù)內(nèi)部可能對(duì)輸入做了無(wú)數(shù)的驗(yàn)證，但你必須寫(xiě)一堆針對(duì)各種特定輸入的單元測(cè)試以確保你的假設(shè)是正確的。
我所指的“把意思說(shuō)清楚”是什么意思呢？假設(shè)C++在原型中支持以下虛擬語(yǔ)法：
char* @Nullable reverseString(@NonNullable const char *foo);
函數(shù)原型中加上這些注解有兩個(gè)好處：
1. 你不需要事先測(cè)試foo是不是null。編譯器保證會(huì)給你一個(gè)非null。
2. 明確地告訴調(diào)用者你不容忍null。這種表述方式編譯器能夠明白，優(yōu)秀的靜態(tài)分析工具可以檢測(cè)到這類bug，這是C語(yǔ)言做不到的。
雖然這看起來(lái)只不過(guò)是增強(qiáng)了一下語(yǔ)法，實(shí)際不僅如此，它還增強(qiáng)了語(yǔ)義。如此不論是人或是機(jī)器就明白foo這個(gè)變量不可為null，否則函數(shù)很生氣，后果很嚴(yán)重。而且，你給這個(gè)函數(shù)劃定了界限，再不用擔(dān)心foo可否為null了。
函數(shù)式編程并不是萬(wàn)金油：
大家對(duì)我的另外一個(gè)常見(jiàn)誤解是我推崇純函數(shù)式語(yǔ)言。我的確有理由喜歡它們?？吹缴厦婺莻€(gè)式子了嗎？
c = a + b
如果我想把expr1和expr2的值相加該如何表達(dá)呢？
c = (expr1) + (expr2)
如果expr1有附加操作而且會(huì)影響expr2的值又該如何表達(dá)呢？這并不罕見(jiàn)：
c = (a++) + (a + b);
這里的問(wèn)題不是你想的那樣。我知道你在想什么：“天知道這門(mén)語(yǔ)言會(huì)如何解釋這個(gè)式子。萬(wàn)一計(jì)算的順序反了怎么辦？”
你想錯(cuò)了。正是由于人們會(huì)產(chǎn)生那樣的想法，編程語(yǔ)言才會(huì)有這樣的特點(diǎn)。要解答你的疑問(wèn)很簡(jiǎn)單，看看編譯手冊(cè)就知道了。
上面式子的根本問(wèn)題是我無(wú)法知道那樣的計(jì)算順序是偶然的還是有意的。我確切地知道上面式子的會(huì)做什么，但我無(wú)法確定的是，它的計(jì)算順序是不是有意的？我能不能優(yōu)化那個(gè)式子，放到一個(gè)循環(huán)里去？我能不能在多核多線程的情況下調(diào)用它？假設(shè)有人問(wèn)我，如果給z賦值10而不是20，會(huì)不會(huì)影響c的值，我無(wú)法回答。
理論上是無(wú)法回答上面那個(gè)問(wèn)題的。當(dāng)然了我們可以根據(jù)經(jīng)驗(yàn)做加一些斷言（assertion）。在斷言出了一堆或者一個(gè)警告后，理性地說(shuō)，我們?nèi)匀徊恢纙會(huì)不會(huì)影響a或者b，最終影響到c。
為什么這很重要
代碼的可維護(hù)性是建立在代碼的可閱讀性的基礎(chǔ)上的。你知道為什么CSS不好嗎？如果僅僅是程序員寫(xiě)錯(cuò)了或者設(shè)計(jì)者把字體和布局規(guī)則混淆了，地球人都知道那還不算太壞。CSS壞就壞在如果不加上大量的注釋，人們就無(wú)法通過(guò)字面上的意思來(lái)理解代碼的意圖。
別忘了基于規(guī)則的聲明式語(yǔ)言并不是新概念，更不是革命。50年前Prolog就提供了類似CSS的聲明方式。今天的Erlang也提供了這類方式，并在業(yè)界得到廣泛應(yīng)用。
請(qǐng)看下面這行代碼：
div .title #subtitle {color: blue}
如果不加載試一下的話，我敢打賭你完全想不到這會(huì)對(duì)頁(yè)面產(chǎn)生怎樣的效果。字面上完全看不出跟其它規(guī)則的關(guān)系，也看不出它如何處理匹配沖突。
因此對(duì)于汝等Ruby/Python/Node.js程序員而言，我的建議是，如果你真想超凡脫俗的話，學(xué)學(xué)谷歌和Facebook。他們使用一些實(shí)驗(yàn)性技術(shù)，并不是為了取代for-loops，而是用來(lái)表明for-loops的意圖?？焖僭偷脑掃x擇簡(jiǎn)單的語(yǔ)言就可以了，當(dāng)需要準(zhǔn)確描述意圖的時(shí)候才考慮更換編程語(yǔ)言。
命令式語(yǔ)言的必要性：
***，我想解釋一下為什么命令式語(yǔ)言是必要的?？纯聪旅孢@個(gè)驅(qū)動(dòng)程序例子：
setlpt1(00000000b); setlpt1(00010000b); setlpt1(00000000b);
這是我假想的串口命令協(xié)議。這幾行代碼是按照先后順序排列的。哪怕200年以后，它們的意圖也不會(huì)發(fā)生什么變化。必要的時(shí)候使用命令型語(yǔ)言，明確地告訴讀者不要打亂這些代碼。你不應(yīng)該改變它們的順序。你也不會(huì)把他們用在某些抽象的端口上，它們只適用于串口或者所謂打印機(jī)口。
用函數(shù)式語(yǔ)言來(lái)實(shí)現(xiàn)上面的功能，并且加上同步原語(yǔ)來(lái)保證它們按照順序運(yùn)行，是愚蠢的。
結(jié)論：
如果說(shuō)這篇文章有一點(diǎn)點(diǎn)值得總結(jié)的東西的話，那便是：下次你寫(xiě)任何代碼/規(guī)范/程序的時(shí)候，問(wèn)問(wèn)自己，意圖是否清楚表達(dá)？未來(lái)的維護(hù)者看到你寫(xiě)的東西，是否能明白它
