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