C++和Java傳統中積極的一面
作者：Bruce Eckel
譯者：趙錕、陳皓
譯者注：
本文翻譯自Bruce Eckel（《Thinking in C++》& 《Thinking in Java》作者）的博文，該博文於2009年03月14日發表於：
本文的發表引起了互聯網上熱烈的討論，關於討論大家可以到這裏圍觀。
下面是原文。原名《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必然被別的語言所取代。