每個(gè)人都在想為什么在這個(gè)世界大家都在選擇靜態(tài)語言，當(dāng)你準(zhǔn)備選擇一門動態(tài)語言的時(shí)候，卻又冒出了如此多的兄弟。我們通?？紤]的是哪種語言是我熟練的那就拿它來做這項(xiàng)工作?？傊@做不失為一種著手開干得好方法?，F(xiàn)在還有別的什么影響你的選擇嗎？測試？開發(fā)速度？還是程序的健壯性？

動態(tài)型  VS  靜態(tài)型

動態(tài)語言是一種變量使用前不需要聲明的語言，如 Python、Ruby 和PHP，在動態(tài)語言中像下面這樣做是允許的。

num = 10 

某種意義上來說，這卻是一把雙刃劍，因?yàn)閯討B(tài)語言的類型檢查是在程序運(yùn)行期間，代碼運(yùn)行前沒有任何辦法找出 bug。我知道你可以寫測試，但是你并不能測試任何事情。這里有一個(gè)雖然不重要的例子。

def get_first_problem(problems):  
    for problem in problems:  
        problam = problem + 1 
        return problam 

現(xiàn)在如果你被一些嚴(yán)重的電子樂干擾著，一個(gè)縮進(jìn)的錯誤很輕易的就忽略了，代碼弄完了然后部署到生產(chǎn)環(huán)境中，于是bug就接踵而來了。

記住，在生產(chǎn)環(huán)境中你是***能消滅bug的人。

靜態(tài)語言 ：使用前變量需要聲明，編譯的時(shí)候需要類型檢查，包括Java、C、C++在內(nèi)的語言都是靜態(tài)語言。

static int awesomeNumber;  
awesomeNumber = 10; 

關(guān)于健壯性的增加和運(yùn)行時(shí)錯誤機(jī)會的減少有很多的爭論，編譯器能捕獲一些在你編碼的時(shí)候產(chǎn)生的令人討厭的錯誤，方法的契約是嚴(yán)格的，不好的地方就是沉重的樣板代碼。

弱類型 VS 強(qiáng)類型

弱類型和強(qiáng)類型經(jīng)常與動態(tài)語言和靜態(tài)語言混淆起來。弱類型語言會引起一些哲學(xué)性問題如數(shù)字2和字符”two“的相加，在弱類型語言中像這樣做是沒問題的。

a = 2 
b = "2" 
   
concatenate(a, b) // Returns "22"  
add(a, b) // Returns 4 

傳統(tǒng)的語言將嚴(yán)格限制各種事務(wù)的出現(xiàn)，如強(qiáng)類型語言中字符與整型相加將導(dǎo)致錯誤，如下：

>>> a = 10 
>>> b = 'ten' 
>>> a + b  
Traceback (most recent call last):  
  File "<stdin>", line 1, in <module>  
TypeError: unsupported operand type(s) for +: 'int' and 'str' 
>>> 

總結(jié)：

無論你在哪抨擊這篇討論，聲明總比前者好，因?yàn)榍罢邥?dǎo)致一場語言的戰(zhàn)爭。

動態(tài)語言適合快速周期開發(fā)和原型設(shè)計(jì)。靜態(tài)語言更適合長期的開發(fā)周期，零碎的bug非常會付出非常高的代價(jià)（電話通信系統(tǒng)，航空交通系統(tǒng)）例如，如果一巨頭公司叫Moo Corp，花了幾百萬美元在做QA和測試，一bug以某種方式陷入在這個(gè)領(lǐng)域中，為了修復(fù)意味著另一個(gè)輪的測試。當(dāng)你做在板凳上你要做的就是選擇一種簡潔的靜態(tài)語言，這項(xiàng)工作的難度就是得有人做”擠奶”的事。

測試、測試、還是測試

僅僅就一點(diǎn)點(diǎn)資料為了用來思考、啟動下一個(gè)項(xiàng)目，你從來就不知道哪些限制你可能放在你自己和你的團(tuán)隊(duì)身上。

當(dāng)你為你的項(xiàng)目選擇一門編程語言時(shí)，你考慮的因素有哪些呢？

英文原文：Sachin FromDev

本文轉(zhuǎn)自：http://blog.jobbole.com/21559/