動(dòng)態(tài)語言和靜態(tài)語言的比較

一 、靜態(tài)語言的優(yōu)勢(shì)到底在哪？

來自robbin 摘自 http://www.javaeye.com/article/33971?page=7

引用

是像Java或者C＃這樣強(qiáng)類型的準(zhǔn)靜態(tài)語言在實(shí)現(xiàn)復(fù)雜的業(yè)務(wù)邏輯、開發(fā)大型商業(yè)系統(tǒng)、以及那些生命周期很長(zhǎng)的應(yīng)用中也有著非常強(qiáng)的優(yōu)勢(shì)

 

這是一個(gè)存在于大家心里常識(shí)了。我承認(rèn)我自己在潛意識(shí)里面也覺得靜態(tài)強(qiáng)類型語言適合開發(fā)復(fù)雜，大型系統(tǒng)。而弱類型腳本語言不適合開發(fā)太復(fù)雜，太大型的項(xiàng)目。但是在參與這個(gè)討論過程中，我突然開始置疑這個(gè)觀點(diǎn)，事實(shí)究竟是不是這樣的呢？

先定義一下標(biāo)準(zhǔn)：

強(qiáng)類型語言(靜態(tài)類型語言)是指需要進(jìn)行變量/對(duì)象類型聲明的語言，一般情況下需要編譯執(zhí)行。例如C/C++/Java/C#

弱類型語言(動(dòng)態(tài)類型語言)是指不需要進(jìn)行變量/對(duì)象類型聲明的語言，一般情況下不需要編譯(但也有編譯型的)。例如PHP/ASP/Ruby/Python/Perl/ABAP/SQL/JavaScript/Unix Shell等等。

 

引用

觀點(diǎn)一：靜態(tài)類型語言因?yàn)轭愋蛷?qiáng)制聲明，所以IDE可以做到很好的代碼感知能力，因?yàn)橛蠭DE的撐腰，所以開發(fā)大型系統(tǒng)，復(fù)雜系統(tǒng)比較有保障。

 

對(duì)于像Java來說，IDEA/Eclipse確實(shí)在代碼感知能力上面已經(jīng)非常強(qiáng)了，這無疑能夠增加對(duì)大型系統(tǒng)復(fù)雜系統(tǒng)的掌控能力。但是除了Java擁有這么強(qiáng)的IDE武器之外，似乎其他語言從來沒有這么強(qiáng)的IDE。C#的Visual Studio在GUI開發(fā)方面和Wizard方面很強(qiáng)，但是代碼感知能力上和Eclipse差的不是一點(diǎn)半點(diǎn)。至于Visual C++根本就是一個(gè)編譯器而已，羞于提及Visual這個(gè)字眼。更不要說那么多C/C++開發(fā)人員都是操起vi吭哧吭哧寫了幾十萬行代碼呢。特別是像Linux Kernel這種幾百萬行代碼，也就是用vi寫出來的阿，夠復(fù)雜，夠大型，夠長(zhǎng)生命周期的吧。

 

引用

觀點(diǎn)二：靜態(tài)語言相對(duì)比較封閉的特點(diǎn)，使得第三方開發(fā)包對(duì)代碼的侵害性可以降到很低。動(dòng)態(tài)語言在這點(diǎn)上表現(xiàn)的就比較差，我想大家都有過從網(wǎng)上下載某個(gè)JS包，然后放到項(xiàng)目代碼里發(fā)生沖突的經(jīng)歷

 

也就是說靜態(tài)類型語言可以保障package的命名空間分割，從而避免命名沖突，代碼的良好隔離性。但是這個(gè)觀點(diǎn)也缺乏說服力。

靜態(tài)類型語言中C,VB都缺乏良好的命名空間分割，容易產(chǎn)生沖突，但是并沒有影響他們做出來的系統(tǒng)就不夠大，不夠復(fù)雜。

而Visual C++開發(fā)的DLL版本沖突也是臭名昭著的，似乎C++的命名空間沒有給它帶來很大的幫助。

而動(dòng)態(tài)類型語言中Ruby/Python/Perl都有比較好的命名空間，特別是Python和Perl，例如CPAN上面的第三方庫(kù)成噸成噸的，也從來沒有聽說什么沖突的問題。

誠(chéng)然像PHP，JavaScript這樣缺乏命名空間的動(dòng)態(tài)語言很容易出現(xiàn)問題，但是這似乎是因?yàn)樗麄內(nèi)狈O機(jī)制導(dǎo)致的，而不是因?yàn)樗麄儎?dòng)態(tài)類型導(dǎo)致的吧？

說到大型系統(tǒng)，復(fù)雜業(yè)務(wù)邏輯系統(tǒng)，Google公司很多東西都是用python開發(fā)的，這也證明了動(dòng)態(tài)類型語言并非不能做大型的復(fù)雜的系統(tǒng)。其實(shí)我個(gè)人認(rèn)為：

動(dòng)態(tài)類型語言，特別是高級(jí)動(dòng)態(tài)類型語言，反而能夠讓人們不需要分心去考慮程序編程問題，而集中精力思考業(yè)務(wù)邏輯實(shí)現(xiàn)，即思考過程即實(shí)現(xiàn)過程，用DSL描述問題的過程就是編程的過程，這方面像Unix Shell，ruby，SQL，甚至PHP都是相應(yīng)領(lǐng)域當(dāng)之無愧的DSL語言。而顯然靜態(tài)類型語言基本都不滿足這個(gè)要求。

那靜態(tài)類型語言的優(yōu)勢(shì)究竟是什么呢？我認(rèn)為就是執(zhí)行效率非常高。所以但凡需要關(guān)注執(zhí)行性能的地方就得用靜態(tài)類型語言。其他方面似乎沒有什么特別的優(yōu)勢(shì)。

若干評(píng)論：

1?？纯磞ahoo吧，它是用PHP寫的。給你用JAVA也可能做不出來那樣的性能。

2。我的一點(diǎn)感覺，動(dòng)態(tài)語言足夠靈活，因此雖然它能夠讓人更集中精力思考業(yè)務(wù)邏輯的實(shí)現(xiàn)，同時(shí)也向人工智能的方向走得更近一些，但因此它也更依賴于開發(fā)人員本身的技術(shù)功底，初學(xué)者、中級(jí)開發(fā)者，難以很好的利用它。 而靜態(tài)類型語言，與我們計(jì)算機(jī)教學(xué)的基本科目（c/pascal/basic）延續(xù)性比較好，所以對(duì)于剛畢業(yè)的學(xué)生而言，更好接受和學(xué)習(xí)。因此我覺得還是學(xué)習(xí)/培訓(xùn)/開發(fā)成本占主要因素。一個(gè)不太恰當(dāng)?shù)睦樱簀avascript的正則表達(dá)式，雖然功能強(qiáng)大，但并不易理解和學(xué)習(xí)。一般只能copy/paste來用。所以很多情況下，還是寧愿手寫標(biāo)準(zhǔn)js來處理。

3。我感覺類似Java這樣的強(qiáng)類型的準(zhǔn)靜態(tài)語言還有一個(gè)重要的特點(diǎn)。一旦程序員基本掌握了語法規(guī)則和書寫規(guī)范，寫出來的程序的可讀性會(huì)強(qiáng)很多，因?yàn)樗旧淼南拗聘?。在一個(gè)大型系統(tǒng)中，Team成員之間互相可以知道對(duì)方在寫什么是非常關(guān)鍵的，這也成為了交流的重要基礎(chǔ)。

然而Ruby這樣的語言，雖然看上去更加符合“描述問題即解決問題”，但是對(duì)于同一段邏輯，同樣可以滿足要求，寫法上卻差別很大。我曾經(jīng)見過用1行寫出來的解決數(shù)讀算法的Ruby解法，誰能看懂？

4。我更經(jīng)常見到的是Java程序員屁大點(diǎn)事寫幾百行，Ruby幾行就搞定了

5。靜態(tài)類型語言是指在編譯時(shí)變量的數(shù)據(jù)類型即可確定的語言，多數(shù)靜態(tài)類型語言要求在使用變量之前必須聲明數(shù)據(jù)類型，某些具有類型推導(dǎo)能力的現(xiàn)代語言可能能夠部分減輕這個(gè)要求.
動(dòng)態(tài)類型語言是在運(yùn)行時(shí)確定數(shù)據(jù)類型的語言。變量使用之前不需要類型聲明，通常變量的類型是被賦值的那個(gè)值的類型。
強(qiáng)類型語言是一旦變量的類型被確定，就不能轉(zhuǎn)化的語言。實(shí)際上所謂的貌似轉(zhuǎn)化，都是通過中間變量來達(dá)到，原本的變量的類型肯定是沒有變化的。
弱類型語言則反之，一個(gè)變量的類型是由其應(yīng)用上下文確定的。比如語言直接支持字符串和整數(shù)可以直接用 + 號(hào)搞定。當(dāng)然，在支持運(yùn)算符重載的強(qiáng)類型語言中也能通過外部實(shí)現(xiàn)的方式在形式上做到這一點(diǎn)，不過這個(gè)是完全不一樣的內(nèi)涵
通常的說，java/python都算是強(qiáng)類型的，而VB/Perl/C都是弱類型的.
不過相比于動(dòng)態(tài)/靜態(tài)語言的分類，強(qiáng)類型/弱類型更多的是一個(gè)相對(duì)的概念。

6。如果采用動(dòng)態(tài)語言，單元測(cè)試上的工作量要比靜態(tài)語言的多很多

robbin 回這一條。其實(shí)你忽略了一點(diǎn)，當(dāng)使用類似RoR這樣的框架的時(shí)候，應(yīng)用代碼量是很少的，所以相應(yīng)需要測(cè)試的部分也很少，比使用靜態(tài)類型語言需要測(cè)試的部分少了很多。

另外，缺少單元測(cè)試沒有你說的那么恐怖。我們現(xiàn)在就沒有寫單元測(cè)試，ruby代碼都已經(jīng)有6000多行了，編程也好，排錯(cuò)也好，一樣很輕松，哪有你吹的那么恐怖。

7.商業(yè)系統(tǒng)的復(fù)雜在于組織上交流的困難，一個(gè)大公司，內(nèi)部有個(gè)人能把商業(yè)流程搞得一清二楚就不錯(cuò)了，這個(gè)人還能把過程給軟件人員講清楚那簡(jiǎn)直是可遇不可求的事。這樣用ruby反而有優(yōu)勢(shì)了，可以快速開發(fā)，促進(jìn)交流，開發(fā)出個(gè)模型出來給商務(wù)人員看看，用用，自然交流起來就容易多了。

現(xiàn)在一個(gè)開發(fā)人員的開發(fā)效率比以前高多了，主要原因是因?yàn)殚_發(fā)語言和編譯器的進(jìn)步，這個(gè)趨勢(shì)，只會(huì)繼續(xù)下去，不要抱著過去的教條不放，java也是在不斷改進(jìn)的，加了reflection, 加了assert，加了泛型，下個(gè)版本，也要加腳本支持了。

8.其實(shí)靜態(tài)類型語言，除了性能方面的考量之外，最大的優(yōu)勢(shì)就是可以提供靜態(tài)類型安全，編譯器可以檢查你的每一個(gè)函數(shù)調(diào)用是不是書寫了正確的名字，是不是提供了正確類型的參數(shù)。這樣一個(gè)系統(tǒng)，配合自定義類型的功能，可以讓很多錯(cuò)誤（比許多人想象的要多）在編譯時(shí)就能被發(fā)現(xiàn)和定位。

9.我在slashdot上類似話題的討論上曾經(jīng)看到過有人抱怨動(dòng)態(tài)語言，那個(gè)哥們是從事銀行系統(tǒng)的，大概有10萬行的python代碼，最后因?yàn)榧?xì)小隱錯(cuò)不斷而覺得無法維護(hù)，貌似要轉(zhuǎn)到j(luò)ava平臺(tái)。(如果把slashdot上近兩年來關(guān)于ruby和python的帖子和評(píng)論看一邊,大概還能夠找到這個(gè)跟貼)
從這哥們的描述來看，他的主要問題是沒有單元測(cè)試或者單元測(cè)試沒有達(dá)到語句覆蓋或者更強(qiáng)的弱條件組合覆蓋，從而導(dǎo)致某些非正常流程發(fā)生時(shí)，流經(jīng)這些未被測(cè)試的語句導(dǎo)致語法錯(cuò)誤而最終整個(gè)程序都掛掉.對(duì)于業(yè)務(wù)系統(tǒng)來說，這是非常嚴(yán)重的事情。就像我前面說的那樣，我自己的程序就曾經(jīng)不止一次死在logging語句上，因?yàn)樽畛跷乙膊粶y(cè)試這類語句的可通過性。
至于單元測(cè)試有沒有用，三五人的項(xiàng)目幾千行的代碼是看不出來的。其實(shí)，作坊式開發(fā)照樣能夠做出很多東西來，5年前國(guó)內(nèi)的開發(fā)方式基本上是沒有單元測(cè)試的，照樣也能玩得轉(zhuǎn)。
但是，就我自己的體驗(yàn)而言，雖然我并不遵循TDD，但單元測(cè)試是足夠詳盡的，而這個(gè)測(cè)試網(wǎng)給我的置信度(尤其是在修改代碼和較大規(guī)模重構(gòu)時(shí))是之前不可想象的。我估計(jì)上千行的程序，就能夠在漸增式的單元測(cè)試中嘗到好處。
10.編譯器對(duì)程序員的幫助到底有多大，這個(gè)還是要應(yīng)人而異的。編譯器能查出來的很多都屬于打字錯(cuò)誤，拼寫錯(cuò)誤。對(duì)于robbin來說，即使沒有編譯器，檢查這種錯(cuò)誤也是小菜一碟?？墒菍?duì)于經(jīng)驗(yàn)不是很豐富的程序員來說，情況恐怕就大大不同了。畢竟程序員經(jīng)驗(yàn)方面差異的一個(gè)重要方面就是Debug能力和經(jīng)驗(yàn)的差異。對(duì)高手來說仔細(xì)讀上兩遍程序就能發(fā)現(xiàn)的錯(cuò)誤，對(duì)一些新手來說可能會(huì)花上一兩小時(shí)，這種情況我在實(shí)際項(xiàng)目中碰到很多次了。