對比java和python

對比java和python

2011年04月18日

1.難易度而言。python遠(yuǎn)遠(yuǎn)簡單于java。

2.開發(fā)速度。Python遠(yuǎn)優(yōu)于java

3.運行速度。java遠(yuǎn)優(yōu)于標(biāo)準(zhǔn)python，pypy和cython可以追趕java，但是兩者都沒有成熟到可以做項目的程度。

4.可用資源。java一抓一大把，python很少很少，尤其是中文資源。

5.穩(wěn)定程度。python3和2不兼容，造成了一定程度上的混亂以及大批類庫失效。java由于有企業(yè)在背后支持所以穩(wěn)定的多。

6.是否開源。python從開始就是完全開源的。Java由sun開發(fā)，但現(xiàn)在有GUN的Openjdk可用，所以不用擔(dān)心。

7.編譯還是解釋。兩者都是解釋型。

我理解，C好比手動擋車(編譯型語言)，java和python(解釋型語言)好比自動檔車。跑的最快的車都是手動檔，但是對開不好的人來說，開自動檔反而更快些。

Kno有一篇文章談到選擇編程語言，“先確定你的需求”，不要由語言的簡單還是復(fù)雜去覺定。只有能夠編寫你真正認(rèn)為有用的程式，才能獲得滿足感，學(xué)習(xí)才能繼續(xù)。

那么java和python分別適用于什么樣的環(huán)境呢。由sourceforge.net可以看出：

最著名，久經(jīng)考驗的普通應(yīng)用程序，基本都是c++寫的。例如emule，7-zip，WinSCP,FileZilla等等等。

一部分由java開發(fā)，例如最有名的OpenOffice。

python寫的很少，如Pidgin，F(xiàn)ireBird。

開發(fā)語言(有多少個程式由此語言開發(fā))的排行如下：

# Java46,202

# C++36,895

# PHP30,048

# C28,075

# C#13,476

# Python13,379

# JavaScript11,285

# Perl9,216

# Unix Shell3,869

# Delphi/Kylix3,548

# Visual Basic3,186

# Visual Basic .NET

很多框架和類庫也和應(yīng)用軟件一樣在這個列表里，因此比較公平。

由此可以看出，java不管在GNU還是商業(yè)領(lǐng)域都是應(yīng)用最廣的語言。C主要用于構(gòu)建系統(tǒng)底層。c++和java用于構(gòu)建中間應(yīng)用層。如果資源足夠，那么會選擇c++開發(fā)，以求運行速度，否則會用java開發(fā)，以求開發(fā)速度。python在各方面都比java優(yōu)秀，可謂次世代語言?？勺钍軤幾h的是它的速度，純python比java慢很多，以及背后沒有商業(yè)支持，穩(wěn)定性備受詬病。目前為止，python在商業(yè)層次上，主要作為一種膠水語言，粘合其他語言(主要是c/c++)的類庫。在GNU領(lǐng)域，主要局限于小規(guī)模的應(yīng)用和個人化應(yīng)用。以及逆向工程(黑客)應(yīng)用。

為什么java在服務(wù)器端被大量應(yīng)用，在客戶端用的卻比較少呢。難道服務(wù)器端用到的計算量反而少么。我認(rèn)為這說明對比c++，java的速度還是可以接受的。無法被接受的是JRE平臺，以及JRE平臺啟動時卡的那一會兒。我就曾經(jīng)為此認(rèn)為java寫就的程式性能低下。

python用戶常常拿來說嘴的一點是：python并不慢，因為python運行時調(diào)用了大量c庫，而c是很快的。反過來想想，這正反映了其膠水語言的事實，任何一種語言都可以調(diào)用c庫，這么比較有價值么？假如一個庫完全由python，那么它的運行效率...不說也罷。編程不能總是用別人的庫啊。

----

Python編程語言目前的使用中需要不斷的學(xué)習(xí)。下面我們就詳細(xì)的看看如何才能更好的進(jìn)行相關(guān)知識的學(xué)習(xí)。最近我一直在看一個基于wxPython的GUI應(yīng)用程序代碼，大概45.5KLOC的左右，而且這還不包括它所用到的庫(如Twisted)。

代碼是由那些對Python比較生疏的Java的開發(fā)者寫的，所以它存在很嚴(yán)重的性能問題(如三十秒的啟動時間)。在檢查代碼的時候，我發(fā)現(xiàn)他們寫了很多在Java中能講得通但是對Python編程語言來說去卻是很難接受的東西。并不是因為“Python比Java慢”，而是因為在Python中有更方便的方法去完成同樣的目標(biāo)，甚至是在Java中不可能的事情。

所以，令人難過的事就是這些家伙事倍功半，寫的那些代碼比本應(yīng)合乎用Python編程語言實現(xiàn)的慢很多。下面，讓我們來看一些例子：

◆Java中的靜態(tài)方法不能翻譯成Python的類方法。哦，當(dāng)然，他多多少少也能產(chǎn)生同樣的效果，但類方法的目的實際上是做一些通常在Java中甚至都不可能的事情(如繼承一個非默認(rèn)的默認(rèn)函數(shù))。Java靜態(tài)方法慣用的翻譯通常翻譯成一個模塊級的函數(shù)，而不是一個類方法或靜態(tài)方法。(并且靜態(tài)常量應(yīng)該翻譯成模塊級常量.)

這不是性能上的問題，但是一個Python編程語言程序員如果想調(diào)用Foo.someMethod，他要是被迫采用像Java中Foo.Foo.someMethod的方式去做的話，那么他就會被逼瘋的。有一點一定要注意:調(diào)用一個類方法需要一個額外的存儲空間,而調(diào)用靜態(tài)方法或函數(shù)就不需要這樣.

對了,還有就是這些Foo.Bar.Baz的屬性鏈也不是自己就能數(shù)出來的.在Java中,這些帶點的名稱是有編譯器來查找的,運行的時候并不會去考慮一共有多少.而在Python中,查找的過程是在運行時進(jìn)行的,所以要包括每個點.(在Python中,要記住一點,'平鋪的結(jié)構(gòu)別嵌套的要好',盡管相對于從性能方面來說,可能它更多涉及的是'可讀性'和'簡單要比復(fù)雜好'.)

◆要使用switch語句嗎?Python編程語言將是一個哈希表，不是一堆if-then語句。要使用在Java中不是switch語句而且還有字符串參與了的一堆if-then語句嗎?它將仍然是一個哈希表。CPython字典是用在我們所了解的領(lǐng)域中認(rèn)為是最佳性能之一的哈希表來實現(xiàn)的。你自己所寫的代碼也不會比這個再好了，除非你是Guido、Tim Peters和Raymond Hettinger的私生子,而且還是遺傳增強了的。

◆XML不是答案。它也不是一個問題?，F(xiàn)在用正則表達(dá)式來解釋Jamie Zawinski，“一些人，當(dāng)他遇到一個問題的時候，就會想'我知道，我要用XML.’那么他們就有兩個問題了。”

相對于在Java中來說這是個不同的情況，因為比起Java代碼，XML是靈活而且有彈性的。但比起Python的代碼來，XML就是一個船錨，一個累贅。在Python中，XML是用來協(xié)同工作的，而不是你的核心功能，因為你不需要那么做。在Java中，XML可能是你的救世主,因為它讓你實現(xiàn)了特定領(lǐng)域的語言并且“不用編碼”就提高你的應(yīng)用程序的適應(yīng)性。在Java中，避免編碼是一個很大的優(yōu)勢，因為編碼意味著重新編譯。但在Python中，通常是，寫代碼比寫XML更簡單。還有就是Python處理代碼要比處理XML快很多很多。(不僅僅是這個，你必須寫XML處理代碼，同時Python就已經(jīng)為你寫好了.)

如果你是一個Java程序員，你并不能利用本能知覺來考慮你是否要在你的Python核心應(yīng)用中使用XML作為一部分。如果你不是因為信息交互的原因去實現(xiàn)一個已經(jīng)存在的XML標(biāo)準(zhǔn)或是建立某種輸入、輸出格式或者建立某種XML編輯器或處理工具，那么就不要這么做。根本不要去這么做。甚至連想都不要想?，F(xiàn)在，丟掉那個XML模式然后把你的手解放出來吧！如果你的應(yīng)用程序或者平臺要被Python編程語言開發(fā)者使用，他們只會感謝你不要在他們的工作中添加使用XML的負(fù)擔(dān)。

(這里唯一的例外是如果你的客戶(your target audience)確確實實因為某些原因而需要使用XML。就好像，他們拒絕學(xué)習(xí)Python但如果你使用XML他們就給你付錢，或者你打算給他們一個很棒的能編輯XML的GUI，還有就是這個XML的GUI是另一個人寫的，同時你得到免費使用的權(quán)利。還有一些很少見的架構(gòu)上的原因需要用到XML。相信我，它們不會應(yīng)用到你的程序中去的。如果有疑問，對一個資深的Python開發(fā)員解釋你的用例。或者，如果你臉皮厚而且不介意被人嘲笑的話，試試向一個Lisp程序解釋你的程序為什么要用XML!)

◆Getter和setter是惡魔。我應(yīng)該說它是惡魔,是魔鬼！Python編程語言對象不是Java Bean。不要寫什么getter和setter，而是還把它們內(nèi)置在“屬性”里面。它直到你能證明你需要比一個簡單訪問復(fù)雜一點的功能時才有意義，要不然，不要寫getter和setter。它們是CPU時間的浪費，更要緊的是，它們還是程序員寶貴時間的浪費。不僅僅對于寫代碼和測試的人，對于那些要閱讀和理解它們的人也是。

在Java中，你必須使用getter和setter,因為公共字段不允許你以后改變想法再去使用getter和setter。所以,在Java中你最好事先避開這些'家務(wù)雜事'.在Python中，這樣做很傻，因為你可以以一個普通特性開始并可以在任何時間改變你的想法，而不用影響到這個類的任何客戶。所以不要寫getter和setter方法。

◆代碼重復(fù)在Java中通常來說就是一場不可避免的災(zāi)禍，你必須經(jīng)常反復(fù)地寫同一個方法而只有一點點的變化(通常是這是因為靜態(tài)類型約束)。在Python中這樣做是沒有必要的也是不值得的(除了極少數(shù)一些特定的場合需要內(nèi)聯(lián)一些要求性能的函數(shù))。如果你發(fā)現(xiàn)自己一遍一遍在寫同樣的代碼而且變化很少，你就需要去學(xué)一下閉包。他們實際不并是那么可怕。

這就是你要做的。你寫了一個包含了函數(shù)的函數(shù)。這里內(nèi)部的函數(shù)就是你要一遍遍寫的函數(shù)的模版，但是在里面加入了針對不同情況的函數(shù)要使用變量。外部的函數(shù)需要剛剛提高的那種變量作為參數(shù)，并且將內(nèi)部的函數(shù)作為結(jié)果返回。然后，每次你要寫另一種略微不同的函數(shù)的時候，你只要調(diào)用這個外部的函數(shù)，并且把返回值賦給你要讓“重復(fù)”函數(shù)出現(xiàn)的名字?，F(xiàn)在，如果你需要改變這個工作方式，你只需要改變一個地方：這個模版。

在我所看過的應(yīng)用程序/平臺中，只有一個很微不足道的程序使用了這個技術(shù),它去掉了數(shù)百行重負(fù)的代碼。實際上，因為開發(fā)者使用了特別的樣板文件來為這個平臺開發(fā)插件，所以這會節(jié)省很多很多第三方開發(fā)人員的代碼，同時也使那些程序員要學(xué)習(xí)的東西變得簡單了。

這只是Java->Python編程語言思維方式轉(zhuǎn)變的冰山一角而已，現(xiàn)在我能正確的轉(zhuǎn)變而不用去鉆研程序的細(xì)節(jié)。本質(zhì)上，如果你曾經(jīng)用過一段時間Java，而且對Python比較陌生，那么你不要太相信自己的本能。你的本能已經(jīng)被Java調(diào)節(jié)，而不是Python。向后退一步來說，最重要的是不要再寫這么多代碼了。

為了這樣做，讓自己覺得更加需要Python。假裝好像Python是可以做任何你想做的魔棒，而你無須出一點力。問一下，“Python怎樣解決我的問題？”還有“Python語言的哪個特點和我的問題最相似？”如果對于你需要的東西其實已經(jīng)有了某種固定形式,那么你絕對會感到驚訝的。事實上，這種現(xiàn)象實在是太普遍了，甚至即使在很有經(jīng)驗的Python程序員中也會出現(xiàn)，以至于Python社區(qū)中給這種現(xiàn)象起了個名字。我們稱之為“GUIDO的時間機器”，因為在我們自己還沒有掌握它之前,通?？瓷先ヒ玫轿覀兯枰臇|西好像那是唯一的方法。

所以，如果你在使用Python編程語言時候不能感到比使用Java要至少多出10倍的生產(chǎn)力話，你就最好做一下改動,你是不是忘記使用time machine!(chances are good that you've been forgetting to use the time machine)(同時如果你還懷念你的Java IDE，你可以這樣想：因為你寫的Python程序比他所需要的要復(fù)雜得多.)