C++和Java傳統中積極的一面

C++和Java傳統中積極的一面

做者：Bruce Eckel
譯者：趙錕、陳皓

譯者注：

本文翻譯自Bruce Eckel（《Thinking in C++》& 《Thinking in Java》做者）的博文，該博文於2009年03月14日發表於：

[url]http://www.artima.com/weblogs/viewpost.jsp?thread=252441[/url]

本文的發表引發了互聯網上熱烈的討論，關於討論你們能夠到 這裏圍觀。

下面是原文。原名《 The Positive Legacy of C++ and Java》

摘要：

在最近的討論中，有些人判定C++並非一個設計完美的語言。在我在C++標準委員那8年裏，我目擊全部關於C++的決議的誕生。我但願本文有助於幫讀者理解C++和JAVA的設計選擇，從而可讓你們更全面的來看待他們。
 

有人說，我不多再使用C++。當我使用C++時，我只是爲了測試一下陳舊的代碼，或者寫一個和性能密切相關的程序，一般這個程序很是小，而且經過其餘的語言來調用。(我喜歡的作法是，用Python快速開發一個程序，用profile輔助程序對其進行性能優化，若是須要的話，經過Python的ctypes調用C++寫的程序來改善性能)。

由於我曾經是C++標準委員會的一員，我目擊了這些決議的產生。這些C++決議都是在通過超級深思熟慮的考慮以後在作出，他們遠比大多數Java的決議更爲謹慎當心。

然而，就像有些人準確地指出那樣，C++是複雜而難於使用的，而且充滿了各類個樣容易讓人忘記的古怪的規則。當我在寫書的時候，我只能從規範中找到這些規則的說明，而不是本身能記住這些規則。

爲了讓人們理解C++這門語言如何即難用、複雜，同時還要有良好的設計，你必須記住一條C++中最主要的設計原則——兼容C語言。這是Stroupstru最正確的決定，這樣作將會出現一條讓大量的C程序員通向C++程序的捷徑：這條捷徑容許C程序員不須要作任何修改就能夠在C++下編譯程序。然而，這也成爲了C++語言巨大的約束，它給C++帶來了強大的力量，同時也給C++帶來了無盡的痛楚。正是由於這個約束致使了C++如此的成功，而且也如此的複雜。

這些C++古怪的條約使那些沒有徹底瞭解C++的Java的設計者們犯了傻。例如，他們認爲程序員能用好操做符重載將會是很是困難的一件事。可是操做符重載在C++中倒是必須的，由於在C++中有棧分配，同時又有堆上的分配，你只有經過重載好操做符來處理好不一樣類型的內存分配，並保證不會產生內存泄漏，的確是難！但對Java來講，由於Java只有單一的一種內存分配機制（ 譯者注：Java基本上是採用堆分配）和垃圾回收機制，這樣操做符重載在Java中就變得多餘（正如C#的操做符重載，和更早以前的Python操做重載，可是Python出現的要比Java早）。可是多年以來，來自Java的團隊就一致認爲「操做符重載太過複雜」。這一決議或其餘的一些Java決議，明顯說明了不少Java的設計者在作出決議的時候沒有作足本身的工做，這也是爲何我有了一個藐視由Gosling和他的Java團隊所作決議的名聲。

一樣還有太多太多的例子，基本類型「由於性能緣由被引入」。真正的緣由是爲了堅持「全部都是對象」，而且同時爲底層具備效率要求的程序提供一個後門（同時這也使得一些熱點技術執行起來更有效率）。噢，可是事實是，你沒有辦法直接使用浮點處理器來進行超越函數的計算（ 譯者注： Transcendental Functions ，一種微積分的函數），而只能使用軟件來計算，但本來這類函數就可使用浮點計算處理器來計算的。我盡我所能將相似這樣的問題羅列出來，可是我聽到的結果卻老是那些無用的回答「這就是Java的方式」。

當我寫下泛型是個如何糟糕的設計時，我獲得了一樣的迴應，「咱們必須兼容以前的（糟糕的）Java的決議」。最後愈來愈多的人們得到了足夠關於泛型是多難用的經驗——的確，C++的泛型更強大，一致性更好（尤爲如今當編譯器的錯誤信息愈來愈清晰後，泛型也比之前更好使用），由於Java泛型設計不好，很難，因此人們又開始回到認真對待具現化而不是泛型，固然，這對語言是有幫助的，由於具現化這個東西並不會消弱太多的語言設計，也不會由於這些自我限制而致使語言缺陷。

那個Java的問題列表在這些沉悶的迴應面前只能顯得單調乏味。那麼，是否是這樣就意味着Java是失敗的語言設計呢？絕對不是，Java將主流程序員帶入到了一個垃圾收集器、虛擬機、一致的錯誤處理模型的世界(若是你不使用異常處理，這類異常多是很是有用的異常，正如我在《Think in Java 》4ed中演示的那樣)。伴隨着它設計上種種缺陷，Java把咱們帶領到了一個更高的層次，在這個層次上咱們正在準備着迎接更爲高級別的語言。（ 譯者注：做者在這裏大意是說Java幹了不少事雖然很不成熟，可能還有點失敗，但他的成功以外是能讓咱們找到一種通往更爲高級別的語言的鋪路石。做者在這裏有譏諷的意思。）

另外一個觀點，人們一直認爲C++是語言中的先驅，許多人也認爲Java是語言的先驅。可是由於虛擬機，Java使得本身更容易被別的語言替代。如今任何人都有可能快速建立一門新的語言，而且和Java具備同樣的效率；而之前，要獲得一個正確的，有效率的編譯器花去了開發一門新語言的大部分時間。（ 譯者注：做者在這裏大意是說C++是先驅，而Java由於虛擬機讓其性能比較差，有時還不如別的語言。做者在這裏再次譏諷了Java的高不成低不就。）

如今，咱們正在見證這一切的發生——不論是更高級的靜態語言，例如Scala，或者說是動態語言（ 譯者注：Dynamic Language，如Python或Ruby），不論是新的仍是移植的，例如Groovy ，JRuby和Jython。這就是將來的趨勢，而且其過分將會很是的平滑，由於你能夠在已有的Java代碼中使用這些新語言，若是有須要，你甚至能夠重寫Java中產生有性能瓶頸的地方。

正如C++會消亡同樣，Java自生有可能消亡，或着被用於特殊環境之下（或僅僅是爲了支持之前遺留的代碼，由於Java並不像C++那樣會被用於硬件編程）。可是Java 真正的亮點，也是意料以外的收穫，就是若是當Java已經到了自身無法在進化的地步時，Java已經爲其替代者建立一條平滑之路。全部將來的語言都將從這裏學到：要麼爲本身建立一種能夠不斷重構(進化)(正如Python和Ruby作的那樣)的文化，要麼就讓其競爭者發展壯大。

譯者注：做者本文的大意是在從側面鄙視Java標準委員會的不少決議，做者認爲Java這種靜態語言性能上強不過C++，而後還不停地加入太多的動態語言的東西，搞很差還不如那些動態語言（如Python或Ruby），整得本身高不成低不就，其如今還不如其過去，Java再這樣搞下去，將來的Java必然被別的語言所取代。