對比java和python
對比java和python
2011年04月18日
1.難易度而言。 python遠遠簡單於java。
2.開發速度。 Python遠優於java
3.運行速度。 java遠優於標準python，pypy和cython可以追趕java，但是兩者都沒有成熟到可以做專案的程度。
4.可用資源。 java一抓一大把，python很少很少，尤其是中文資源。
5.穩定程度。 python3和2不相容，造成了一定程度上的混亂以及大批程式庫失效。 java由於有企業在背後支持所以穩定的多。
6.是否開源。 python從開始就是完全開源的。 Java由sun開發，但現在有GUN的Openjdk可用，所以不用擔心。
7.編譯還是解釋。兩者都是解釋型。
我理解，C好比手排車（編譯型語言），java和python（解釋型語言）好比自排車。跑的最快的車都是手排檔，但是對開不好的人來說，開自排反而更快。
Kno有一篇文章談到選擇程式語言，“先確定你的需求”，不要由語言的簡單還是複雜去覺定。只有能夠編寫你真正認為有用的程式，才能獲得滿足感，學習才能繼續。
那麼java和python分別適用於什麼樣的環境呢。由sourceforge.net可以看出：
最著名，久經考驗的普通應用程序，基本上都是c++寫的。例如emule，7-zip，WinSCP,FileZilla等等等。
一部分由java開發，例如最有名的OpenOffice。
python寫的很少，如Pidgin，FireBird。
開發語言（有多少個程式由此語言開發）的排行如下：
# Java46,202
# C++36,895
# php30,048〜175 75 75 75〜475
# Python13,379
# Javascript11,285
# Perl9,216
# Unix Shell3,869
# Delphi/Kylix3,548
》# Visualic3,18653,548
NET 》# Visualic3,186)一樣在這個列表裡，因此比較公平。
由此可以看出，java不管在GNU或商業領域都是應用最廣的語言。 C主要用於建構系統底層。 c++和java用於建構中間應用層。如果資源夠，那麼就會選擇c++開發，以求運行速度，否則會用java開發，以求開發速度。 python在各方面都比java優秀，可謂次世代語言。可最有爭議的是它的速度，純python比java慢很多，以及背後沒有商業支持，穩定性備受詬病。目前為止，python在商業層次上，主要作為一種膠水語言，黏合其他語言（主要是c/c++）的類別庫。在GNU領域，主要侷限於小規模的應用和個人化應用。以及逆向工程（駭客）應用。
為什麼java在伺服器端被大量應用，在客戶端用的卻比較少呢。難道伺服器端用到的計算量反而少麼。我認為這說明對比c++，java的速度還是可以接受的。無法被接受的是JRE平台，以及JRE平台啟動時卡片的那一會兒。我就曾經為此認為java寫就的程式效能低。
python用戶常拿來說嘴的一點是：python並不慢，因為python運行時調用了大量c庫，而c是很快的。反過來想想，這正反映了其膠水語言的事實，任何一種語言都可以調用c庫，這麼比較有價值？假如一個函式庫完全由python，那麼它的運作效率...不說也罷。程式設計不能總是用別人的函式庫啊。
----
◆Java中的靜態方法不能翻譯成Python的類別方法。哦，當然，他多多少少也能產生同樣的效果，但類別方法的目的實際上是做一些通常在Java中甚至都不可能的事情(如繼承一個非預設的預設函數)。 Java靜態方法慣用的翻譯通常翻譯成一個模組級的函數，而不是一個類別方法或靜態方法。 (且靜態常數應該翻譯成模組級常數.)
這不是效能上的問題，但是一個Python程式語言程式設計師如果想呼叫Foo.someMethod，他要是被迫採用像Java中Foo.Foo.someMethod的方式去做的話，那麼他就會被逼瘋的。有一點一定要注意:呼叫一個類別方法需要一個額外的儲存空間,而呼叫靜態方法或函數就不需要這樣.
對了,還有就是這些Foo.Bar.Baz的屬性鏈也不是自己就能數出來的.在Java中,這些帶點的名稱是有編譯器來查找的,運行的時候並不會去考慮一共有多少.而在Python中,查找的過程是在運行時進行的,所以要包括每個點.(在Python中,要記住一點,"平舖的結構別嵌套的要好",儘管相對於從性能方面來說,可能它更多涉及的是"可讀性"和"簡單要比複雜好".)
◆要使用switch語句嗎?Python程式語言將是一個雜湊表，不是一堆if-then語句。要使用在Java中不是switch語句而且還有字串參與了的一堆if-then語句嗎?它將仍然是一個哈希表。 CPython字典是用在我們所了解的領域中認為是最佳性能之一的哈希表來實現的。你自己所寫的程式碼也不會比這個再好了，除非你是Guido、Tim Peters和Raymond Hettinger的私生子,而且還是遺傳增強了的。
◆xml不是答案。它也不是一個問題。現在用正規表示式來解釋Jamie Zawinski，「有些人，當他遇到一個問題的時候，就會想『我知道，我要用XML.』那麼他們就有兩個問題了。」
相對於在Java中來說這是個不同的情況，因為比起Java程式碼，XML是靈活且有彈性的。但比起Python的程式碼來，XML就是一個船錨，一個累贅。在Python中，XML是用來協同工作的，而不是你的核心功能，因為你不需要那麼做。在Java中，XML可能是你的救世主,因為它讓你實現了特定領域的語言並且「不用編碼」就提高你的應用程式的適應性。在Java中，避免編碼是一個很大的優勢，因為編碼意味著重新編譯。但在Python中，通常是，寫程式比寫XML更簡單。還有Python處理程式碼要比處理XML快很多很多。 (不只是這個，你必須寫XML處理程式碼，同時Python就已經為你寫好了.)
如果你是一個Java程式設計師，你並不能利用本能知覺來考慮你是否要在你的Python核心應用中使用XML作為一部分。如果你不是因為資訊互動的原因去實現一個已經存在的XML標準或是建立某種輸入、輸出格式或建立某種XML編輯器或處理工具，那就不要這麼做。根本不要去這麼做。甚至連想都不要想。現在，丟掉那個XML模式然後把你的手解放出來吧！如果你的應用程式或平台要被Python程式語言開發者使用，他們只會感謝你不要在他們的工作中加入使用XML的負擔。
(這裡唯一的例外是如果你的客戶(your target audience)確確實實因為某些原因而需要使用XML。就好像，他們拒絕學習Python但如果你使用XML他們就給你付錢，或者你打算給他們一個很棒的能編輯XML的GUI，還有就是這個XML的GUI是另一個人寫的，同時你得到免費使用的權利。 。 Lisp程式解釋你的程式為什麼要用XML!)
◆Getter和setter是惡魔。我應該說它是惡魔,是魔鬼！ Python程式語言物件不是Java Bean。不要寫什麼getter和setter，而是還把它們內建在「屬性」裡面。它直到你能證明你需要比一個簡單存取複雜一點的功能時才有意義，要不然，不要寫getter和setter。它們是CPU時間的浪費，更要緊的是，它們還是程式設計師寶貴時間的浪費。不僅僅對於寫程式碼和測試的人，對於那些要閱讀和理解它們的人也是如此。
在Java中，你必須使用getter和setter,因為公共欄位不允許你以後改變想法再去使用getter和setter。所以,在Java中你最好事先避開這些"家務雜事".在Python中，這樣做很傻，因為你可以以一個普通特性開始並可以在任何時間改變你的想法，而不用影響到這個類的任何客戶。所以不要寫getter和setter方法。
◆程式碼重複在Java中通常來說就是一場不可避免的災禍，你必須經常反覆地寫同一個方法而只有一點點的變化(通常是這是因為靜態類型約束)。在Python中這樣做是沒有必要的也是不值得的(除了極少數一些特定的場合需要內聯一些要求性能的函數)。如果你發現自己一遍一遍在寫同樣的程式碼而且變化很少，你就需要去學一下閉包。他們實際上不並是那麼可怕。
對Python程式設計技巧大總結
簡讀彈性的Python程式語言
短時間內掌握Python程式語言
對Python程式語言歷史說明介紹
有關Python程式語言
對Python程式語言歷史說明介紹有關Python程式設計語言進行說明這就是說明。你要做的。你寫了一個包含了函數的函數。這裡內部的函數就是你要一遍遍寫的函數的模版，但是在裡面加入了針對不同情況的函數要使用變數。外部的函數需要剛剛提高的那種變數作為參數，並且將內部的函數作為結果傳回。然後，每次你要寫另一個略微不同的函數的時候，你只要呼叫這個外部的函數，並且把回傳值賦給你要讓「重複」函數出現的名字。現在，如果你需要改變這個工作方式，你只需要改變一個地方：這個模版。 在我所看過的應用程式/平台中，只有一個很微不足道的程式使用了這個技術,它去掉了數百行重負的程式碼。實際上，因為開發者使用了特別的樣板文件來為這個平台開發插件，所以這會節省很多很多第三方開發人員的程式碼，同時也讓那些程式設計師要學習的東西變得簡單了。 這只是Java->Python程式語言思維方式轉變的冰山一角而已，現在我能正確的轉變而不用去鑽研程式的細節。本質上，如果你曾經用過一段時間Java，而且對Python比較陌生，那麼你不要太相信自己的本能。你的本能已經被Java調節，而不是Python。向後退一步來說，最重要的是不要再寫這麼多程式碼了。 為了這樣做，讓自己覺得更需要Python。假裝好像Python是可以做任何你想做的魔棒，而你無須出一點力。問一下，「Python怎麼解決我的問題？」還有「Python語言的哪個特點和我的問題最相似？」如果對於你需要的東西其實已經有了某種固定形式,那麼你絕對會感到驚訝的。事實上，這種現象實在是太普遍了，即使在很有經驗的Python程式設計師中也會出現，以至於Python社群中給這種現象取了個名字。我們稱之為“GUIDO的時間機器”，因為在我們自己還沒有掌握它之前,通常看上去要得到我們所需要的東西好像那是唯一的方法。 所以，如果你在使用Python編程語言時候不能感到比使用Java要至少多出10倍的生產力話，你就最好做一下改動,你是不是忘記使用time machine!(chances are good that you' ve been forgetting to use the time machine)(同時如果你還懷念你的Java IDE，你可以這樣想：因為你寫的Python程式比他所需要的要複雜得多.) 以上就是對比java和python對比的內容，更多相關文章請關注PHP中文網（www.php.cn）！
