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