CSDN的編輯把它和透明的那篇文章放在了一起。跟貼者甚眾，令我沒(méi)想到的是，我的文章居然被不少跟貼者駁斥，而且語(yǔ)言極盡諷刺、挖苦之能事。
我并不反對就技術(shù)問(wèn)題爭論，也不是不允許別人就我的文章和觀(guān)點(diǎn)與我辯論。相反，我一向都非常歡迎同行指正我的錯誤，能夠使我有所提高。
但是，多年與人打交道的經(jīng)驗讓我深深地相信這樣一個(gè)真理：“你永遠無(wú)法說(shuō)服不想被你說(shuō)服的人。”
這次眾多駁斥我的跟貼再一次驗證了這樣一個(gè)真理。
我的文章由于成文比較倉促，所以確實(shí)在文筆上有一些漏洞，遣詞造句也不是很妥當。但我認為，一個(gè)嚴肅的辯論者，是不會(huì )咬文嚼字的尋找對方文法上的弱點(diǎn)的。否則的話(huà)，除了數學(xué)公理之外，沒(méi)什么話(huà)可以說(shuō)了！
對于這樣的人，在我眼里，并不是在污辱我的智商（盡管他是這樣以為的），而是在侮辱他自己的智商。這說(shuō)明他完全不具備與人交流的能力。
如果一定要咬文嚼字，那么所有判斷句都不可以在文章里用了。Java會(huì )消亡嗎？廢話(huà)，一定會(huì )。宇宙都會(huì )消亡，什么能不消亡？
透明的意思是，3-5年內，Ruby將占據企業(yè)級應用市場(chǎng)的主流。也就是JavaEE和今天的Ruby換個(gè)位子。我認為，這是不可能的。Java平臺至少能夠繼續占據、企業(yè)級應用市場(chǎng)主流地位10年。
有人說(shuō)我不懂Ruby，也不懂Java。這我就不敢茍同了。我是不懂Ruby，但并不代表我不懂Ruby,Python,Smalltalk語(yǔ)言為代表的動(dòng)態(tài)面向對象語(yǔ)言的機制。對于Java，我也許不比某些人懂得多，但也絕不會(huì )比一般的Java程序員懂得少。
我對Ruby的認識，僅僅是今年5月Martin Fowler先生在上海交大作的一次演講中Martin Fowler的Ruby編程演示。我還略為研究過(guò)Smalltalk和Python的語(yǔ)法。但是它們的類(lèi)庫，我沒(méi)有研究過(guò)。
因為，我還不打算靠它們吃飯，那厚厚的專(zhuān)用類(lèi)庫對我而言是沒(méi)有價(jià)值的。
Spring的AOP實(shí)現需要使用“反射”這種動(dòng)態(tài)技術(shù)。這也是促成我當年研究Smalltalk和Python這樣的動(dòng)態(tài)面向對象語(yǔ)言的原因。我也十分折服于動(dòng)態(tài)面向對象編程技術(shù)的強大能力。我一直認為動(dòng)態(tài)OO技術(shù)在未來(lái)，將在編程中發(fā)揮越來(lái)越大的作用，也一直希望JVM能夠增加更多的動(dòng)態(tài)技術(shù)。我還曾經(jīng)寫(xiě)過(guò)文章為動(dòng)態(tài)OO技術(shù)搖旗吶喊過(guò)，此初衷依然不改！
Java作為一個(gè)平臺也確實(shí)有這樣的能力，而且也正在向這個(gè)方面發(fā)展，JVM將會(huì )支持更多的動(dòng)態(tài)OO技術(shù)。
.NET平臺當年推出之時(shí)，就以支持多種靜態(tài)面向對象編程語(yǔ)言為賣(mài)點(diǎn)。VB.NET,C#，Delphi,托管C++這4種主流的面向對象編程語(yǔ)言都可以在.NET平臺上運行。
同樣都是靜態(tài)面向對象編程語(yǔ)言，它們之間除了關(guān)鍵字不同之外，有什么本質(zhì)上的區別嗎？沒(méi)有！VB.NET和C#是我所熟悉的兩種.NET語(yǔ)言。它們之間本質(zhì)上確實(shí)沒(méi)什么區別。唯一的區別是，.NET平臺的技術(shù)更新時(shí)，C#會(huì )先得到支持，VB.NET要晚一些。比如，事件機制，.NET1.1時(shí)，VB.NET用的是類(lèi)似于Java1.0時(shí)的機制，C#用的是Java更新版本的機制。我想，應該是因為微軟最重視C#的緣故吧。
.NET平臺同時(shí)支持多種類(lèi)似的語(yǔ)言，雖然在市場(chǎng)上有吸引VB,C++,Delphi,Java等程序員的作用，但在技術(shù)上卻導致了開(kāi)發(fā)資源的浪費。一種技術(shù)，要提供多個(gè)語(yǔ)言的實(shí)現。這比Java平臺只支持Java這一種靜態(tài)面向對象編程語(yǔ)言要低效的多。我在發(fā)現了微軟優(yōu)先關(guān)照C#之后，就決定從VB.NET上轉到C#上，以免吃虧！自從Delphi投入.NET平臺之后，日漸式微，這也是一個(gè)平臺上不需要多種類(lèi)似語(yǔ)言的明證！可以預見(jiàn)，.NET平臺上C#獨大的趨勢還會(huì )繼續下去。
.NET支持多種類(lèi)似語(yǔ)言的另一個(gè)問(wèn)題是，分裂了開(kāi)發(fā)者社區。VB.NET,C#，Delphi，還有J#，托管C++，它們的語(yǔ)言原理和能力實(shí)際上都差不多，都是靜態(tài)面向對象語(yǔ)言，但是，由于語(yǔ)法不同，就分裂成了幾個(gè)開(kāi)發(fā)者社區，彼此交流都不方便。
在我上一篇文章的評論者中，有人說(shuō)我說(shuō)錯了，Java平臺上除了Java之外還有Beanshell等語(yǔ)言。拜托！兄弟，你的理解力沒(méi)什么問(wèn)題吧？我說(shuō)的是Java平臺上只有一種官方支持的靜態(tài)面向對象編程語(yǔ)言。就是和.NET比較而言的。
Java平臺官方支持C++,C#,VB.NET,Delphi,J#嗎？
Beanshell是一種動(dòng)態(tài)面向對象語(yǔ)言，而且Sun官方可沒(méi)有支持它！
現在，Java平臺正在增強對動(dòng)態(tài)編程能力的支持。目前，開(kāi)源社區提供了Beanshell,JRuby,JPython,Groovy等面向對象編程語(yǔ)言。我相信，最后，在Java平臺上也會(huì )只剩下一種主流的動(dòng)態(tài)面向對象編程語(yǔ)言。未來(lái)，Java平臺上會(huì )剩下兩種主流的編程語(yǔ)言：靜態(tài)面向對象編程語(yǔ)言類(lèi)型是Java；動(dòng)態(tài)面向對象編程語(yǔ)言是上面中的一種，也許是Groovy,也許是JRuby。
將來(lái)，我們Java程序員將有2件編程利器：Java和動(dòng)態(tài)OO語(yǔ)言。對于編程問(wèn)題，將能夠更加游刃有余！底層的API類(lèi)庫，既可以是Java，也可以是其它動(dòng)態(tài)OO語(yǔ)言所編寫(xiě)。反正都一樣是.class文件，Java和動(dòng)態(tài)OO語(yǔ)言都可以調用。
這就是未來(lái)！Ruby和Python這兩種平臺將會(huì )繼續慘淡的過(guò)日子，也許不會(huì )消亡，但成不了主流。不是因為它們的語(yǔ)法不好，機制不行，而是因為它們缺少Java平臺上那樣多的API，也缺少熟悉這些API的程序員。
它們的靈魂將會(huì )飛到Java平臺上，以JRuby,JPython的形式生存下來(lái)，在Java平臺上發(fā)展起來(lái)。
接下來(lái)，再談一談靜態(tài)OO語(yǔ)言和動(dòng)態(tài)OO語(yǔ)言的優(yōu)劣的問(wèn)題。
我欣賞動(dòng)態(tài)OO語(yǔ)言，smalltalk雖然出現的很早，開(kāi)發(fā)者甚少，但是在它的社區中卻誕生許多著(zhù)名的程序員和設計模式等思想。MVC模式，XP極限編程等我所尊敬的技術(shù)都出自smalltalk。
但是，靜態(tài)OO語(yǔ)言一直占據著(zhù)主流的地位，也不是沒(méi)有原因的。除了編譯型語(yǔ)言的執行速度比解釋型語(yǔ)言快之外，靜態(tài)OO語(yǔ)言還有其它的優(yōu)勢。速度的快慢，在今天來(lái)看，并不是十分重要。Java比C++慢一些，但現在測試下來(lái)，C++最多比Java快一倍而已（不要跟我說(shuō)某一個(gè)程序速度差很多，我這里指的是一般的程序，不作特別的優(yōu)化和劣化處理）。只要速度不是相差一個(gè)數量級，就不是問(wèn)題。
靜態(tài)OO語(yǔ)言意味著(zhù)更嚴格的語(yǔ)法，更多的編輯和編譯時(shí)的檢查步驟。更強的糾錯能力，不正是編程語(yǔ)言發(fā)展的一個(gè)標準嗎？不是可以更好的提高效率嗎？
5月份那次看Martin Fowler先生演示編寫(xiě)Ruby程序，IDE弱弱的報錯能力讓Martin先生也傷了不少腦筋！
不錯，Ruby不需要給變量聲明類(lèi)型。想指向哪個(gè)類(lèi)型，就指向哪個(gè)類(lèi)型。但是，指錯了呢？只有在運行時(shí)才能發(fā)現類(lèi)型指錯了。如果這是個(gè)復雜的程序，有很多執行路徑呢？如果測試人員沒(méi)能夠窮盡所有這些可能的路徑呢？這個(gè)錯誤豈不是會(huì )漏給用戶(hù)？
不錯，借助于測試驅動(dòng)開(kāi)發(fā)，是可以降低出錯幾率。但是，測試驅動(dòng)開(kāi)發(fā)也不是測試的銀彈，不能保證能夠找出所有的錯誤。而且，靜態(tài)編程語(yǔ)言也可以使用測試驅動(dòng)開(kāi)發(fā)技術(shù)。
我預測，未來(lái)3-5年，Java平臺和.NET平臺都會(huì )增加對動(dòng)態(tài)OO語(yǔ)言的支持力度，它們上面的動(dòng)態(tài)OO語(yǔ)言將會(huì )達到實(shí)用化的程度。而Python和Ruby將會(huì )繼續維持現在這樣的市場(chǎng)規模。仍然處于邊緣。Python和Ruby的解釋器平臺不會(huì )得到多大范圍的應用。就像今天，Web2.0的那些小網(wǎng)站帶來(lái)了Web2.0的概念，但最后是門(mén)戶(hù)網(wǎng)站Yahoo,Sina等占據了Web2.0的市場(chǎng)。
接下來(lái)，說(shuō)說(shuō)DSL特定領(lǐng)域語(yǔ)言的問(wèn)題。Matin Fowler最近轉調了。我記得原來(lái)他非常支持XML格式的作用。但是，最近他說(shuō)Ruby是最合適的DSL語(yǔ)言。盡管我仍然十分敬佩Martin Fowler先生，但是對他的這個(gè)觀(guān)點(diǎn)，我不敢茍同。我認為，DSL語(yǔ)言還是應該使用xml格式，而不是使用Ruby這種類(lèi)英語(yǔ)的編程語(yǔ)言來(lái)描述。
DSL可以說(shuō)是一種“元數據”。用來(lái)描述程序?，F在有2種元數據：標注和配置文件。
1.標注是.net首先引入的。Java在5.0之后也引入了。標注寫(xiě)在源代碼中，和關(guān)鍵字一樣，只是標注是可以自定義的。
標注的優(yōu)點(diǎn)是，簡(jiǎn)單。缺點(diǎn)是表達能力不強。
2.配置文件，一般又分為3種：屬性文件，一般文本文件和xml文件。
屬性文件中的數據是以“名—值”對的形式表示的。缺乏數據之間的關(guān)系結構。表達能力不強。
文本文件，就是直接在文本中按照規定的語(yǔ)法寫(xiě)上一段文本。類(lèi)似自然語(yǔ)言，只是語(yǔ)法的限制很強。語(yǔ)法檢查，是一個(gè)大問(wèn)題。如果沒(méi)有按照語(yǔ)法寫(xiě)，就會(huì )發(fā)生運行時(shí)錯誤。
Xml文件，是層次結構的。它的前身是層次數據庫。它的格式嚴謹，語(yǔ)法容易驗證，規則容易定義。只是稍微復雜一點(diǎn)，需要寫(xiě)上元素名。
但是，總的來(lái)說(shuō)，XML文件格式的DSL還是功能最強大，語(yǔ)法驗證能力最強，目前也是首先的DSL語(yǔ)言的載體。
除了使用元數據之外，直接使用編程語(yǔ)言也是可以實(shí)現高等級的功能的。如，傳統的不使用xml配置文件的Java編程。Java作為一種編譯語(yǔ)言，需要編譯，不使用xml等配置，就不是很方便。
而Ruby作為解釋型語(yǔ)言，直接修改源代碼是非常方便的。我想這大概就是Martin Fowler先生關(guān)于使用Ruby作為DSL的原因吧。
但是，使用DSL語(yǔ)言的用戶(hù)，他懂Ruby嗎？懂編程嗎？愿意查看和修改源代碼嗎？我們中國的用戶(hù)懂英語(yǔ)嗎？
我認為，DSL使用XML文件還是首選！
最后，談?wù)勱P(guān)于OO的問(wèn)題。有網(wǎng)友說(shuō)我“言必OO?OO就是銀彈嗎?”。這里我回答他：OO就是銀彈！
我Blog上的副標題是：“以OO為中心，堅定不移的走Spring道路”。
面向對象編程，給我們帶來(lái)了多少API類(lèi)庫。Int,String等基本的數據類(lèi)型，以及順序、條件、循環(huán)3種控制流這樣簡(jiǎn)單、細粒度的元素，通過(guò)類(lèi)被封裝了起來(lái)，今天已經(jīng)能夠通過(guò)層層疊疊的類(lèi)支持對現實(shí)世界的種種對象的模擬和抽象。
借助于類(lèi)庫，眾多的DSL特定領(lǐng)域語(yǔ)言已經(jīng)被廣泛使用。今天的java程序員使用了更多的配置文件（這就是DSL）來(lái)編程。如Ant配置文件，Hibernate配置文件，Spring配置文件等等。
最近，我正在學(xué)習jBPM。jBPM也是一個(gè)Java類(lèi)庫。通過(guò)Java類(lèi)，它提供了一個(gè)DSL語(yǔ)言框架。我們能夠使用xml配置文件，編寫(xiě)DSL語(yǔ)言：jpdl,bpel規范的。實(shí)現工作流、BPM等。
當然，除了OOP之外，還有AOP。但是，AOP只是OOP的補充。OOP能夠實(shí)現絕大部分的抽象模擬任務(wù)。
認為OO無(wú)用的程序員，可能工作在嵌入式開(kāi)發(fā)等與硬件有關(guān)的工作領(lǐng)域。他們的編程領(lǐng)域中，業(yè)務(wù)邏輯比較簡(jiǎn)單，不需要過(guò)多的抽象層次。
但是，這并不能成為否定OO作用的理由。你用不著(zhù)OO，并不代表OO沒(méi)用，并不代表OO不是銀彈。
OO已經(jīng)給我們帶來(lái)了多大的變化??！Java的成功就是一例。
還是毛主席的那句話(huà)：“沒(méi)有調查，就沒(méi)有發(fā)言權”。對此我也是深有體會(huì )的，曾經(jīng)也犯過(guò)很多錯。對于自己不懂的領(lǐng)域，硬是認為別人的說(shuō)法荒謬。后來(lái)，自己真正了解了那個(gè)領(lǐng)域之后，才知道“今是而昨非”??！
聯(lián)系客服
