動態(tài)語言會淘汰靜態(tài)語言嗎？
51CTO之前曾報道了《洞察動態(tài)語言與靜態(tài)語言之爭》，這并不表示動態(tài)語言全面的優(yōu)于靜態(tài)語言，更不表示靜態(tài)語言會被動態(tài)語言全面的取代。進(jìn)一步，這里想簡單的說一下，靜態(tài)語言相對的優(yōu)越性，和存在意義。
這里首先要表達(dá)一下觀點：計算機不會魔法。具體來說兩方面，一是離機器越近，性能上越有可能達(dá)到更快；二是目前的機器模型，總是以線性方式管理數(shù)據(jù)的（值得吐槽的是在操作系統(tǒng)以上，文件分區(qū)系統(tǒng)也總是這樣干的，更底層能否以哪怕是極座標(biāo)方式，直接在二／三維空間上定位訪問，而非扇區(qū)、柱面、簇這種形式，我不清楚，有待方家指點）。
線性管理信息帶來的效應(yīng)就是：基于線性數(shù)據(jù)結(jié)構(gòu)，或以地址訪問信息的編程工具，通常來說會比基于字典結(jié)構(gòu)的更快，至少有更大的優(yōu)化空間。而靜態(tài)語言的話，編譯時我們已經(jīng)確定了對象的結(jié)構(gòu)和尺寸（動態(tài)尺寸的內(nèi)容可以通過引用管理），這是動態(tài)語言無法做到的。動態(tài)語言的對象結(jié)構(gòu)，總是基于字典結(jié)構(gòu)，要兼顧對象結(jié)構(gòu)在運行時發(fā)生改變的問題。這使得它的數(shù)據(jù)管理總是要比直接地址訪問要多上那么一層。這也是甚少見到動態(tài)語言編譯器的原因。
流行的動態(tài)語言，幾乎都是解釋／字節(jié)碼平臺，甚至，最常見的Python/Ruby等等語言，幾乎都有飽受批評的GIL（Global Interpreter Lock）。以 Python 社區(qū)的經(jīng)驗來說，多年來出現(xiàn)的數(shù)個無GIL的C-Python 實現(xiàn)，單核性能都不如現(xiàn)在的官方版本。Jython和IronPython則是得益于JVM和 CLR，這兩個久經(jīng)經(jīng)考驗的虛擬機平臺，它們的first-class language 都是靜態(tài)編譯型語言（盡管其主流編譯器生成的是字節(jié)碼，但是通常我們都視Java和C#為編譯語言）。
為Perl社區(qū)期待多年的Perl 6 ，至今還沒有真正的發(fā)布（其虛擬機Parrot雖然已經(jīng)發(fā)布，但受制于主力語言實現(xiàn)進(jìn)度，現(xiàn)在還沒有得到足夠的實戰(zhàn)驗證）。為動態(tài)語言實現(xiàn)一個高性能的，特別是并行的高性能環(huán)境，難度之高，可見一斑。
根本上說，在當(dāng)前的硬件模型上，想要以非線性的方式管理信息，動態(tài)伸縮，動態(tài)修改結(jié)構(gòu)，非常的不容易。舉一個例子，候捷老師有一個講座，是以windows 95為例，詳細(xì)講解malloc/free的底層實現(xiàn)，有聽過的朋友應(yīng)該對操作系統(tǒng)動態(tài)管理內(nèi)存資源的復(fù)雜程度有所體會。
這類問題涉及比較深入的底層問題，我不是科班出身，這方面比較外行，講的不是很好，不過有興趣的朋友可以深究一下，會發(fā)現(xiàn)這事兒比看起來要麻煩得多。想要讓動態(tài)語言達(dá)到靜態(tài)化的性能，是件相當(dāng)有挑戰(zhàn)的事。Google的 Protocol Buffer 協(xié)議，也是基于靜態(tài)模型的。
現(xiàn)代的靜態(tài)語言，搞了很好的“偽裝”，使它寫起來可以非常的有“動感”，例如 C#3，Scala等，但究其本質(zhì)，它們代碼中涉及的類型，仍然是可以編譯期確定的。我所接觸過的語言中，此類功能最有歷史的應(yīng)該是Haskell，而它是通過一個非常嚴(yán)苛的數(shù)學(xué)體系來推導(dǎo)類型，在此過程中，還是時有需要程序員顯式聲明函數(shù)類型，才能完成編譯。
靜態(tài)語言在變得越來越友好敏捷，動態(tài)語言在越來越快，但是兩者之間的分界，仍然相當(dāng)?shù)那逦o態(tài)語言更快，更具優(yōu)化潛力。動態(tài)語言更靈活，更具表達(dá)能力。這是兩者不能被互相取代的根本原因。
當(dāng)然，性能問題并不簡單，動態(tài)語言在宏觀上往往沒有具部的測試結(jié)果看起來那么慢，這是因為要表達(dá)復(fù)雜的業(yè)務(wù)邏輯，往往需要復(fù)雜的數(shù)據(jù)結(jié)構(gòu)和訪問代碼，這些復(fù)雜的數(shù)據(jù)內(nèi)容，要隨著用戶的訪問不斷變化。要實現(xiàn)這一切，如果使用靜態(tài)語言，就要關(guān)注動態(tài)數(shù)據(jù)結(jié)構(gòu)的實現(xiàn)，如果使用的是沒有GC的開發(fā)技術(shù)，還要關(guān)注內(nèi)存資源的回收，確實會出現(xiàn)繞了一大圈兒，結(jié)果實現(xiàn)的系統(tǒng)還沒有現(xiàn)成的動態(tài)語言快的現(xiàn)像（盡管這不是普遍的）。更何況現(xiàn)實中總是以線性讀寫的IO接口，更嚴(yán)重拉平了不同語言之間的性能差異。所以現(xiàn)在比較得到認(rèn)可的實現(xiàn)方式往往是以動態(tài)語言實現(xiàn)項目，然后，如果有需求，也有這個成本負(fù)擔(dān)，就以靜態(tài)語言優(yōu)化性能瓶頸。
當(dāng)然，上述的模式往往用在服務(wù)器型的項目中，在GUI環(huán)境中，要與顯示器、鼠標(biāo)鍵盤等人機交互環(huán)境頻繁的互動，這個資源付出非常的大，加上在CPP等靜態(tài)語言大行的時代，GUI開發(fā)已經(jīng)相當(dāng)成熟，技術(shù)力量沉積的歷史原因，這個領(lǐng)域仍然是以靜態(tài)的、編譯型的語言為主力。最多是為了提交二次開發(fā)能力，提供動態(tài)語言調(diào)用的接口，或嵌入一個解釋環(huán)境，有限的利用。
其實即使是服務(wù)器環(huán)境，隨著互聯(lián)網(wǎng)的發(fā)展，性能問題也正在越來越突出。我就遇到過某個簡單邏輯的功能，使用Python怎樣都無法優(yōu)化到理想的程度，最終用Objective C寫了一個nginx模塊。另一方面說Objective C這樣的語言已經(jīng)相當(dāng)?shù)膭討B(tài)化，使用它的字典結(jié)構(gòu)，要比用C方便的多，在二進(jìn)制上又可以完全兼容于C，在性能和空間付出上，明顯可以觀察到比大多C的字典結(jié)構(gòu)，要多付出一些性能代價。計算機沒有魔法，人得到便利，總是要付出一些計算資源。把它盡可能的貼近理想，是技術(shù)人員的目標(biāo)。
越來越多的大型架構(gòu)，要求我們不僅以模塊、連接庫和函數(shù)接口的層面思考問題，更多的要考慮實際運行時的，運行實例和服務(wù)器的行為。我們不但需要附件齊備的運行時環(huán)境，也需要可以直達(dá)硬件的，高速有效的工具。包括開發(fā)一些不那么動態(tài)但是更快速的定制服務(wù)環(huán)境，也成為一個越來越常見的需求。
雖然編程語言在發(fā)展，我們有更多，更強大的方式來表達(dá)我們的思維，但是隨著用戶量、商業(yè)模式和服務(wù)方式的迅速變化，新的挑戰(zhàn)也不斷出現(xiàn)。對于職業(yè)的IT開發(fā)團(tuán)隊，我們在面對更多的挑戰(zhàn)。我們需要更為豐富的技術(shù)組合，指望一種技術(shù)一統(tǒng)天下，即使局限于互聯(lián)網(wǎng)應(yīng)用這個領(lǐng)域，也仍然是一個奢望。這十年來動態(tài)語言的興起，其實是在補過去邏輯表達(dá)方面不足的功課，這是硬件發(fā)展帶來的有限的福利，但是硬件資源永遠(yuǎn)是快速發(fā)展，但卻不足使用。
動態(tài)語言和靜態(tài)語言組合使用，兼顧高效開發(fā)與高性能的效果，在目前可以預(yù)見的未來，仍然是比較實際的思路。
原文鏈接：http://blog.csdn.net/ccat/archive/2011/01/04/6116088.aspx
【編輯推薦】
