編程語言的發(fā)展趨勢及未來方向（5）：元編程

　　這是Anders Hejlsberg(不用介紹這是誰了吧)在比利時TechDays 2010所做的開場演講。由于最近我在博客上關(guān)于語言的討論比較多，出于應(yīng)景，也打算將Anders的演講完整地聽寫出來。在上一部分中，Anders談及了他眼中編程語言的另一個發(fā)展趨勢：動態(tài)性。在這一部分中，Anders則討論了動態(tài)語言所擅長的“元編程”，并簡單介紹了他為靜態(tài)類型語言所設(shè)計的一種改進(jìn)方案：編譯器即服務(wù)。

　　如果沒有特別說明，所有的文字都直接翻譯自Anders的演講，并使用我自己的口語習(xí)慣表達(dá)出來，對于Anders的口誤及反復(fù)等情況，必要時在譯文中自然也會進(jìn)行忽略。為了方便理解，我也會將視頻中關(guān)鍵部分進(jìn)行截圖，而某些代碼演示則會直接作為文章內(nèi)容發(fā)表。

　　(聽寫開始，接上篇)

　　動態(tài)語言的另一個關(guān)鍵和有趣之處在于“元編程”?！?a class="contentlabel" href="http://m.butianyuan.cn/news/listbylabel/label/元編程">元編程”實(shí)際上是“代碼生成”的一種別稱，其實(shí)在日常應(yīng)用中我們也經(jīng)常依賴這種做法。觀察動態(tài)語言適合元編程的原因也是件十分有趣的事情。

　　在這個藍(lán)框中是一段Ruby on Rails代碼(見上圖)。簡單地說，這里定義了一個Order類，繼承了ActiveRecord，也定義了一些關(guān)系，如belongs_to和has_many關(guān)系。Ruby這種動態(tài)語言的關(guān)鍵之處，在于一切事物都是通過執(zhí)行而得到的，包括類型聲明。比如這里的類型申明執(zhí)行了belongs_to和has_many方法的調(diào)用，執(zhí)行belongs_to會截獲一對多或一對一關(guān)系所需要的信息，因此在這里語言是在運(yùn)行的時候，動態(tài)為自身生成了代碼。

　　實(shí)現(xiàn)這點(diǎn)在動態(tài)語言里自然會更容易一些，因?yàn)樗鼈儧]有編譯期和執(zhí)行期的區(qū)別。靜態(tài)類型語言在這方面會比較困難。例如在C#或Java里使用ORM時，傳統(tǒng)的做法是讓代碼生成器去觀察數(shù)據(jù)庫，生成一大堆代碼，然后再編譯，有些復(fù)雜。不過我時常想著去改善這一點(diǎn)。

　　其中一種做法，是我們正在努力實(shí)現(xiàn)的“編譯器即服務(wù)”，我現(xiàn)在先對它進(jìn)行一些簡單的介紹。傳統(tǒng)的編譯器像是一個黑盒，你在一端輸入代碼，而另一端便會生成.NET程序集或是對象代碼等等。而這個黑盒卻很神秘，你目前很難參與或理解它的工作。

　　你可以想象，一些代碼往往是不包含在源文件中的。如果你想要交互式編程的體驗(yàn)，例如一個交互式的提示符，那么代碼不是保存在源文件中而是由用戶輸入的。如果您在實(shí)現(xiàn)一個DSL，例如Windows Workflow或是Biztalk，則可能用C#或VB實(shí)現(xiàn)了一些需要動態(tài)執(zhí)行的規(guī)則，它們也不是保存在源文件中，而可能是放在XML屬性中的。此時你想編譯它們卻做不到，你還是要把它們放入源文件，這就變的復(fù)雜了。

　　另一方面，對于編譯器來說，我們不一定需要它生成程序集，有時候需要的是一些樹狀的表現(xiàn)形式。例如一些由用戶反射生成的代碼，便可能不要程序集而是一個解析樹，然后可以對它進(jìn)行識別和重寫。因此，我們可能越來越需要的是一些API，以此開放編譯器的功能。

　　例如，你可以給它一小段代碼，讓它返回一段可執(zhí)行的程序，或是一個可以識別或重寫的解析樹。這么做可以讓靜態(tài)類型語言獲得許多有用的功能，例如元編程，以及可操作的完整的對象模型等等。我們正在朝這方面努力，我也會在下午1點(diǎn)的C# 4.0演講中談?wù)摳噙@方面的內(nèi)容。