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