在大型項目上，Python 是個爛語言嗎？
最近在pongba的google groups看到一個較火的討論：python是個爛語言https://groups.google.com/forum/?fromgroups=#!topic/pongba/X7OpNT4BZLQ。
比較客觀的關於python的優點和缺點是什麼呢。
這些看法：
「
可以很快的寫點簡單的東西出來。但python代碼一多開發效率就指數下降
一般的小項目， 代碼超過 1000 行寫 python 就已經是虐心了
代碼超過 10w 以後你就別想用 python 開發了。
python 缺乏真正的開發工具
語法錯誤都在運行時
」
還算公正嗎？--------------------------------------------
我想問的不是哪種語言好哪種不好。而只是關於python自身的優勢、劣勢。
太多硬傷和臆想，懶得批。只說「代碼超過 10w 以後你就別想用 python 開發了」這一句，2012年4月豆瓣主站項目代碼行數就近50萬行了，可我們還在用 python 開發。
不點評 Go，光說他噴 Python 的部分好了。
用 Boost 去做實際開發？沒被編譯器坑過的人是幸福的。
能用 std:: 的地方用 C Style 的輪子？沒被 std::string 效率問題坑過的人是幸福的。
Python 超過 1k 行就是災難？這些對語法正確性全靠（即時）編譯提示錯誤的人寫什麼 1k 行的代碼啊。最好的軟體工程工具都是語言無關的：Unit testing，design by contract。除了很少的特殊語言（Eiffel，AspectJ），基本都是靠庫和程序員手工實踐的。
一個公司能像 Google 一樣招人，他們用什麼語言都可以。如果不能，趁早放棄 C++，你修不盈新手挖的坑，扶不正老人搭的廟。
至於性能問題……沒有到 Google 這個尺度上，性能問題從不需要從全局方面去解決。找到熱點，用合適的工具局部替換，這才是工程上有可行性的方案。何況 Python 是出名的易於用 C 擴展的語言。
Perl, Python, Go，甚至算上 Java……這些語言的問題都是，他們從來不是不可被替換的。他們都在解決非常具體的問題，因此當有一個新的語言在當前語言框架之外解決了一個新的具體問題時候，舊語言就會損失一批用戶。Go 的 coroutine，Python 的語法清晰和簡單，Perl 的字元串處理效率和隨時運行，Java 的庫和 GC，從左往右就是這麼一個後浪推前浪的關係而已。在合適的地方用合適的工具解決正確的問題是每個程序員和架構師應該會去做的事情。
在一門語言里找槽點很容易，不找槽點開口就噴更容易。亂噴一時爽，過一兩年回頭看看自己說過的話，還沒被自己的幼稚笑死的人，估計也沒有進步的餘地了。
安息吧。
－－ 以上是 2013 年 5 月的原始答案－－
答主在回答之後一年半不小心加入 Google 並參與了多個大型 Python 項目被灌屎三噸之後聲明：是的 Python 就是個爛語言（但題目中的幾位噴子仍然是sb）。
把另一個回答轉一部分過來：你如何看待王垠的《什麼是「腳本語言」》？
根據這些年用過的編程語言，我總結出一條判斷語言是否值得學習、使用的指導原則：
易用、靈活、高效，一門編程語言最多只能同時擁有兩項。
易用 包括：
1. 簡潔，易讀、易理解、易寫；
2. 一致性好，易協作，易接手維護；
3. 基本構造緊湊；
4. 儘可能自包含，擁有豐富的類庫和軟體包支持；
5. 可移植，對執行環境的假定越少越好；
6. 從編寫到執行，整個過程涉及的工具越少越好，程序易部署；
7. 手冊可隨手取用。
靈活 包括：
1. 伸縮性好，刪除依賴性與加入依賴性一樣簡單；
2. 允許在不同層次上抽象（含DSL）；
3. 支持多種編程範式；
4. 儘可能適用於更多的領域；
5. 可定製語言子集（方言）；
6. 可編譯執行，也可解釋執行。
高效 包括：
1. 編寫快，越快越好（考慮工具支持與純手寫）；
2. 編譯快，越快越好；
3. 除錯快，越快越好；
4. 執行快，越快越好。
還有一些特性沒有羅列出來。
仔細考慮一下，上述各特性不乏相互對立的，如何取得平衡，完全視應用環境而定。
這些特性考量將與設計哲學相互影響，最終決定一門編程語言的編寫風格與使用方式。
但終究，一門編程語言被設計出來的主要目的，是在成本最小化的基礎上，儘可能好地解決某些問題。
另外，不從架構角度考慮開發與運維、用戶操作的關係，做出來的東西必然到外都是坑，且很難持續。
不要隨便看不起一門編程語言，它被發明出來必然有其用處。在恰當的時機用適當的語言解決正確的問題比什麼都重要。
我寫過幾年Python，也寫過幾年CPP，寫過幾年CS，Python做大項目沒什麼問題，不會比其它主流語言更差，項目的可控規模多大，主要還是取決於人，不是語言——語言當然有差別，但是沒有宣傳的那麼大。至於開發工具的問題，高水平的開發人員根本不會依賴開發工具。而且，Python本身不是那種非常依賴代碼補全等功能的技術，我習慣的組合是emacs+ipython+python-mode，用doctesting做TDD，效率很高。最近一段用sublime text比較多，也沒覺得離開習慣的環境就做不下去。
至於錯誤在運行時，這就看自動化測試的水平了。Python項目出現的bug不會比CPP或Java更高。
如果用不好，什麼都是爛語言。這是個相當廉價的態度。
==========
看了一下鏈接里的文章，覺得挺可樂，那位老兄根本不知道Python比Java還要早一年發布吧……（準確的說，1994年是python發布了1.0版，而第一次publish代碼是在1991年的0.9.0版）
可以看看robert love 在quora的回答
Robert Love"s answer to Google Engineering: Why does Google prefer the Java stack for its products instead of Python?如果去編寫一個很精密的東西，沒有一個嚴謹的類型系統是很難想像的。
我們的SQL優化器，核心代碼大概只有1w行左右，全部用C++和Java編寫。其涉及到的各種精巧演算法，如果用Python維護起來是很痛苦的。
附上一篇介紹PostgreSQL optimizer論文（http://db.cs.berkeley.edu/papers/UCB-MS-zfong.pdf）中的一段話：Query optimization requires a great deal of element manipulation. The optimizer must separate,
modify, and regroup elements within a query』s target list and qualification to create new components for
individual nodes in the plan tree. A programming language like LISP is well-suited for this type of processing
because the language contains functions and data structures specifically designed for object manipulation
tasks. Consequently, for ease of implementation, we chose to write the POSTGRES query
optimizer in LISP.
可見語言的選擇多麼重要
隨著傳統靜態語言對自動類型推導和函數式寫法的支持，我的確認為動態語言是要被淘汰的。
當然我在扯淡里王垠對語言有很多思考，是值得參考的。
包括很多特定目的的語言也逐步不再需要，比如awk，ant。比如現在的build工具一般都會是全功能的通用語言，scala的，rust的，具體我已經忘了，但隨著比如java，scala這些對lambda的支持，通用語言配合lib已經可以達到聲明式語言，動態語言，函數式語言的簡潔了。
我們需要靜態類型系統來幫助我們，因為我們大腦能力有限，我們是謙卑的程序員。Guido從G家離開後不久G家唯一的大型Python內部項目就推倒重寫了。回答完畢。
更新：借著Type Annotate的東風，Google已經下大力氣開發 google/pytype 讓現有代碼的可維護性增加很多。如果當年有pytype的話，那個大型Python內部項目可能就不重寫而是重構了。
我記得一句話，寫出來的代碼目的是給別人看的，順便可以在機器上執行。
好的代碼是可讀性強的，好的語言便是為了方便寫出可讀性強的代碼。
編程語言本身並沒有問題，有問題都是程序員自己的問題，Openstack有多少行代碼了，也發展的好好的。
當然了，對於懶的程序員，可能還是靜態語言寫起來輕鬆一點。沒有用Python寫過一行生產代碼，現在用Python寫快排還是二把刀的水平。
本來我根本不適合回答這個問題的。不過那群組裡的討論，涉及到了很多語言的歷史。我覺得可以從其他語言的角度來講講。
早期的語言，沒有那麼強大的編譯器，不足以做出那麼多的靜態檢查，所以從彙編到高級語言這一步，有大量的黑客工程師下了苦功來製造工具鏈。他們針對高級語言的種種遐想，實際上是他們受盡了之前的語言的苦楚的產物。
肯湯普森最早趁老婆回娘家的時候寫Unix原型的時候用的是彙編，對他來說當然綽綽有餘，但是彙編的抽象能力不足，於是他用發明的B語言又重寫了一遍。在這一步，B語言勝過彙編的就是它的優美。
但是B語言是動態語言，性能很差，於是里奇加入以後，在它的基礎上再發明了C語言，性能得到了很大的提升。在這一步，又是對性能考量起了很大的作用。
後來本賈尼因為劍橋念書的時候用動態語言BCPL毛骨悚然的經驗，在強類型弱檢查的C語言基礎上發明了C++。他似乎認為足夠強的語法檢查就足以應付軟體工程的複雜度。事實證明他錯了，在大型項目上C++是個爛語言的呼聲比Python不知道早了多少年。
後來有了Java。它並不是C++加上些語法糖的產物，這個我就不說了。Java能勝過C++而大行其道，就是因為它語法足夠優美。事實就是，如果我們不寫戰鬥機的火控系統，不寫操作系統，我們為什麼要那麼在乎性能？
Java火了以後，之前的Python和之後的Ruby都漸次火了起來，Web時代到來，PHP也火了起來，後來JavaScript也火了起來。這些語言都不那麼看重性能，似乎現在就是一個語法優美的時代了。因為現在程序員的時間已經比機器的時間要貴重了。
那麼我們來探討幾個問題：
1 性能有那麼重要嗎？
現在好像除了超大型互聯網公司需要靜態語言來省電以外，沒有聽說過多少因為語言速度慢而出現的軟體問題。何況現在慢的程序，以後未必就慢了。可是程序員的速度，可是一直很難提起來。沒有銀彈啊。
2 程序規模變大以後，真的那麼需要編譯期的靜態檢查來排錯嗎？
無論多麼嚴格的檢查都無法阻止程序員寫出垃圾來。C的檢查比C++弱，但是它在TIOBE上排得比C++要靠前。里奇相信程序員能夠做好自己的事情所以沒有做出過多的假定，C++看起來嚴格遵守了很多編程範式，其實過於複雜，直到今天，C++的編譯器也不能明確地解決它最複雜的內存泄露問題，這個檢查有等於沒有。
沒有靜態編譯而擴展成大型工程，請看PHP。請看RoR。更不用說保羅格蘭漢姆以前用Lisp曾經開過一個作坊似的公司做出了世界第一流的大型軟體。這就是程序良好的風格比什麼都重要的一個好例子。動態語言看起來拋棄了靜態的類型檢查，但是得到了靈活的類型機制，有得有失，在現在看來，是一個很好的趨勢。用過動態語言再回去看某些靜態類型語言，看多了眼睛流血，寫多了手流血。
3 語言一定要依賴於開發工具嗎？
我不知道真正的語言開發工具指的是什麼。事實上除了PHP，現在各大腳本語言的開發工具都只是半斤八兩，Python還是其中發展最快的了。我覺得好的語言並不應該依賴於技術體系，現在MIT里還是朝聖一樣使用Lisp和emacs。emacs很好排錯嗎？emacs很方便部署嗎？emacs很方便做性能基準測試嗎？這會影響到Lisp這門語言爛不爛嗎？
C++倒是什麼工具都有，這讓它變好了嗎？
工具其實都在其次，一切慢慢都會好起來的。
說兩個就近的題外話：
1 好奇號宇宙飛船的兩百五十萬行的代碼，大部分都是用Python生成C的方式寫出來的。不知道這算不算一個超過十萬行的項目？
2 MIT的計算機第一門課一直在灌輸兩個道理：
計算機程序是寫給人看的，恰好能夠運行。
軟體設計其實就是對於抽象複雜度的控制。
這兩個觀念完全與性能、靜態檢查和開發工具無關。這門課許多年一直用scheme教，前兩年突然換Python了。
無論什麼語言，1000行代碼都hold不住的人，智商堪憂，別來製造代碼垃圾了。
我一個戰五渣寫的Python小項目，兩個代碼文件加起來就超過1000行了。大型項目這個問題太籠統了。
就個人看法，這個問題分成兩個方面。
如果系統規模很大，內部關係很複雜，但是又不能藉助資料庫，一定要自己硬編碼實現業務邏輯，那請遠離一切動態類型的腳本語言，靜態類型的語言中類型檢查在這種情況下非常必要；
如果可以依賴資料庫（存儲過程，觸發器，約束等），那用什麼語言都只是個控制和表現層的東西，無所謂。
摘自《UNIX 編程藝術》的一段話送給你：
對軟體錯誤模式進行大量研究得出一個最一致結論是：程序員每百行代碼出錯率和所使用的編程語言在很大程度上無關。更高級的語言可以用更少的行數完成更多的任務，也意味著更少的 Bug。
NASA用FORTRAN把人送上了月球；KR用彙編和B語言寫出了UNIX……
有爭論哪種語言好的功夫還不如去改改程序里的Bug，優化下執行效率，要不就美化下代碼多寫兩行注釋，省得總有人說你正在用的語言是個爛語言……
有一次在Quora上有人問演算法導論的作者，你們寫代碼最喜歡用哪種語言啊，人家說「我首選python」。
我發現python已經漸漸地成為了機器學習，自然語言處理，機器視覺，數據分析方面研究的首選語言了，再往後，python會不會在更大程度上侵蝕matlab和mathematica的陣營，成為通用數學建模的首選語言，從而在更加廣大的天地中發揮它的簡單與優雅之天性，也未可知哦。
你能想像某一天，某研究團隊率先用python寫出了對全人類幸福和進步有意義的代碼（數學、物理、生物方面的模型）。至少我相信python的優雅簡潔是讓它最有希望做到這一點的，因為十幾年前Perl 對人類基因組計劃已經做了類似的事情；似乎在好奇號火星車上python也已經做到了（推動科學的前進）。因為比起人類的這些成就，那些成天討論C++，Java，PHP，python，ruby孰優孰劣的人，成天討論庫、類型的強弱，能做多少個connect，性能差多少個百分比，縮進好不好看，實在渺小無意義啊。
How Perl saved human genome
10w行就叫大項目？
題主可知道openstack？
大型項目不知道，反正python寫的知乎是讓我崩潰了，從沒遇到這麼頻繁無法服務的網站
應該這麼說，在大型項目上，Python社區相對於Java、C/C++等語言，缺乏足夠的經驗和範例。而Python本身也有一定的缺陷，這一點在大型項目開發時會被放大。
但是大型項目，往往都不是一兩種語言開發而成的。一般來說C/C++、Java是最常用的，如果是B/S架構的項目，那麼JavaScript必不可少。如果腳本寫的非常複雜，可能會用Perl或Python來代替Shell。如果是運行在Windows平台下，又是C/S架構，也可能會加入C#。
另外，不是代碼行數多就叫大型項目，這個項目得要有一定的技術含量。推薦閱讀：
※對 Quant 而言 Python 的需求高嗎，除 C++ 外還有哪些流行的編程語言？
※使用 Python 會降低程序員的編程能力嗎？