八戒推薦1
幾個月前跋炕，一個同事問我赖晶，應(yīng)該如何選擇編程語言，或者有沒有什么固定的選擇模式辐烂，當時我便打算寫點什么遏插。上周在硅谷開會，這我是第一次跟“hack3rs”的創(chuàng)業(yè)狂以及技術(shù)狂們打交道纠修。我學會了很多前所未聞的臟話胳嘲，也有所得–即便是追求精簡的初創(chuàng)企業(yè)也傾向于把問題過份復(fù)雜化。
將真正領(lǐng)悟精簡精神的人甄別出來并不困難扣草。谷歌了牛，F(xiàn)acebook以及Akamai的程師們的講座魅力十足。他們從一個更宏觀的角度思考和解決問題德召。這跟公司的財力白魂，規(guī)模沒有關(guān)系，他們特意剪除細枝末節(jié)上岗，以便將注意力集中在問題的根本。
我自己也曾一味要求手下考慮使用高級編程語言甚至全面向?qū)ο笳Z言蕴坪，我發(fā)現(xiàn)許多的新時代初創(chuàng)企業(yè)也還沒領(lǐng)悟其精髓肴掷。他們用Javascript、Python和Ruby編程背传，卻不明白為什么要用這些語言呆瞻。
不可否認，把循環(huán)寫得緊湊或者避免使用模板固有其道理径玖。但如果這是你選擇一門編程語言的唯一理由痴脾，那么你就大錯特錯了。日常工作中梳星，與其用基于深度優(yōu)化的向量化C++語言構(gòu)建的多核并行異步map-reduce架構(gòu)去做一個卷積離散傅立葉變換（correlation-DFT）赞赖，我寧愿用BASIC來做一個快速傅立葉變換（FFT）。
那么到底應(yīng)該根據(jù)什么來選擇編程語言呢冤灾？唯一檢驗標準：是否言而達意前域。
拋開語言的執(zhí)行效率和功能等等不談，一門語言必須能夠讓你描述自己的意圖韵吨，不光是對編譯器而言匿垄，更是對未來的讀者而言。我相信軟件維護中99%的問題都是由于最初寫代碼的人沒能準備表述他們的意圖造成的。如果言不達意椿疗，文檔就不叫文檔漏峰。如果言不達意，UML圖就不是UML圖届榄。如果無法描述某種數(shù)據(jù)型適用于哪些操作符的話芽狗，面向?qū)ο缶幊叹筒皇敲嫦驅(qū)ο缶幊獭Ｑ远_意不是指C風格的ModifyWindowEx（HWND wnd）不易讀而Window.modify（）告訴了你和編譯器這個window可以和不可以做什么痒蓬。關(guān)鍵是要表明你的意圖童擎。
Fortran如今已大大落后，因為它用下面這種方式描述一個算式：
MOV AX,$5DADD AX,$6FMOV$7F, AX
其實完全可以寫成這樣：
c=a+b
如此你就知道是a加上b攻晒，結(jié)果存到c顾复，即便你不懂計算機也能看懂。
一個常見的誤解是：函數(shù)式編程語言表達你要什么（what you want）而命令式編程語言表達你想怎樣（how you want）鲁捏。
這是一種糟糕的理解芯砸。因為有時候“你想怎樣”恰恰是你想表達的意思。
按照我一貫的博文風格给梅，請你問自己一個基本問題假丧，當面臨語言的選擇時：
“我是否把意思說清楚了？”
如果你無法回答這個問題动羽，那么你沒有用最佳語言包帚。如果你不得不寫文檔或者做注釋，這說明你的代碼沒能描述你的意圖运吓】拾睿看看這個函數(shù)原型：
char*reverseString(constchar*foo);
在缺少關(guān)于空指針，空字符串以及其他異常處理文檔的幫助下拘哨，根本沒法理解作者到底想干什么谋梭。這不太好。當然倦青，函數(shù)內(nèi)部可能對輸入做了無數(shù)的驗
證瓮床，但你必須寫一堆針對各種特定輸入的單元測試以確保你的假設(shè)是正確的。
我所指的“把意思說清楚”是什么意思呢产镐？假設(shè)C++在原型中支持以下虛擬語法：
char*@NullablereverseString(@NonNullableconstchar*foo);
函數(shù)原型中加上這些注解有兩個好處：
1. 你不需要事先測試foo是不是null隘庄。編譯器保證會給你一個非null。
2. 明確地告訴調(diào)用者你不容忍null磷账。這種表述方式編譯器能夠明白峭沦，優(yōu)秀的靜態(tài)分析工具可以檢測到這類bug，這是C語言做不到的逃糟。
雖然這看起來只不過是增強了一下語法吼鱼，實際不僅如此蓬豁，它還增強了語義。如此不論是人或是機器就明白foo這個變量不可為null菇肃，否則函數(shù)很生氣地粪，后果很嚴重。而且琐谤，你給這個函數(shù)劃定了界限蟆技，再不用擔心foo可否為null了。
函數(shù)式編程并不是萬金油：
大家對我的另外一個常見誤解是我推崇純函數(shù)式語言斗忌。我的確有理由喜歡它們质礼。看到上面那個式子了嗎织阳？
c=a+b
如果我想把expr1和expr2的值相加該如何表達呢眶蕉？
c=(expr1)+(expr2)
如果expr1有附加操作而且會影響expr2的值又該如何表達呢？這并不罕見：
c=(a++)+(a+b);
這里的問題不是你想的那樣唧躲。我知道你在想什么：“天知道這門語言會如何解釋這個式子造挽。萬一計算的順序反了怎么辦？”
你想錯了弄痹。正是由于人們會產(chǎn)生那樣的想法饭入，編程語言才會有這樣的特點。要解答你的疑問很簡單肛真，看看編譯手冊就知道了谐丢。
上面式子的根本問題是我無法知道那樣的計算順序是偶然的還是有意的。我確切地知道上面式子的會做什么毁欣，但我無法確定的是庇谆，它的計算順序是不是有意的？我能不能優(yōu)化那個式子凭疮，放到一個循環(huán)里去？我能不能在多核多線程的情況下調(diào)用它串述？假設(shè)有人問我执解，如果給z賦值10而不是20，會不會影響c的值纲酗，我無法回答衰腌。
理論上是無法回答上面那個問題的。當然了我們可以根據(jù)經(jīng)驗做加一些斷言（assertion）觅赊。在斷言出了一堆或者一個警告后右蕊，理性地說，我們?nèi)匀徊恢纙會不會影響a或者b吮螺，最終影響到c饶囚。
為什么這很重要
代碼的可維護性是建立在代碼的可閱讀性的基礎(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程序員而言瞄崇，我的建議是，如果你真想超凡脫俗的話壕曼，學學谷歌和Facebook苏研。他們使用一些實驗性技術(shù)，并不是為了取代for-loops腮郊，而是用來表明for-loops的意圖摹蘑。快速原型的話選擇簡單的語言就可以了轧飞，當需要準確描述意圖的時候才考慮更換編程語言衅鹿。
命令式語言的必要性：
最后，我想解釋一下為什么命令式語言是必要的过咬〈蟛常看看下面這個驅(qū)動程序例子：
setlpt1(00000000b);setlpt1(00010000b);setlpt1(00000000b);
這是我假想的串口命令協(xié)議。這幾行代碼是按照先后順序排列的掸绞。哪怕200年以后泵三，它們的意圖也不會發(fā)生什么變化。必要的時候使用命令型語言衔掸，明確地告訴讀者不要打亂這些代碼烫幕。你不應(yīng)該改變它們的順序。你也不會把他們用在某些抽象的端口上敞映，它們只適用于串口或者所謂打印機口较曼。
用函數(shù)式語言來實現(xiàn)上面的功能，并且加上同步原語來保證它們按照順序運行振愿，是愚蠢的捷犹。
結(jié)論：
如果說這篇文章有一點點值得總結(jié)的東西的話弛饭，那便是：下次你寫任何代碼/規(guī)范/程序的時候，問問自己伏恐，意圖是否清楚表達孩哑？未來的維護者看到你寫的東西，是否能明白它
八戒推薦2
來源：Be Geek
