程序設(shè)計離不開編程語言，但是編程語言在國內(nèi)的大環(huán)境中似乎一直是個二等公民，許多人也認(rèn)為，語言的討論完全是不入流的，但其實編程語言與工具、框架或開發(fā)方法等一樣，都對生產(chǎn)力有著重要的影響。

　　事實上，語言的發(fā)展歷史比其他方面更為悠久，并且在過去十幾年，甚至最近幾年中都依然在不斷的碰撞和演變。期間一些新的語言誕生了，而另一些在當(dāng)時看來陽春白雪的語言和編程范式也重新獲得了重視。

　　anders hejlsberg是微軟的technical fellow，擔(dān)任c#編程語言的首席架構(gòu)師，也參與了.net framework、vb.net和f#等語言的設(shè)計與開發(fā)，《delphi與c#之父：技術(shù)理想架構(gòu)開發(fā)傳奇》一文詳細(xì)介紹了anders hejlsberg在微軟的編程傳奇之路。

　　幾個月前，anders在比利時techdays 2010及荷蘭devdays 2010分別作了一場演講，闡述了他眼中的編程語言的發(fā)展趨勢及未來方向，本文便對他的觀點進(jìn)行了總結(jié)。

　　大約25~30年前，anders開發(fā)了著名的turbo pascal，這是一套集語言、編譯器及開發(fā)工具于一體的產(chǎn)品，也是anders進(jìn)入編程語言領(lǐng)域的起點。anders談到，當(dāng)年turbo pascal所用的z-80和如今的計算機(jī)已經(jīng)不可同日而語。與那時相比，如今的機(jī)器已經(jīng)有大約10萬倍的外部存儲容量，1萬倍的內(nèi)存大小，cpu速度也有大約1000倍的提高。但是，如果我們比較如今的java代碼及當(dāng)年的pascal代碼，會發(fā)現(xiàn)它們的差別其實并不大。

　　anders認(rèn)為編程語言的發(fā)展非常緩慢，期間當(dāng)然出現(xiàn)了一些東西，例如面向?qū)ο蟮?，但是遠(yuǎn)沒有好上1000倍。事實上，近幾十年來的努力主要體現(xiàn)在框架及工具等方面(如圖1)。例如.net framework里有超過一萬個類和十萬個方法，與turbo pascal相比的確有了超過1000倍的增長。類似的，現(xiàn)在的ide包含了無數(shù)強大的功能，例如語法提示、重構(gòu)、調(diào)試器等。與此相比，編程語言的改進(jìn)的確很不明顯。

　　在過去50~60年的編程歷史中，編程語言的抽象級別不斷提高，人們都在努力讓編程語言更有表現(xiàn)力，這樣就可以用更少的代碼完成更多的工作。我們一開始使用匯編，然后使用面向過程的語言(如pascal和c)，然后是面向?qū)ο笳Z言(如c++)，隨后便進(jìn)入了托管時代，語言運行于受托管的執(zhí)行環(huán)境上(如c#和java)，它們的主要特性有自動垃圾收集、類型安全等。anders認(rèn)為這樣的趨勢還會繼續(xù)下去，還會有抽象級別越來越高的語言。另一方面，編程語言往往都傾向于構(gòu)建于現(xiàn)有的工具上，而不會從頭寫起?，F(xiàn)在出現(xiàn)的編程語言，例如f#、scala和clojure等，都是基于現(xiàn)有框架構(gòu)建的，每次從頭開始的代價實在太高。

　　在anders眼中，如今影響力較大的趨勢主要有三個(如圖2)，分別是聲明式的編程風(fēng)格(包括領(lǐng)域特定語言、函數(shù)式編程)、動態(tài)語言(最重要的方面是元編程能力)以及多核環(huán)境下的并發(fā)編程。此外隨著語言的發(fā)展，原本常用的面向?qū)ο笳Z言、動態(tài)語言或是函數(shù)式等邊界也變得越來越模糊，例如各種主要的編程語言都受到函數(shù)式語言的影響。因此，多范式程序設(shè)計語言也是一個愈發(fā)明顯的趨勢。

　　聲明式編程與dsl

　　目前常見的編程語言大都是命令式(imperative)的，例如c#、java或c++等。這些語言的特征在于，代碼里不僅表現(xiàn)了“做什么(what)”，而更多表現(xiàn)出“如何(how)完成工作”這樣的實現(xiàn)細(xì)節(jié)，例如for循環(huán)、i += 1等，甚至這部分細(xì)節(jié)會掩蓋我們的最終目標(biāo)。

　　在anders看來，命令式編程通常會讓代碼變得十分冗余，更重要的是由于它提供了過于具體的指令，這樣執(zhí)行代碼的基礎(chǔ)設(shè)施(如clr或jvm)沒有太多發(fā)揮空間，只能老老實實地根據(jù)指令一步步地向目標(biāo)前進(jìn)。例如，并行執(zhí)行程序會變得十分困難，因為像“執(zhí)行目的”這樣更高層次的信息已經(jīng)丟失了。因此，編程語言的趨勢之一，便是能讓代碼包含更多的“what”，而不是“how”，這樣執(zhí)行環(huán)境便可以更加聰明地去適應(yīng)當(dāng)前的執(zhí)行要求。

　　關(guān)于聲明式的編程風(fēng)格，anders主要提出了兩個方面，第一個方面是dsl(domain specific language，領(lǐng)域特定語言)。dsl不是什么新鮮的玩意兒，我們平時經(jīng)常接觸的sql、css、正則表達(dá)式等都屬于dsl。有的dsl可能更加專注于一個方面，例如mathematica、logo等。這些語言的目標(biāo)都是特定的領(lǐng)域，與之相對的則是gppl(general purpose programming language，通用目的編程語言)。

　　martin fowler將dsl分為外部dsl和內(nèi)部dsl兩種。外部dsl有自己的特定語法、解析器和詞法分析器等，它們往往是一種小型的編程語言，甚至不會像gppl那樣需要源文件。與之相對的則是內(nèi)部dsl。內(nèi)部dsl其實更像是種別稱，它代表一類特別api及使用模式。

　　xslt、sql等都可以算作是外部dsl。外部dsl一般會直接針對特定的領(lǐng)域設(shè)計，而不考慮其他方面。james gosling曾經(jīng)說過：每個配置文件最終都會變成一門編程語言。一開始你可能只會用它表示一點點東西，慢慢地你便會想要一些規(guī)則，而這些規(guī)則則變成了表達(dá)式，后來你可能還會定義變量，進(jìn)行條件判斷等，而最終它就變成了一種奇怪的編程語言。這樣的情況屢見不鮮?，F(xiàn)在有一些公司也在關(guān)注dsl的開發(fā)。

　　例如以前在微軟工作的charles simonyi提出了intentional programming的概念，還有jetbrains公司提供了叫做mps(meta programming system)的產(chǎn)品。最近微軟也提出了自己的oslo項目，而在eclipse世界里也有xtext，所以如今在這方面已經(jīng)有不少嘗試。由于外部dsl的獨立性，在某些情況下也會出現(xiàn)特定的工具，輔助領(lǐng)域?qū)＜一蚴情_發(fā)人員編寫dsl代碼。還有一些dsl會以xml方言的形式提出，利用xml方言的好處在于有不少現(xiàn)成的工具可用，這樣可以更快地定義自己的語法。

　　內(nèi)部dsl往往只代表一系列特別的api及使用模式，例如linq查詢語句及ruby on rails中的active record聲明代碼等。內(nèi)部dsl可以使用一系列api來“偽裝”成一種dsl，利用一些流暢化的技巧，例如像jquery那樣把一些方法通過“點”連接起來，而另一些也會利用元編程的方式。內(nèi)部dsl還有一些優(yōu)勢，例如可以訪問語言中的代碼或變量，以及利用代碼補全、重構(gòu)等母語言的所有特性。

　　dsl的可讀性往往很高。例如，要篩選出單價大于20的產(chǎn)品，并對所屬種類進(jìn)行分組，降序列出每組的分類名稱及產(chǎn)品數(shù)量。如果是用命令式的編程方式，可能是這樣的：

　　var groups = new dictionary(); foreach (product p in products) { if (p.unitprice >= 20) { if (!groups.containskey(p.categoryname)) { grouping g = new grouping(); g.name = p.categoryname; g.count = 0; groups[p.categoryname] = g; } groups[p.categoryname].productcount++; } } var result = new list(groups.values); result.sort(delegate(grouping x, grouping y) { return x.count > y.count ? -1 : x.count < y.count ? 1 : 0; });

　　顯然這些代碼編寫起來需要一點時間，且很難直接看出它的真實目的，換言之，“what”幾乎完全被“how”所代替了。這樣，一個新的程序員必須花費一定時間才能理解這段代碼的目的。但如果使用linq，代碼便可以改寫成：

　　var result = products where(p => p.unitprice >= 20) groupby(p => p.categoryname) orderbydescending(g => g.count()) select(g => new { name = g.key, count = g.count() });

　　這段代碼更加關(guān)注的是“how”而不是“what”，它不會明確地給出過濾的操作方式，也沒有涉及到創(chuàng)建字典這樣的細(xì)節(jié)。這段代碼還可以利用c# 3.0中內(nèi)置的dsl，即linq查詢語句來改寫：

　　var result = from p in products where p.unitprice >= 20 group p by p.categoryname into g orderby g.count() descending select new { name = g.key, count = g.count() };

　　編譯器會簡單地將linq差距語句轉(zhuǎn)化為前一種形式。這段代碼只是表現(xiàn)出最終的目的，而不是明確指定做事的方式，這樣便可以很容易地并行執(zhí)行這段代碼，如使用pinq則幾乎不需要做出任何修改。

　　函數(shù)式編程

　　anders提出的另一個重要的聲明式編程方式便是函數(shù)式編程。函數(shù)式編程歷史悠久，如當(dāng)年的lisp便是函數(shù)式編程語言。除了lisp以外還有其他許多函數(shù)式編程語言，如apl、haskell、ml等。函數(shù)式編程在學(xué)術(shù)界已經(jīng)有過許多研究，大約在5~10年前許多人開始吸收和整理這些研究內(nèi)容，想要把它們?nèi)谌敫鼮橥ㄓ玫木幊陶Z言?，F(xiàn)在的編程語言，如c#、python、ruby、scala等，都受到了函數(shù)式編程語言的影響。

　　使用命令式編程語言寫程序時，我們經(jīng)常會編寫如x = x + 1這樣的語句，此時我們大量依賴的是可變狀態(tài)，或者說是變量，它們的值可以隨程序運行而改變，可變狀態(tài)非常強大，但隨之而來的便是“副作用”問題，例如一個無需參數(shù)的void方法，它會根據(jù)調(diào)用次數(shù)或是在哪個線程上進(jìn)行調(diào)用對程序產(chǎn)生影響，它會改變程序內(nèi)部的狀態(tài)，從而影響之后的運行效果。而在函數(shù)式編程中則不會出現(xiàn)這個情況，因為所有的狀態(tài)都是不可變的。事實上對函數(shù)式編程的討論更像是數(shù)學(xué)、公式，而不是程序語句，如x = x + 1對于數(shù)學(xué)家來說，似乎只是個永不為真的表達(dá)式而已。

　　函數(shù)式編程十分容易并行，因為它在運行時不會修改任何狀態(tài)，因此無論多少線程在運行時都可以觀察到正確的結(jié)果。假如兩個函數(shù)完全無關(guān)，那么它們是并行還是順序執(zhí)行便沒有什么區(qū)別。

　　當(dāng)然，現(xiàn)實中的程序一定是有副作用的，例如向屏幕輸出內(nèi)容，向socket傳輸數(shù)據(jù)等，因此真實世界中的函數(shù)式編程往往都會考慮如何將有副作用的代碼分離出來。函數(shù)式編程默認(rèn)是不可變的，開發(fā)人員必須做些額外的事情才能使用可變狀態(tài)或是危險的副作用，與之相反，c#或java必須使用readonly或final來做到這一點。此時，使用函數(shù)式編程語言時的思維觀念便會有所不同。