一、異同對比選擇
1、Python和ruby的相同點：
都強調語法簡單，都具有更一般的表達方式。python是縮排，ruby是類basic的表達。都大量減少了符號。
都是動態資料型別。都是有豐富的資料結構。
都具有C語言擴充套件能力，都具有可移植性，比perl的可移植性更好。也都可以作為嵌入語言。
都是物件導向的語言，都可以作為大專案的開發工具。
都有豐富的庫支援。
也有最寬鬆的版權許可，除了一些工具屬於GNU世界。
都有lisp特色的eval函式，也都能把函式作為引數。
也有圖形介面的ruby的專門編輯器。
都獲得了廣泛的c庫的支援。如qt、gtk、tk、SDL、FOX等，ruby計劃實現SWIG介面。
都有完善的文件。
2、和python相比ruby的優點：
具有正規表示式和嵌入html的功能。python也有正規表示式，但沒有ruby的應用方便和廣泛。python的嵌入html專案才剛起步。ruby還有apache的mod模組。ruby本身也實現和很多unix工具，如racc，doctools。比python更親近Linux。
比python功能更完整的物件導向的語法。
ruby的整個庫都是具有類繼承的結構。
他的基本的資料型別和運算子都是可以過載的。
ruby主要的功能都是透過物件的方法呼叫來實現的，而不是函式。python也在向這方面發展，但沒有ruby做的徹底。
ruby的類是更規範的單繼承，還有介面等概念的實現。
python可以實現在列表內的條件語句、迴圈語句，而ruby用“塊”的方式來實現這個功能，比python的更靈活，更具有通用性。
ruby具有類似lisp的徹底的函式方式的條件語句、迴圈語句等。語句的表達能力更強。
附帶一些unix工具，如racc等。
3、和python相比ruby的不足：
最大的不足正是因為ruby的強大所引起的。它沒有python的簡單性好。比較複雜的物件導向語法、“塊”語法的引入、正規表示式的引入、一些簡寫標記都增加了語言的複雜性。
python的縮排表達方式比ruby的basic的表達方式更讓人悅目，ruby程式的滿眼的end讓人不舒服。當然，ruby認為end的方式比python更先進。
ruby還沒有python的“自省”的能力，沒有從程式檔案中生成文件的能力。
ruby沒有國際化的支援。國際化支援在ruby的計劃中。這是因為ruby的歷史比python要短造成的。
ruby沒有類似jython的東西。
4、python和ruby的語言的選擇：
從簡單的就是好的來說，選python是沒錯的。python適合尋找簡單語言的人，這很可能造成python更流行，因此也有更多的支援。但如果要追求更強大的語法功能，則ruby是好的選擇。因為ruby和python的哲學有很多相似的地方，先從python入手，儘量用python，如果python的能力不足了，可以在找ruby。
ruby和python的比較，就像五筆和拼音輸入法的比較。拼音作為入門的輸入法和長久使用的輸入法都沒有問題。五筆適合更高要求的情況。如果追求效能的不妨學學ruby。對程式語言感興趣，想了解各種程式設計概念的學ruby也會很興奮。
二、兩者各有特點：
1、Python從語法上來說更質樸一些，而Ruby更性感一些
Python的語法相對其他指令碼語言來說，沒有太多花巧的地方，顯得比較死板一點，其實從Python強制程式碼縮排也可以看出來Guido設計語言的取向。語法死板的一面就是不容易玩出來更性感的東西，比方說Rails這樣的框架，另外Python也無法做DSL這樣的事情，但是語法死板的另一面就是比較規範，相對來說，更加適應軟體開發的工程性要求，更容易組織大規模的團隊進行開發。
Ruby的語法非常靈活，Matz設計ruby的出發點也是為了coding for fun，因此可以用ruby玩出來很多花樣，運用足夠的技巧，可以用Ruby寫出來逼近自然語言的DSL，對於程式設計師來說，玩ruby確實充滿了樂趣。Rails能在ruby社群誕生，而不是Python社群誕生絕對和程式語言有直接的關係。不過ruby語法靈活的另一面就是程式設計實現風格的多樣性，這對於大規模團隊的協作和管理是一個挑戰。
2、Python的解析器實現更成熟，第三方庫質量高
Ruby1.9解析器儘管已經有了很大的效能提升和很多新的功能，但是從原始碼實現的角度來說，基本上是透過在Ruby1.8原始碼上打patch來增加功能的。從原始碼的結構來說，Ruby的實現太古老了，Ruby擴充套件起來比較困難，只能不斷打patch。這也是為什麼現在Ruby社群湧現出來那麼多新的Ruby解析器實現的原因。從很大程度上來說，這制約了Ruby的發展速度。相對而言，Python解析器更成熟，也比較穩定。
在第三方類庫的數量上來說，Ruby並不比Python少，但是高效能高質量久經考驗的第三方類庫Python要明顯比Ruby多，事實上很多Ruby的第三方類庫都不太成熟，因此這也很大程度上制約了Ruby的發展。
3、Python的應用領域非常廣泛，而Ruby目前主要侷限在在Web領域
Python應用的領域非常廣泛，除了web開發以外，還被廣泛用在伺服器後端的高效能伺服器實現，伺服器後端的各種密集運算，全文檢索，各種文字處理，系統管理等等，另外桌面應用領域wxPython也是一個很成熟的跨平臺GUI框架。對於某些特殊的應用，比方說呼叫作業系統核心API，Python也可以完成的很好，比方說大量小檔案的實時同步方案，就是用Python直接呼叫linuxKernel的inotify特性來實現的。所以可以說Python是軟體開發領域的瑞士軍刀，什麼事情都可以做。
正是由於Ruby解析器和Ruby類庫的制約，Ruby的應用主要侷限在Web開發領域，目前Ruby的應用還無法延伸到web開發領域以外的很多地方。據說豆瓣早期就考慮過Ruby on Rails，但是因為Ruby不能做其他事情，而Python可以大包大攬，最後放棄Ruby選擇了Python。
4、在Web領域Ruby是王者
隨著網際網路應用更進一步滲透到軟體開發的各個領域，其實web開發佔整個軟體行業開發的比重也是越來越大。儘管Ruby在其他領域很受制約，但是在Web開發領域就是絕對的王者了。Rails框架的領先程度已經遠遠甩開了任何一個潛在的競爭對手十萬八千里。因此儘管Ruby可能有這樣那樣的問題，但是說到Web開發，Rails幾乎就是無可爭議的唯一選擇。
而Python儘管十分全面，卻偏偏在web開發領域不彰，web框架雖然眾多，卻沒有一個真正可以挑大樑，Django雖然在Python社群比較流行，但很多方面也有缺陷。現在的網際網路應用往往都是多種語言混合程式設計，Ruby在Web以外的缺陷也可以用其他語言來彌補。
5、Python的包管理不如Ruby
儘管Python的第三方類庫更高質量更成熟，但是Python社群缺乏Ruby Gem這樣一個良好的包管理軟體和包釋出的網站。因此應用的構建顯得不如Ruby那麼方便，那麼人性化。特別是在類庫的版本升級上，就會遇到很多麻煩，不如Ruby Gem那麼簡單。
不過總的來說，Python和Ruby還是相似度極高的兩種程式語言，即使兩種程式語言都學習一下也不會浪費太多時間。如果我個人選擇的話，會首選用Rails來構建web應用，再根據情況選擇Python或者Java處理一些伺服器後端的運算。總之，未來還是一個混合程式設計的時代，我們需要多瞭解一些程式設計工具，然後根據需要看菜吃飯才行。
三、《ruby和python的比較》之更正
1、文件、開源專案、庫支援，這些東西Ruby不要跟Python比，不是幾個數量級的問題，何必貌似並列的排在一起。
2、Python確實沒有把正規表示式模組內建到核心裡面，但是卻有re這個標準庫的支援，當時的目的也是為了儘可能的把核心做到最小。我不太明白，使用標準庫和內建有什麼區別，甚至可以作為優點？且使用Python中的正規表示式也不過是多個import
re和呼叫時的幾個字母而已，省下的無數個end足以抵銷這個問題了。
3、至於嵌入HTML功能，Python裡有C/Python雙實現的Cheetah模板可用，據說託Zope的福，美國海軍和法國政府在用，不知Ruby這個功能的成熟度如何？
4、mod_ruby模組的出現時間很短，如果作者沒有聽過mod_python那就實在孤陋寡聞了。我在一年前翻譯mod_python3.2.8文件的時候，mod_python已經很成熟了，以至於幾乎所有的Python
WEB框架都支援構建在其上來提高效率。但是，似乎mod_ruby的更新，每年也只有幾次。mod_python更有gnu.org這樣的重量級應用，不知mod_ruby有沒有？
5、另外，提到unix工具。Red hat
Linux的安裝程式一直是用Python寫的，如果你恰巧用ubuntu，那麼，那個提示你更新系統的程式，也是用Python寫的。
6、racc和doctools，請原諒我的孤陋寡聞，我google了一下居然除了你的這篇文章還沒找到幾篇關於racc的中文內容，輾轉之後才查到是一種類似yacc的工具。從google的角度講，racc的可用性我就不多說了。我不太明白一個yacc工具在日常程式設計當中有多大的實用性，但是既然作者提到了我就順便找了個我只聽說過名字，根本沒用過的Spark。google的結果是”racc
ruby”:”python
spark”=159,000:659,000。至於doctools，我更是無話可說，在google上只有15,800條記錄，我到現在都看不出這個東西是幹什麼用的。所以找了個估計是類似的東西對比了一下，docutils，google的記錄是25,400條。
7、“比Python庫更完整的物件導向語法”。試問物件導向的目的是什麼？再者，ruby能否像Python一樣，絕大多數標準庫根本不需要查文件，只要猜測一下大體上的名字，然後dir()一下，再help()一下就可以直接上手，用到第二次的時候，因為模組內東西實在太少，記憶太方便，就可以直接寫出來的地步？另外，物件導向既不是什麼銀彈，也不是最先進的軟體工程思想。
8、”ruby的整個庫都是類繼承結構的”，個人認為是Java的糟粕，反倒是當成寶學過來了。或許這也是ruby來拯救Java程式設計師的一項優勢吧。
9、”基本資料型別和運算子都是可以過載的”，這個不是太清楚，不知Python中過載add之類的算不算。
10、”ruby主要的功能都是透過物件的方法呼叫來實現的，而不是函式”，Python中所有的東西都是物件，但並不都是類，不知這句還有什麼意義。另外，推薦你不要太追求什麼徹底，還是實用這個詞比較有吸引力。
11、Python沒有嚴格要求單繼承是給程式設計師以靈活性。另外，關於介面，Python中只要定義了同名的函式就算是具有了相同的介面，玄學上升到了這個高度，我也有些迷糊了。至於介面，不要那麼自信，ruby的所謂介面也不過是個mix-in。這個東西Python的幾個大專案中也有過實現，只是因為對Python意義不明顯，所以才沒有更多的使用。
12、關於lisp的函數語言程式設計，Python中有很多內建支援，如map、zip、filter等等，當然還有lambda。不要說支援，我們談實用。Pythoner中尚且有些人認為函數語言程式設計影響了程式碼可讀性而儘量避免呢。所以，你認為支援什麼東西之前，先想好這樣東西算不算是個好東西。
13、”最大的不足正是因為ruby的強大所引起的”。這句真噁心，不予評論。
14、呵呵，ruby居然沒有國際化支援，真是個笑話，不知道當初那個小日本怎麼想的？難道他英語過了四級？
15、至於jython，現在也有了jruby，可能是作者的原文比較早的緣故吧。Python也有很多種實現，像是jython,ironpython, pypy,pyrex等等。Python的優秀其實並不一定要透過用其他語言來實現才能體現出來。當然更不要說寄希望於要Java來解救水深火熱中的ruby了。
另外麼，有些ruby的缺點不要回避：
16、ruby沒有本地化執行緒，而是用的偽執行緒，根本無法利用多核CPU的優勢。CPython使用了本地化執行緒，但是因為使用了GIL所以也是無法利用多核CPU優勢的。但是Stackless的出現完全可以解決這個問題，並且stackless更是將Python提高到了平行計算的高度，這個高度的競爭對手可以是Erlang，ruby自然不必窺探。其中的超輕量執行緒技術可以確保一臺很爛的機器上跑幾十萬的執行緒還很輕鬆。基於Twisted的非同步程式設計方式也提供了一種選擇。
17、剛剛開始學Python的時候，就聽說過一句“Python是主流動態語言中最慢的”，後來才知道，說那句話的人根本沒把ruby放在眼裡。如果把ruby也算進主流動態語言裡，那麼就會出現一個比Python還慢了一個多數量級的語言了。
18、ruby流行麼？是不是要走向PHP？php是個好東西，但是問題在於他只能作WEB程式設計，限制了PHP的應用範圍，稍微需要系統一點的東西就要藉助於C。而現在的ruby似乎也就是走著這條路。直到有一天，有人爆料”ruby是可以做客戶端程式設計的”，贏得大家一片好奇。況且現在的ROR能否取代什麼還是個未知數。從Java
WEB開發中解救出來的人們也並不都是走向了ruby。
四、評《選Ruby還是選Python？》
Python和Ruby的設計哲學確實有很大的差異，這個問題，我就不評論哪個更好了，各有所愛吧。至於效率，Ruby永遠不要考慮跟Python相比。Ruby是偽執行緒，而且根本沒有利用多核CPU的可能，直接pass。而Python使用native
thread，僅僅由於部分模組不是threadsafe的而加入了GIL來限制應用多核CPU，而在我最近的測試中，在使用Twisted的非同步執行緒之後，已經可以很好的利用多核CPU的計算能力了。執行效率上也不是一個數量級，自己試試就知道。
拿Java對比Python，可見作者創造力之強悍，哈哈。開源專案是很符合達爾文的自然選擇的，難道Ruby的開源專案少倒成了優點了？另外，在Python中我也沒見除了WEB
framework之外有什麼專案有太多的重複。舉個例子，pypcap就已經基本淘汰了pcapy了。
談到資源，Ruby還有很長的路要走，所以提到雙方都很強的時候，麻煩不要太並列化了。至於Java社群的人傾向於學Ruby，我個人認為只是被Java折磨慣了的開發人員目光太狹隘所致。語言是工具，物件導向也是工具，純粹的物件導向並不見得高明到哪裡去，Python也有函數語言程式設計的支援，作者怎麼沒有提到。另外，Python的很多做法是以開發效率為第一目標的而不拘泥於各類形式，甚至為很多智力有限的人所廣泛詬病的C++中的多繼承，Python也可以支援。問題不在於支援了什麼讓你不喜歡的東西，而是讓儘可能多的人用上他們喜歡的東西。另外，一直被Ruby開發者所認為的Python不夠OO的一個例子就是取一個序列的長度，Python使用len(x)的方法。這個問題，如果Ruby開發者認為x.length就可以算是OO的話，那麼Python也大可以直接使用x.len()來獲取長度。從用方法來封裝屬性的Java角度講，誰更OO一些呢，哈哈。
Ruby是一個日本人的作品，呵呵，這個就不多說了，不喜歡日本的國人有很多，在此我僅在技術層面就可以把Ruby貶低下去，無須用非技術的東西了。
關於Ruby on rails，Ruby社群確實把幾乎所有的精力都集中於此。但是這隻能表現出Ruby的幼稚，事實已經證明了，ROR的很多模仿者已經推出無數的高階功能，遠遠超過了ROR，沒有取代ROR只是出於先入為主的觀念。如果現在的Ruby，突然失去了ROR又會是什麼樣子。至於作者提到的zend，居然用來跟ROR相比，有如以卵擊石，我學過Python的2種WEB框架，平時也比較關注Python和Ruby的各種東西，但是zend這個東西，我是沒有聽說過的，不知是不是作者的作品，哈哈。如果一定要在WEB框架上有個較量的話，你可以用django,Quixote,mod_python之類的來比較一下。django，一個典型的ROR模仿品，還在成長，但是已經有很多優於ROR的功能了，而效能上遠優於ROR自不必說。應用Quixote的douban.com是所有使用Python和Ruby網站中流量最大的，而且在相同硬體配置的情況下比ROR實現速度快了一倍還多，要知道去除WEB伺服器等等的各種平等損耗之後，這可是要快上一個數量級的東西。至於mod_python，據說www.gnu.org用的就是這個。如果Ruby還想開源的話，那麼就永遠活在Python的陰影裡面吧。
至於上手的速度，各個人有不同的情況，不作評論。至於靈活性所帶來的東西，仁者見仁，就不要評論了。作者談到Python的入門不容易，真不知Ruby有個何等容易。我初學Python時，第11天就用Python寫了一個詞法解析器，至今仍然在我部落格上可查。所以，入門難度這個東西，每個人還是自己去試試為好，不必聽別人怎麼說。
提到ROR生成的目錄有很多東西，要很久才可以都瞭解，這確實是IDE的綜合症。在Python下，比較典型的例子是TurboGears，如果你希望瞭解整個應用程式的執行方式，你可以從核心cherrypy開始學習，然後開始使用TurboGears就沒有什麼可不瞭解的東西了。在這個角度上，ROR沒有選擇。再者，現在ROR可用的一種連線WEB伺服器的方式scgi，當年也是Python的作品，又是一個在Python的陰影下活著的小東西。
未來的發展麼，孤注一擲的Ruby還很難說，但既然是孤注一擲，風險還是蠻大的。而Python麼，我也以為真的會平穩的發展，但是後來Micro$oft的加入，讓我們都難以預料Python的未來到底有多大了。我們再回頭談談作者一直討厭的Python的多樣性，在我看來Ruby可以超越Python的東西屈指可數，而Python超過Ruby的東西，自然是Ruby難以逾越的鴻溝。所以從程式語言的多樣性考慮，也就不建議大家學Ruby了吧，少了一種選擇，聚集一些人氣總是好的。