爭(zhēng)論：Java是否應(yīng)該停止增加新特性

作者 Ryan Slobojan譯者 曹云飛 發(fā)布于 2008年1月17日 下午8時(shí)13分

社區(qū)

Java

主題

語(yǔ)言,

社區(qū),

變更

最近，關(guān)于Java平臺(tái)的未來(lái)有許多辯論，有些人認(rèn)為Java應(yīng)該加入更多的特征，這樣才能與C#、Ruby這樣的語(yǔ)言競(jìng)爭(zhēng)，另一些人認(rèn)為應(yīng)該保持Java的穩(wěn)定，以免變的過于復(fù)雜以至于難以使用。Bruce Eckel認(rèn)為應(yīng)該徹底停止往Java中增加新特性，這引起了一場(chǎng)新的辯論。

在Bruce Eckel 的博文中，他說(shuō)如果Java要保持主流地位，那么就需要停止進(jìn)化。作為一種語(yǔ)言，Java已經(jīng)“過于嘈雜”了，代碼有些過分啰嗦（例如System.out.println()）。Eckel認(rèn)為Java泛型增加了復(fù)雜性，這已經(jīng)引起了人們的關(guān)注，他還說(shuō)明了他看到的Java的一個(gè)關(guān)鍵問題：

我們對(duì)于復(fù)雜性的唯一控制手段是抽象：隱藏不需要暴露的部分（分治法（"divide and conquer"）是一個(gè)變種）。在Java中的悖論是，復(fù)雜性問題的一個(gè)關(guān)鍵方面被忽略了：沒有認(rèn)識(shí)到代碼可讀性是重要的問題。好像IDE會(huì)為你寫代 碼，如果那樣的話即使代碼過分復(fù)雜也不是問題了。

[Joshua Bloch] 將關(guān)于復(fù)雜性的思想提升了一步。他說(shuō)復(fù)雜 性不僅僅是指一個(gè)孤立的特定特征的復(fù)雜性，這種情況下復(fù)雜性通常是一目了然的。復(fù)雜性是指組合復(fù)雜性，這是當(dāng)你將一個(gè)新特性與其他語(yǔ)言特性以任意可能的方式進(jìn)行組合時(shí)所帶來(lái)的復(fù)雜性。如果你沒有從一開始就小心的設(shè)計(jì)，那么當(dāng)你將一個(gè)新特性加入一種現(xiàn)存的語(yǔ)言中時(shí)，你無(wú)法控制該特性是怎樣與其他現(xiàn)存特性進(jìn)行 組合的。組合復(fù)雜性會(huì)產(chǎn)生恐怖的后果，特別是在加入了特性之后，這時(shí)再做任何事情都為時(shí)已晚。早餐結(jié)束后Josh說(shuō)這類復(fù)雜性為Java的答疑解惑者提供 了豐富的素材，但是對(duì)于整個(gè)Java社區(qū)是有害的。

Eckel認(rèn)為他自己是一個(gè)“特性上癮者”，總是思考語(yǔ)言在新特性方面的進(jìn)化，但是現(xiàn)在他質(zhì)疑如果一個(gè)特性不能被正確的實(shí)現(xiàn)，該特性是否應(yīng)該被去掉 （例如Java的泛型）。Eckel認(rèn)為C和C++都非常穩(wěn)定，Java也應(yīng)該穩(wěn)定而不是追逐新的語(yǔ)言特性或者試圖跟隨所有的市場(chǎng)沖動(dòng)。有些人提出了打破 向后兼容性的想法，他們認(rèn)為那些希望使用老特性的人們可以使用老版本的Java而不要升級(jí)到新版本。Eckel對(duì)于不惜一切代價(jià)維護(hù)向后兼容性的風(fēng)險(xiǎn)做了 警告：

如果由于向后不兼容而不能正確的插入特性，我們?cè)谡Z(yǔ)言變化的時(shí)候會(huì)受到很大束縛，Java現(xiàn)在的情形與C++相同。C++經(jīng)常因 為它的設(shè)計(jì)受到批評(píng)，從C++標(biāo)準(zhǔn)委員會(huì)剛開始運(yùn)轉(zhuǎn)我就在其中工作，已經(jīng)工作了8年，我看到了所有關(guān)于語(yǔ)言特性的辯論。這些語(yǔ)言特性不是變化無(wú)常的，而是 經(jīng)過非常謹(jǐn)慎的而且深思熟慮的考量的結(jié)果。是向后兼容C語(yǔ)言產(chǎn)生了語(yǔ)言復(fù)雜性和困難性。一旦你在所有事情上都把自己與向后兼容綁定在一起，那么當(dāng)你向語(yǔ)言 加入特性的時(shí)候必須做好語(yǔ)言被破壞的準(zhǔn)備。如果Java不愿意打破向后兼容性，那么它就無(wú)法避免不打糧食的復(fù)雜性以及不完整的新特性實(shí)現(xiàn)。

Eckel認(rèn)為新的語(yǔ)言是放置主要新特性的正確場(chǎng)所，Scala是“當(dāng)前Java最好的退出策略”。他還認(rèn)為Java唯一的出路是成為象C那樣的工具語(yǔ)言，將來(lái)只應(yīng)該清理并豐富現(xiàn)在不完整的庫(kù)，把主要的語(yǔ)言變化（例如閉包）留給其他語(yǔ)言，而不是加入Java中。

Kevin Dangoor同意Eckel的觀點(diǎn)，他說(shuō)在需要向后兼容性的語(yǔ)言中加入新的特性也是笨拙的，他還指出在這一領(lǐng)域ECMAScript與Java有同樣的問題。Dangoor還對(duì)于開發(fā)者始終要尋求新的、炫的特性來(lái)幫助項(xiàng)目的批判聲音提出了質(zhì)疑：

軟件是思考的成果。其可鍛性很強(qiáng)且新的思想很容易測(cè)試。通過互聯(lián)網(wǎng)，新的思想和代碼傳播的很快很遠(yuǎn)，這是好事情。對(duì)于我來(lái)說(shuō)，現(xiàn) 在開發(fā)軟件比5、10、15、20年前要好的多。我看到許多閃光的事物飛過，而沒有真正的使用過它們。但是我認(rèn)為這些閃光的事物是非常重要的，其中包含了各種各樣的思想，可以使用不同的工具將其應(yīng)用于不同的場(chǎng)景。一些出自這些思想的實(shí)現(xiàn)成為了主流。

一般來(lái)說(shuō)，人們不會(huì)轉(zhuǎn)而使用所有從其身邊 飛過的閃光的事物。有些人會(huì)認(rèn)真的嘗試這些事物，他們可能會(huì)成為成功的拓荒者或者遭受失敗的痛苦而轉(zhuǎn)向其他解決方案。如果有足夠的人喜歡該思想并且推動(dòng)它 的發(fā)展，那么該思想會(huì)成為主流。Rails是2004年閃光的新事物。毫無(wú)疑問，有一些早期的使用者遭受了痛苦，但是在那些歲月里，相對(duì)于使用其他工具的 人而言，更多的人因?yàn)槭褂肦ails獲得了非常高的生產(chǎn)率。不管最終有多少人接受了Rails，事實(shí)是自Rails出現(xiàn)以后，它的很多思想對(duì)工作產(chǎn)生了顯 著的影響。

Cay Horstmann 同樣認(rèn)為應(yīng)該減少對(duì)Java語(yǔ)法的關(guān)注，增加對(duì)Java中痛苦之處的關(guān)注。Horstmann援引了C++，指出Java解決了C++碰到的兩個(gè)主要痛苦之處，內(nèi)存管理和GUI/數(shù)據(jù)庫(kù)的訪問。

然而，Java現(xiàn)在需要解決它自己的痛苦之處：

• 臃腫的代碼 —— getter和setter方法，匿名類形式的事件監(jiān)聽器，可以由編譯器推斷出來(lái)的長(zhǎng)的類型聲明。
• Web應(yīng)用開發(fā) —— 這很難，用復(fù)雜的而且動(dòng)力不足的技術(shù)，例如JSP和JSF來(lái)開發(fā)web應(yīng)用“就像用叉子來(lái)喝湯”。
  
• 并發(fā) —— “我不夠聰明，不能滿懷信心的說(shuō)我編寫的重要并發(fā)程序不會(huì)有死鎖，不會(huì)有競(jìng)爭(zhēng)條件。這就象我不夠聰明，不能滿懷信心的說(shuō)我編寫的重要C++程序不會(huì)有內(nèi)存泄露或內(nèi)存破壞”
  

其他觀點(diǎn)：

• Phillip Calçado認(rèn)為Java應(yīng)該固定而不是繼續(xù)擴(kuò)展，但是不同意關(guān)于Java本身難以閱讀的說(shuō)法，他說(shuō)在創(chuàng)建Java的時(shí)候，它比當(dāng)時(shí)的語(yǔ)言，例如C++易于閱讀
  
• Richard Relos認(rèn)為 大多數(shù)Java代碼不使用新的語(yǔ)言特性，增加新的特性僅僅分散了開發(fā)者的注意力，破壞了邏輯形式。
  
• Ian Cooper探討了C#的問題，他質(zhì)疑C#是否已經(jīng)到達(dá)了收益遞減的點(diǎn)，他同意主要新特性的去處應(yīng)該是一個(gè)新語(yǔ)言
• Giovani Salvador擔(dān)心如果Java不再增加新特性，它會(huì)過時(shí)，那么Java開發(fā)者會(huì)變成“恐龍”

你如何看待這個(gè)問題？

查看英文原文：Debate: Should the Java language stop adding new features?