Python的Version 3.0已經發(fā)布。Notably Python又做了一些Java一直很反對的事情：打破了與Python 2.x的向后兼容（Backwards compatibility），Notable修改了一個更加理智的基于Unicode的字符串處理模型。Pythonista的同仁告訴我很多其他不合理的東西如print operator也已經清除。盡管如此，我還是不建議所有的Python開發(fā)者立馬升級（version 2.x仍將在接下來的幾年中得到支持。）version 3.0顯然是一個比version 2.x更加簡單、更加優(yōu)秀和合理的編程語言，這將提高開發(fā)者的效率并讓他們的工作更加富有樂趣。顯然，Python是一個充滿生機的、不斷進步的語言。
相比較而言，Java則死氣沉沉。像Python 2.x 一樣，它也包含許多不合理和錯誤設計的地方（或許Java更多），但Sun一直拼死反對做任何事情來修補這些眾所周知的問題。相反，在過去的12年里Sun不但不給這個臟兮兮的家伙洗澡刷牙，卻對它噴香水、抹唇膏。（意指Sun不但不修補這些問題，還縱之任之）
對version 1.4的Java而言，向后兼容（Backwards compatibility）是一個利于維護很有用的功能，但在Java 5 中，當泛化（generics）和自動裝箱機制（Autoboxing）改變了語言的核心時，向后兼容（Backwards compatibility）徹底地出現(xiàn)問題。自動裝箱機制（Autoboxing）是一個錯誤的選擇，它試圖掩蓋住Java早期對原始（primitives）和對象（objects）采用隔離的類系統(tǒng)（type system）的決定。那是Java的Plessy v. Ferguson決定，原始（primitives）和對象（objects）是獨立但等同的。一個獨立的原始類型系統(tǒng)（primitive type system）在1995年的時候很有意義，那時CPU緩慢而且虛擬機技術并不先進?，F(xiàn)在原始類型除了將編程語言更加復雜化之外，別無他處。
泛化（generics）是另一個例子：在這兒向后兼容（Backwards compatibility）出了個好主意，最后卻變成恐怖的東西。多線程設計（Multiple design）能夠使代碼運行在老的VM上，也即的類型擦除（type erasure）。最后，不管怎樣，二進制兼容破碎。然而，如果他們不擔心落后的二進制兼容而重新設計，沒有人考慮泛化（generics）多么簡單有力。
閉包（Closures）如果現(xiàn)在加入，只會將形式更加惡化。當且僅當在Java同時移除內部類（inner classes）并做出所有的語法改變來支持真正的閉包（Closures）時，閉包（Closures）對語言而言才是好的特性。同樣的，新的特性不能夠添加到現(xiàn)有的羸弱基礎之上，除非我們回到語言設計的初期從頭設計。
我無法想到還有像Java一樣老的主流語言并試圖維護version 1.0的兼容性，實際上，我能想到的有C#，但C#年齡只有Java的一半。除非我們做出艱難的抉擇，并像Python一樣摒棄那些傳統(tǒng)，否則Java將注定將像C++和Cobol一樣：留著長長的白胡子的開發(fā)者工具，自編程語言之初就存在并其后不斷發(fā)展添加，花大量時間用在維護十年前的代碼上。與此同時，新一代的開發(fā)者將因為更加現(xiàn)代的語言如Python而拋棄Java，就如同當年我們?yōu)榱薐ava拋棄C++一樣。
承認存在問題只是解決問題的第一步，但Java甚至都沒有承認他有問題。這個語言很大，很復雜。在單核奔騰2、100Mhz處理器和32位存儲空間實用的東西，現(xiàn)在已經遠遠落伍。向后兼容（Backwards compatibility）已經成為纏繞在Java腳上的沉重枷鎖。除非摘掉這個枷鎖、更正以前的錯誤，Java和我們才能邁步向前。
很難相信，五年前我就發(fā)出了這樣的聲音，然而至今仍然沒有任何改變，而且事實反而更加糟糕。看看C++當年被Java替代的歷史，也許Java也敗局已定，是時候有新的語言來取代這個語言了？
相比較而言，Java則死氣沉沉。像Python 2.x 一樣，它也包含許多不合理和錯誤設計的地方（或許Java更多），但Sun一直拼死反對做任何事情來修補這些眾所周知的問題。相反，在過去的12年里Sun不但不給這個臟兮兮的家伙洗澡刷牙，卻對它噴香水、抹唇膏。（意指Sun不但不修補這些問題，還縱之任之）
對version 1.4的Java而言，向后兼容（Backwards compatibility）是一個利于維護很有用的功能，但在Java 5 中，當泛化（generics）和自動裝箱機制（Autoboxing）改變了語言的核心時，向后兼容（Backwards compatibility）徹底地出現(xiàn)問題。自動裝箱機制（Autoboxing）是一個錯誤的選擇，它試圖掩蓋住Java早期對原始（primitives）和對象（objects）采用隔離的類系統(tǒng)（type system）的決定。那是Java的Plessy v. Ferguson決定，原始（primitives）和對象（objects）是獨立但等同的。一個獨立的原始類型系統(tǒng)（primitive type system）在1995年的時候很有意義，那時CPU緩慢而且虛擬機技術并不先進?，F(xiàn)在原始類型除了將編程語言更加復雜化之外，別無他處。
泛化（generics）是另一個例子：在這兒向后兼容（Backwards compatibility）出了個好主意，最后卻變成恐怖的東西。多線程設計（Multiple design）能夠使代碼運行在老的VM上，也即的類型擦除（type erasure）。最后，不管怎樣，二進制兼容破碎。然而，如果他們不擔心落后的二進制兼容而重新設計，沒有人考慮泛化（generics）多么簡單有力。
閉包（Closures）如果現(xiàn)在加入，只會將形式更加惡化。當且僅當在Java同時移除內部類（inner classes）并做出所有的語法改變來支持真正的閉包（Closures）時，閉包（Closures）對語言而言才是好的特性。同樣的，新的特性不能夠添加到現(xiàn)有的羸弱基礎之上，除非我們回到語言設計的初期從頭設計。
我無法想到還有像Java一樣老的主流語言并試圖維護version 1.0的兼容性，實際上，我能想到的有C#，但C#年齡只有Java的一半。除非我們做出艱難的抉擇，并像Python一樣摒棄那些傳統(tǒng)，否則Java將注定將像C++和Cobol一樣：留著長長的白胡子的開發(fā)者工具，自編程語言之初就存在并其后不斷發(fā)展添加，花大量時間用在維護十年前的代碼上。與此同時，新一代的開發(fā)者將因為更加現(xiàn)代的語言如Python而拋棄Java，就如同當年我們?yōu)榱薐ava拋棄C++一樣。
承認存在問題只是解決問題的第一步，但Java甚至都沒有承認他有問題。這個語言很大，很復雜。在單核奔騰2、100Mhz處理器和32位存儲空間實用的東西，現(xiàn)在已經遠遠落伍。向后兼容（Backwards compatibility）已經成為纏繞在Java腳上的沉重枷鎖。除非摘掉這個枷鎖、更正以前的錯誤，Java和我們才能邁步向前。
很難相信，五年前我就發(fā)出了這樣的聲音，然而至今仍然沒有任何改變，而且事實反而更加糟糕。看看C++當年被Java替代的歷史，也許Java也敗局已定，是時候有新的語言來取代這個語言了？