標(biāo)題：Language Oriented Programming:The Next Programming Paradigm
網(wǎng)址：http://www.onboard.jetbrains.com/is1/articles/04/10/lop/mps.pdf
中文譯文網(wǎng)址：http://blog.csdn.net/chelsea/archive/2005/02/17/290486.aspx
這篇文章的中文譯文在切爾斯基的blog上面看到，翻譯得非常好，看來是花了不少工作量，而且譯者對(duì)這個(gè)領(lǐng)域非常熟悉，強(qiáng)烈感謝那些翻譯外文文獻(xiàn)無私貢獻(xiàn)給大家的人。下面的摘要直接轉(zhuǎn)載了切爾斯基的原文摘要。大意和感想部分是我自己寫的。
摘要：
現(xiàn)在是軟件開發(fā)中開始下一次技術(shù)革命的時(shí)候了，而這次革命的輪廓正變得越來越清晰。下一代編程范型也在接近我們，但仍然沒有完全成形－－不同的部分有不同的名稱：Intentional programming, MDA, generative programming, 等等；我建議把把所有這些新方法歸并為一個(gè)名字： ‘language-oriented programming’（面向語言的編程）, 而本文將闡述這種新的編程范型的主要原則今天主流的編程方法有一些內(nèi)在的假定像脖子上的繩索一樣桎梏著我們，盡管大部分程序員還沒有意識(shí)到它；即使算上在編程領(lǐng)域取得的所有進(jìn)步，我們也仍然處于石器時(shí)代；我們有我們信賴的石斧（面向?qū)ο缶幊蹋軌驖M足我們的需要，但是當(dāng)用它來對(duì)付最困難的問題時(shí)，它會(huì)裂成碎屑；為了超越石器前進(jìn)，我們必須馴服烈火，只有這樣，我們才能鑄造出新的工具，激發(fā)一個(gè)創(chuàng)作的新時(shí)代，和新技術(shù)的爆發(fā)。我將討論編程的局限，它強(qiáng)迫程序員像計(jì)算機(jī)一樣思考，而不是令計(jì)算機(jī)像程序員一樣思考；這是嚴(yán)重的，根深蒂固的局限，需要花費(fèi)巨大的努力去克服它；當(dāng)我說這將是編程中下一個(gè)大的范型轉(zhuǎn)換時(shí)我并沒有自命不凡；我們需要徹底重新定義我們編寫程序的方法本文中，我表述了我的觀點(diǎn)和我當(dāng)前在Language Oriented Programming (LOP)上的工作；首先我將展示目前主流編程方法的錯(cuò)誤，然后我會(huì)使用示例來解釋LOP的概念，它們基于我已有的一個(gè)LOP的實(shí)現(xiàn)：Meta Programming System (MPS). 本文有意只是給你一個(gè)對(duì)LOP的驚鴻一瞥，目的是激發(fā)你對(duì)這個(gè)思想的興趣，并希望能夠得到反饋和討論。
大意：
全文總體分為兩個(gè)個(gè)部分：一是面向語言編程概論；二是元編程系統(tǒng)的介紹。
第一部分討論了這個(gè)幾個(gè)問題：
1）通用編程語言（例如JAVA,C++）和DSL（Domain Specific Language，例如SQL）之間的比較與分析。顯然通用編程語言適用面廣而不精；而DSL則精而不廣；
2）當(dāng)前主流編程方法與LOP的流程比較：主流編程方法分為思考、選擇、編程；而LOP分為思考、選擇、創(chuàng)建、編程。
3）當(dāng)前編程語言的缺點(diǎn)：一是實(shí)現(xiàn)的耗時(shí)長(zhǎng)，從確切的知道某個(gè)問題的解決方案到編程實(shí)現(xiàn)它總是一個(gè)漫長(zhǎng)的過程；二是代碼的維護(hù)和理解困難；三是陡峭的學(xué)習(xí)曲線，學(xué)習(xí)編程語言以及相關(guān)的類庫總是一個(gè)艱難的過程。
4）LOP的細(xì)節(jié)：對(duì)于“編程”的定義，編程不是寫一組計(jì)算機(jī)指令，而應(yīng)該是對(duì)某個(gè)問題的清晰無誤的表達(dá)；“編程”不能僅僅限制在文本中，程序不應(yīng)該天生就是文本；LOP將編程語言分為三個(gè)部分：結(jié)構(gòu)、編輯器、和語義；結(jié)構(gòu)定義了抽象語法、支持的概念、以及如何安排它們；編輯器定義了具體的語法，如何描繪和編輯語言；語義定義了行為，它如何被解釋，和/或它如何被轉(zhuǎn)換成可執(zhí)行代碼；當(dāng)然，語言還可以有其它方面，比如約束和類型系統(tǒng)。（上一句話引自http://blog.csdn.net/chelsea/archive/2005/02/17/290486.aspx的譯稿）
第二部分介紹了如下內(nèi)容：
1）在MPS中如何創(chuàng)建語言：“創(chuàng)建語言”本身是一個(gè)問題，解決這個(gè)問題的方法就是一個(gè)“程序”。我們知道對(duì)于“程序”使用DSL可以得到更高的效率。于是MPS提供了用來“創(chuàng)建語言”的DSL。對(duì)應(yīng)于語言的三個(gè)方面，MPS提供了三種語言：Structure Language用來創(chuàng)建語言的“結(jié)構(gòu)”；Editor Language用來創(chuàng)建語言的“編輯器”；Transformation Language用來創(chuàng)建語言的“語義”。
2）平臺(tái)、框架、庫和語言：MPS提供了三種基本的語言：Base Language是一種最小化的通用語言；Collection Language是一種專門用來處理集合的語言；User Interface Language是用戶界面語言。
3）MPS的起步：MPS目前剛剛起步，可能適用于以下兩個(gè)方面：Java應(yīng)用程序；創(chuàng)建你的應(yīng)用程序的配置/腳本語言。
感想：
1. 關(guān)于“編程”本質(zhì)的討論。
關(guān)于“編程”的本質(zhì)，作者在文中說：“今天，百分之九十九的程序員認(rèn)為編程就是編寫一串計(jì)算機(jī)能夠執(zhí)行的指令集；我們被教育說計(jì)算機(jī)建立在圖靈機(jī)模型之上，因此它們用指令集的術(shù)語來“思考””。這句話放到五年前說還差不多，當(dāng)前MDA技術(shù)的發(fā)展，很多程序員已經(jīng)脫離了這個(gè)誤區(qū)。其實(shí)，從最早期的計(jì)算機(jī)教材中就已經(jīng)清楚的說明：程序是從問題域到解決空間的一個(gè)清晰無誤的解決方案。選擇計(jì)算機(jī)指令集作為程序的表達(dá)方式只不過是一種無奈的選擇，當(dāng)前的很多技術(shù)已經(jīng)盡力要脫出這個(gè)巢臼。以MDA技術(shù)為例，當(dāng)前很多的MDA工具已經(jīng)可以不寫一行代碼解決一些經(jīng)典的問題，例如用ArcStyler編寫Web訪問的程序，只需要建立模型然后進(jìn)行代碼生成和配置即可。還有Rose和EMF等UML工具，可以把大部分的編程工作放到構(gòu)建UML類圖中，只是在最后進(jìn)行少量的代碼補(bǔ)充工作。Together更是使代碼和UML圖一致化，同時(shí)用不同的方法展現(xiàn)程序。因此，其實(shí)“編程”的本質(zhì)在很多程序員的心里已經(jīng)達(dá)成了共識(shí)，大家不甘心在“編寫計(jì)算機(jī)指令集”這棵樹上吊死，只是如何才能找到更好的解決方案目前還眾說紛紜，希望LOP是一條光明之路。
2. 程序和本文之間關(guān)系的討論
萬惡的MFC也曾經(jīng)給我一些啟蒙教育，其中最出色的就是它的“文檔-框架-視圖”結(jié)構(gòu)，雖然它把著名的MVC模式解釋得一塌糊涂，不過當(dāng)時(shí)的我還是覺得一個(gè)文檔可以對(duì)應(yīng)多個(gè)視圖是一個(gè)很棒的想法。當(dāng)然，在MVC中我才真正領(lǐng)略了model和View的實(shí)質(zhì)所在。對(duì)于程序來說，其根本實(shí)質(zhì)可以稱之為model，而其表現(xiàn)形式可以稱之為view。在目前看來，大部分程序的view都是以文本形式表現(xiàn)的，例如java代碼。不過，UML在前幾年就已經(jīng)顛覆了這個(gè)“程序即文本”的觀點(diǎn)。UML的成功就在于它提供了適當(dāng)?shù)膱D形化符號(hào)來對(duì)應(yīng)程序的結(jié)構(gòu)部分。但是當(dāng)前我們還是不能完全離開文本代碼的，不過在圖形（例如類圖或者程序流程圖）和文本之間尋找一個(gè)適當(dāng)?shù)钠胶馐且粋€(gè)很有意義的事情。我記得曾經(jīng)在一篇文章中有人專門討論過這個(gè)問題：http://www.softmetaware.com/oopsla2003/bettin.pdf
3. Transformation Language本質(zhì)是什么，是否可以很好的規(guī)定語言的語義？
LOP的精華部分應(yīng)該是這個(gè)Transformation Language，因?yàn)槿绻@個(gè)環(huán)節(jié)能夠很好的解決的話，可以說這個(gè)工作也就成功了一大半。因?yàn)閷?duì)于定義一個(gè)新的語言，其結(jié)構(gòu)特征和編輯器都不是關(guān)鍵問題，使用MOF應(yīng)該可以定義出一個(gè)語言的結(jié)構(gòu)部分。但是如何讓一個(gè)模型運(yùn)行起來卻一直不能解決。雖然有可執(zhí)行UML的提法，但是好像并沒有完全解決問題。
可以說MDA是一個(gè)理想的解決方案，它可以定義建模語言，定義建模語言到主流編程語言的代碼生成，但是無法解決如何在建模語言中定義語義性。一旦可以在建模語言中定義運(yùn)行語義，就可以徹底拋棄當(dāng)前的編程語言，從而把編程徹底的變?yōu)椤敖！薄?/SPAN>
Transformation Language的想法是利用這個(gè)語言定義語言之間的轉(zhuǎn)換，將一個(gè)自定義的語言轉(zhuǎn)換為當(dāng)前流行的編程語言，然后利用此編程語言進(jìn)行運(yùn)行。作者想盡力描繪出一個(gè)美好的畫面，但是在關(guān)鍵的部分還是語焉不詳。且不論定義一個(gè)新的語言需要多么廣闊的專業(yè)知識(shí)和創(chuàng)造力，僅僅定義兩種語言之間的映射，就是一項(xiàng)浩大的工程啊。“念天地之悠悠，獨(dú)愴然而淚下”。
4. 最終討論，LOP是否能夠提升編程的抽象層次，最終提高程序員的生產(chǎn)力？LOP適用于哪些方面？
從文中看來，LOP并不像MDA那樣著力于提高編程的抽象層次，它并不想用“建模”來替代“編程”。而是獨(dú)辟蹊徑，提供給程序員一個(gè)創(chuàng)造新語言的工具，對(duì)于每個(gè)專業(yè)領(lǐng)域，都能夠快速的開發(fā)出一個(gè)DSL，使用這個(gè)DSL可以大大提高這個(gè)領(lǐng)域的生產(chǎn)力。照此來看，LOP似乎又可以稱為“DSL Generator”。至于是否能夠總體上提升生產(chǎn)力，還是要看具體情況而定。無論如何，LOP走出了一條新路，對(duì)它的創(chuàng)造者，我表示深深的敬佩。
另外，MPS可能會(huì)在下個(gè)月提供下載，試用之后，再做評(píng)論。