對比java和python對比

對比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
　　# C28,075
　　# C#13,476
　　# Python13,379
　　# JavaScript11,285
　　# Perl9,216
　　# Unix Shell3,869
　　# Delphi/Kylix3,548
　　# Visual Basic3,186
　　# Visual Basic .NET
　　不少框架和類庫也和應用軟件同樣在這個列表裏，所以比較公平。
　　由此能夠看出，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，那麼它的運行效率...不說也罷。編程不能老是用別人的庫啊。

----

Python編程語言目前的使用中須要不斷的學習。下面咱們就詳細的看看如何才能更好的進行相關知識的學習。最近我一直在看一個基於wxPython的GUI應用程序代碼，大概45.5KLOC的左右，並且這還不包括它所用到的庫(如Twisted)。

代碼是由那些對Python比較生疏的Java的開發者寫的，因此它存在很嚴重的性能問題(如三十秒的啓動時間)。在檢查代碼的時候，我發現他們寫了不少在Java中能講得通可是對Python編程語言來講去倒是很難接受的東西。並非由於「Python比Java慢」，而是由於在Python中有更方便的方法去完成一樣的目標，甚至是在Java中不可能的事情。

因此，使人難過的事就是這些傢伙事倍功半，寫的那些代碼比本應合乎用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是另外一我的寫的，同時你獲得無償使用的權利。還有一些不多見的架構上的緣由須要用到XML。相信我，它們不會應用到你的程序中去的。若是有疑問，對一個資深的Python開發員解釋你的用例。或者，若是你臉皮厚並且不介意被人嘲笑的話，試試向一個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編程語言進行描述

 

這就是你要作的。你寫了一個包含了函數的函數。這裏內部的函數就是你要一遍遍寫的函數的模版，可是在裏面加入了針對不一樣狀況的函數要使用變量。外部的函數須要剛剛提升的那種變量做爲參數，而且將內部的函數做爲結果返回。而後，每次你要寫另外一種略微不一樣的函數的時候，你只要調用這個外部的函數，而且把返回值賦給你要讓「重複」函數出現的名字。如今，若是你須要改變這個工做方式，你只須要改變一個地方：這個模版。

在我所看過的應用程序/平臺中，只有一個很微不足道的程序使用了這個技術,它去掉了數百行重負的代碼。實際上，由於開發者使用了特別的樣板文件來爲這個平臺開發插件，因此這會節省不少不少第三方開發人員的代碼，同時也使那些程序員要學習的東西變得簡單了。

這只是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程序比他所須要的要複雜得多.)