動態語言的另一個關鍵和有趣之處在于“元編程”。“元編程”實際上是“代碼生成”的一種別稱，其實在日常應用中我們也經常依賴這種做法。觀察動態語言適合元編程的原因也是件十分有趣的事情。

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

實現這點在動態語言里自然會更容易一些，因為它們沒有編譯期和執行期的區別。靜態類型語言在這方面會比較困難。例如在C#或Java里使用ORM時，傳統的做法是讓代碼生成器去觀察數據庫，生成一大堆代碼，然后再編譯，有些復雜。不過我時常想著去改善這一點。

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

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

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

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

原文鏈接：http://blog.zhaojie.me/2010/05/trends-and-future-directions-in-programming-languages-by-anders-5-meta-programming.html

---

.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注

總結

以上是生活随笔為你收集整理的编程语言的发展趋势及未来方向（5）：元编程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。