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