來自C#之父的編程語言趨勢預測
程序設計離不開編程語言，但是編程語言在國內(nèi)的大環(huán)境中似乎一直是個二等公民，許多人也認為，語言的討論完全是不入流的，但其實編程語言與工具、框架或開發(fā)方法等一樣，都對生產(chǎn)力有著重要的影響。
事實上，語言的發(fā)展歷史比其他方面更為悠久，并且在過去十幾年，甚至最近幾年中都依然在不斷的碰撞和演變。期間一些新的語言誕生了，而另一些在當時看來陽春白雪的語言和編程范式也重新獲得了重視。
Anders Hejlsberg是微軟的Technical Fellow，擔任C#編程語言的***架構師，也參與了.NET Framework、VB.NET和F#等語言的設計與開發(fā)，有關Anders Hejlsberg的更多報道，歡迎訪問《Delphi與C#之父：技術理想架構開發(fā)傳奇》。
幾個月前，Anders在比利時TechDays 2010及荷蘭DevDays 2010分別作了一場演講，闡述了他眼中的編程語言的發(fā)展趨勢及未來方向，本文便對他的觀點進行了總結。
51CTO推薦閱讀：對話Windows教父：未來編程語言的發(fā)展方向
大約25~30年前，Anders開發(fā)了著名的Turbo Pascal，這是一套集語言、編譯器及開發(fā)工具于一體的產(chǎn)品，也是Anders進入編程語言領域的起點。Anders談到，當年Turbo Pascal所用的Z-80和如今的計算機已經(jīng)不可同日而語。與那時相比，如今的機器已經(jīng)有大約10萬倍的外部存儲容量，1萬倍的內(nèi)存大小，CPU速度也有大約1000倍的提高。但是，如果我們比較如今的Java代碼及當年的Pascal代碼，會發(fā)現(xiàn)它們的差別其實并不大。
Anders認為編程語言的發(fā)展非常緩慢，期間當然出現(xiàn)了一些東西，例如面向?qū)ο蟮?，但是遠沒有好上1000倍。事實上，近幾十年來的努力主要體現(xiàn)在框架及工具等方面。例如.NET Framework里有超過一萬個類和十萬個方法，與Turbo Pascal相比的確有了超過1000倍的增長。類似的，現(xiàn)在的IDE包含了無數(shù)強大的功能，例如語法提示、重構、調(diào)試器等。與此相比，編程語言的改進的確很不明顯。
在過去50~60年的編程歷史中，編程語言的抽象級別不斷提高，人們都在努力讓編程語言更有表現(xiàn)力，這樣就可以用更少的代碼完成更多的工作。我們一開始使用匯編，然后使用面向過程的語言（如Pascal和C），然后是面向?qū)ο笳Z言（如C++），隨后便進入了托管時代，語言運行于受托管的執(zhí)行環(huán)境上（如C#和Java），它們的主要特性有自動垃圾收集、類型安全等。Anders認為這樣的趨勢還會繼續(xù)下去，還會有抽象級別越來越高的語言。另一方面，編程語言往往都傾向于構建于現(xiàn)有的工具上，而不會從頭寫起?，F(xiàn)在出現(xiàn)的編程語言，例如F#、Scala和Clojure等，都是基于現(xiàn)有框架構建的，每次從頭開始的代價實在太高。
在Anders眼中，如今影響力較大的趨勢主要有三個，分別是聲明式的編程風格（包括領域特定語言、函數(shù)式編程）、動態(tài)語言（最重要的方面是元編程能力）以及多核環(huán)境下的并發(fā)編程。此外隨著語言的發(fā)展，原本常用的面向?qū)ο笳Z言、動態(tài)語言或是函數(shù)式等邊界也變得越來越模糊，例如各種主要的編程語言都受到函數(shù)式語言的影響。因此，多范式程序設計語言也是一個愈發(fā)明顯的趨勢。
#p#
聲明式編程與DSL
目前常見的編程語言大都是命令式（Imperative）的，例如C#、Java或C++等。這些語言的特征在于，代碼里不僅表現(xiàn)了“做什么（What）”，而更多表現(xiàn)出“如何（How）完成工作”這樣的實現(xiàn)細節(jié)，例如for循環(huán)、i += 1等，甚至這部分細節(jié)會掩蓋我們的最終目標。
51CTO推薦閱讀：AOP實現(xiàn)原理：從命令式編程和聲明式編程說起
在Anders看來，命令式編程通常會讓代碼變得十分冗余，更重要的是由于它提供了過于具體的指令，這樣執(zhí)行代碼的基礎設施（如CLR或JVM）沒有太多發(fā)揮空間，只能老老實實地根據(jù)指令一步步地向目標前進。例如，并行執(zhí)行程序會變得十分困難，因為像“執(zhí)行目的”這樣更高層次的信息已經(jīng)丟失了。因此，編程語言的趨勢之一，便是能讓代碼包含更多的“What”，而不是“How”，這樣執(zhí)行環(huán)境便可以更加聰明地去適應當前的執(zhí)行要求。
關于聲明式的編程風格，Anders主要提出了兩個方面，***個方面是DSL（Domain Specific Language，領域特定語言）。DSL不是什么新鮮的玩意兒，我們平時經(jīng)常接觸的SQL、CSS、正則表達式等都屬于DSL。有的DSL可能更加專注于一個方面，例如Mathematica、LOGO等。這些語言的目標都是特定的領域，與之相對的則是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一般會直接針對特定的領域設計，而不考慮其他方面。James Gosling曾經(jīng)說過：每個配置文件最終都會變成一門編程語言。一開始你可能只會用它表示一點點東西，慢慢地你便會想要一些規(guī)則，而這些規(guī)則則變成了表達式，后來你可能還會定義變量，進行條件判斷等，而最終它就變成了一種奇怪的編程語言。這樣的情況屢見不鮮?，F(xiàn)在有一些公司也在關注DSL的開發(fā)。
例如以前在微軟工作的Charles Simonyi提出了Intentional Programming的概念，還有JetBrains公司提供了叫做MPS（Meta Programming System）的產(chǎn)品。最近微軟也提出了自己的Oslo項目，而在Eclipse世界里也有Xtext，所以如今在這方面已經(jīng)有不少嘗試。由于外部DSL的獨立性，在某些情況下也會出現(xiàn)特定的工具，輔助領域?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)勢，例如可以訪問語言中的代碼或變量，以及利用代碼補全、重構等母語言的所有特性。
DSL的可讀性往往很高。例如，要篩選出單價大于20的產(chǎn)品，并對所屬種類進行分組，降序列出每組的分類名稱及產(chǎn)品數(shù)量。如果是用命令式的編程方式，可能是這樣的：
- var groups = new Dictionary<string, Grouping>();
- 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<Grouping>(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() });
這段代碼更加關注的是“How”而不是“What”，它不會明確地給出過濾的操作方式，也沒有涉及到創(chuàng)建字典這樣的細節(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則幾乎不需要做出任何修改。
#p#
函數(shù)式編程
Anders提出的另一個重要的聲明式編程方式便是函數(shù)式編程。函數(shù)式編程歷史悠久，如當年的LISP便是函數(shù)式編程語言。除了LISP以外還有其他許多函數(shù)式編程語言，如APL、Haskell、ML等。函數(shù)式編程在學術界已經(jīng)有過許多研究，大約在5~10年前許多人開始吸收和整理這些研究內(nèi)容，想要把它們?nèi)谌敫鼮橥ㄓ玫木幊陶Z言?，F(xiàn)在的編程語言，如C#、Python、Ruby、Scala等，都受到了函數(shù)式編程語言的影響。
推薦專題：F#函數(shù)式編程語言
使用命令式編程語言寫程序時，我們經(jīng)常會編寫如x = x + 1這樣的語句，此時我們大量依賴的是可變狀態(tài)，或者說是變量，它們的值可以隨程序運行而改變，可變狀態(tài)非常強大，但隨之而來的便是“副作用”問題，例如一個無需參數(shù)的void方法，它會根據(jù)調(diào)用次數(shù)或是在哪個線程上進行調(diào)用對程序產(chǎn)生影響，它會改變程序內(nèi)部的狀態(tài)，從而影響之后的運行效果。而在函數(shù)式編程中則不會出現(xiàn)這個情況，因為所有的狀態(tài)都是不可變的。事實上對函數(shù)式編程的討論更像是數(shù)學、公式，而不是程序語句，如x = x + 1對于數(shù)學家來說，似乎只是個永不為真的表達式而已。
函數(shù)式編程十分容易并行，因為它在運行時不會修改任何狀態(tài)，因此無論多少線程在運行時都可以觀察到正確的結果。假如兩個函數(shù)完全無關，那么它們是并行還是順序執(zhí)行便沒有什么區(qū)別。
當然，現(xiàn)實中的程序一定是有副作用的，例如向屏幕輸出內(nèi)容，向Socket傳輸數(shù)據(jù)等，因此真實世界中的函數(shù)式編程往往都會考慮如何將有副作用的代碼分離出來。函數(shù)式編程默認是不可變的，開發(fā)人員必須做些額外的事情才能使用可變狀態(tài)或是危險的副作用，與之相反，C#或Java必須使用readonly或final來做到這一點。此時，使用函數(shù)式編程語言時的思維觀念便會有所不同。
原文鏈接：http://www.programmer.com.cn/3745/
【編輯推薦】
