元編程：編寫在運行時操縱語言構件的代碼。 --《Ruby元編程》
應該是借鑒了lisp裏的宏（macro）。其他語言裏還有類似的用法嗎？
人生最曼妙的风景，竟是内心的淡定与从容！
這樣來說吧： 工業時代初期，是這樣的情況： 人生產機器，機器生產產品。
到了後期： 人生產機器，機器生產機器，機器生產產品。
顯然，機器生產機器是一個了不起的進步，這大大的解放了勞動力。
元程式設計就類似機器生產機器，簡單說就是程式可以自己改變自己或是產生新的程式。這樣的當然大大的解放了程式設計師。
當然，事實上在元編程之前，程式設計師就發明了大量的輔助工具來幫助自己編程，例如IDE什麼的。只是後來程式設計師覺得IDE啥的還是太弱了，就能查找替換跳到引用套用模板啥的，要是程式可以自己生產自己該有多好。
====================科普完畢，以下是不負責任的暢想=================== ==
事實上meta-programming一直都不是一個定義良好的概念，主要是meta（元）這個字本身的意思就很模糊。
元一般被理解為更基本的，更基礎的。元編程就是比程式更基礎的編程，也就是程式產生程式。從這個角度來說，無論是C++的模板、C的巨集、.NET的Emit和Compiler Provider、JavaScript的字串拼接和eval，甚至於什麼動網程式碼產生器，都是程式產生程式。
但是一般而言，要稱得上元程式設計還是要滿足一定的條件，當然，由於元程式設計這個概念並非是定義良好，這些條件也只能算得上是什麼共識。這個語言的特性被A當作是元編程，而B不這麼認為是很正常的事情，下面列舉的這些條件，僅僅只是站在我的角度認為的：
1、具備元程式設計能力的語言，必須是可以產生相同程式設計語言程式碼的語言，而不能是用一種語言產生另一種語言的程式。這就把程式碼產生器排除在外了。 2.具備元程式設計能力的語言，元程式設計產生的程式碼，必須能通過詞法分析。這一條把C的巨集排除在外和JavaScript的eval排除在外了。 ……
可以看出來，到底算得上元編程，採用不同的限制條件可以得到不同的結果。當我們討論一個程式設計語言是不是可以元程式設計時，條件1基本上是可以達成共識，條件2就各有各的看法。
話說元程式設計最初產生的時候，單純只是為了減輕程式設計師的負擔，C++的模板原本只是重載的延伸。由於強類型的緣故，C語言必須針對不同的類型編寫一大堆重複的程式碼，重載解決了這些重複程式碼的名稱污染，而泛型則開始解決這些程式碼的重複。但C++標委會那群傢伙顯然不會像Anders那樣止步於泛型，高端大氣上檔次一直是C++努力不懈的追求，所以泛型就被搞成了模板，更進一步的，程式設計師也一起來Happy，就玩了C++模板元程式設計。
Javascript 就有呀！
http://www.slideshare.net/danwrong/metaprogramming-javascript
注意到這個 presentation 的發表日期，這已經不是什麼新鮮玩意兒了，這些年隨著語言的不斷完善和擴展，還有更多的元編程技巧被廣泛應用，你可以 google 一下。
另外，支援元程式設計的語言是非常普遍的，幾乎所有的函數式程式語言都可以，Java 有 Annotation，Clojure 自不必說。 Lisp 基於宏，Ruby 和 Smalltalk 類似都是主要利用反射機制。還有像 Groovy 是基於位元組編碼和 AST 轉換等等。
元程式設計算是進階技巧，但不是什麼魔法，也不是很罕見的特性。
這樣來說吧：
工業時代初期，是這樣的情況：
人生產機器，機器生產產品。
到了後期：
人生產機器，機器生產機器，機器生產產品。
顯然，機器生產機器是一個了不起的進步，這大大的解放了勞動力。
元程式設計就類似機器生產機器，簡單說就是程式可以自己改變自己或是產生新的程式。這樣的當然大大的解放了程式設計師。
當然，事實上在元編程之前，程式設計師就發明了大量的輔助工具來幫助自己編程，例如IDE什麼的。只是後來程式設計師覺得IDE啥的還是太弱了，就能查找替換跳到引用套用模板啥的，要是程式可以自己生產自己該有多好。
====================科普完畢，以下是不負責任的暢想=================== ==
事實上meta-programming一直都不是一個定義良好的概念，主要是meta（元）這個字本身的意思就很模糊。
元一般被理解為更基本的，更基礎的。元編程就是比程式更基礎的編程，也就是程式產生程式。從這個角度來說，無論是C++的模板、C的巨集、.NET的Emit和Compiler Provider、JavaScript的字串拼接和eval，甚至於什麼動網程式碼產生器，都是程式產生程式。
但是一般而言，要稱得上元程式設計還是要滿足一定的條件，當然，由於元程式設計這個概念並非是定義良好，這些條件也只能算得上是什麼共識。這個語言的特性被A當作是元編程，而B不這麼認為是很正常的事情，下面列舉的這些條件，僅僅只是站在我的角度認為的：
1、具備元程式設計能力的語言，必須是可以產生相同程式設計語言程式碼的語言，而不能是用一種語言產生另一種語言的程式。這就把程式碼產生器排除在外了。
2.具備元程式設計能力的語言，元程式設計產生的程式碼，必須能通過詞法分析。這一條把C的巨集排除在外和JavaScript的eval排除在外了。
……
可以看出來，到底算得上元編程，採用不同的限制條件可以得到不同的結果。當我們討論一個程式設計語言是不是可以元程式設計時，條件1基本上是可以達成共識，條件2就各有各的看法。
話說元程式設計最初產生的時候，單純只是為了減輕程式設計師的負擔，C++的模板原本只是重載的延伸。由於強類型的緣故，C語言必須針對不同的類型編寫一大堆重複的程式碼，重載解決了這些重複程式碼的名稱污染，而泛型則開始解決這些程式碼的重複。但C++標委會那群傢伙顯然不會像Anders那樣止步於泛型，高端大氣上檔次一直是C++努力不懈的追求，所以泛型就被搞成了模板，更進一步的，程式設計師也一起來Happy，就玩了C++模板元程式設計。
Javascript 就有呀！
http://www.slideshare.net/danwrong/metaprogramming-javascript
注意到這個 presentation 的發表日期，這已經不是什麼新鮮玩意兒了，這些年隨著語言的不斷完善和擴展，還有更多的元編程技巧被廣泛應用，你可以 google 一下。
另外，支援元程式設計的語言是非常普遍的，幾乎所有的函數式程式語言都可以，Java 有 Annotation，Clojure 自不必說。 Lisp 基於宏，Ruby 和 Smalltalk 類似都是主要利用反射機制。還有像 Groovy 是基於位元組編碼和 AST 轉換等等。
元程式設計算是進階技巧，但不是什麼魔法，也不是很罕見的特性。