在大型項目上，Python 是個爛語言嗎

Robert Love, Google Software Engineer and Manager on Web Search.

Upvoted by Kah Seng Tay, I was the Head TA for a class taught in Java at MIT. I used…

Robert has 10+ answers in Google Engineering.

Man, I cannot imagine writing let alone maintaining a large software stack in Python. We use C++, Go, and Java for production software systems, with Python employed for scripting, testing, and tooling.

There are a bunch of reasons for the primacy of C++ and Java:

• Familiarity. Early Googlers were well-versed in C++.
• Performance. Java can be faster than Python; C++ can be faster than Java.
• Tooling. Tools for debugging, profiling, and so on are significantly better for Java than Python. Even C++ is easier to debug and understand in large systems.
• Concurrency. As you can imagine, Google systems are highly parallelized and many are highly threaded. Threading in Python is an unmitigated disaster. The global interpreter lock (GIL) is a giant pain in the ass.
• Lack of need for the prototyping prowess of Python. One commonly-cited strength of Python is that it is easier to rapidly prototype small systems in Python than Java and (to an even greater extent) C++. At Google, however, this benefit isn't all that appealing: We have a lot of powerful frameworks that make prototyping or extending existing systems easy. Folks tend to prototype by gluing a hack into an existing server rather than build an entirely new distributed system.

Don't get me wrong, in the war of Perl versus Python, I come down on the side of Python. But I would never use it to build a production, scalable, mission critical, performant system—particularly one someone else may need to understand some day long in the future.

 

 

太多硬傷和臆想，懶得批。只說「代碼超過 10w 之後你就別想用 python 開發了」這一句，2012年4月豆瓣主站項目代碼行數就近50萬行了，可咱們還在用 python 開發。

我寫過幾年Python，也寫過幾年CPP，寫過幾年CS，Python作大項目沒什麼問題，不會比其它主流語言更差，項目的可控規模多大，主要仍是取決 於人，不是語言——語言固然有差異，可是沒有宣傳的那麼大。至於開發工具的問題，高水平的開發人員根本不會依賴開發工具。並且，Python自己不是那種 很是依賴代碼補全等功能的技術，我習慣的組合是emacs+ipython+python-mode，用doctesting作TDD，效率很高。最近一 段用sublime text比較多，也沒以爲離開習慣的環境就作不下去。
至於錯誤在運行時，這就看自動化測試的水平了。Python項目出現的bug不會比CPP或Java更高。
若是用很差，什麼都是爛語言。這是個至關廉價的態度。

 

用 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，從左往右就是這麼一個後浪推前浪的關係而已。在合適的地方用合適的工具解決正確的問題是每一個程序員和架構師應該會去作的事情。
在一門語言裏找槽點很容易，不找槽點開口就噴更容易。亂噴一時爽，過一兩年回頭看看本身說過的話，還沒被本身的幼稚笑死的人，估計也沒有進步的餘地了。

 

 

王sir、熊天霸、雲儀 等人贊同

沒有用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了。

 

 

今天在InfoQ看到一篇文章」Visual Studio Python工具和Node.js工具介紹「，PTVS的開發人員說」Python原本就已經被不少工業領域所使用。Reddit、Youtube、 Dropbox等流行的網站都普遍地使用了這門語言。有不少財富500強的企業也使用了Python。某個主要金融機構的一個項目有3000名開發人員和 超過1600萬行Python代碼，這是咱們瞭解到的最大的Python項目之一。「

 

一次在Quora上有人問算法導論的做者，大家寫代碼最喜歡用哪一種語言啊，人家說「我首選python」。
我發現python已經漸漸地 成爲了機器學習，天然語言處理，機器視覺，數據分析方面研究的首選語言了，再日後，python會不會在更大程度上侵蝕matlab和 mathematica的陣營，成爲通用數學建模的首選語言，從而在更加廣大的天地中發揮它的簡單與優雅之天性，也未可知哦。
你能想象某 一天，某研究團隊率先用python寫出了對全人類幸福和進步有意義的代碼（數學、物理、生物方面的模型）。至少我相信python的優雅簡潔是讓它最有 但願作到這一點的，由於十幾年前Perl 對人類基因組計劃已經作了相似的事情；彷佛在好奇號火星車上python也已經作到了（推進科學的前進）。由於比起人類的這些成就，那些整天討論 C++，Java，PHP，python，ruby孰優孰劣的人，整天討論庫、類型的強弱，能作多少個connect，性能差多少個百分比，縮進好很差 看，實在眇小無心義啊。
How Perl saved human genome

 

 

把另外一個回答轉一部分過來：你如何看待王垠的《什麼是「腳本語言」》？
根據這些年用過的編程語言，我總結出一條判斷語言是否值得學習、使用的指導原則：
易用、靈活、高效，一門編程語言最多隻能同時擁有兩項。
易用 包括：
1. 簡潔，易讀、易理解、易寫；
2. 一致性好，易協做，易接手維護；
3. 基本構造緊湊；
4. 儘量自包含，擁有豐富的類庫和軟件包支持；
5. 可移植，對執行環境的假定越少越好；
6. 從編寫到執行，整個過程涉及的工具越少越好，程序易部署；
7. 手冊可隨手取用。

靈活 包括：
1. 伸縮性好，刪除依賴性與加入依賴性同樣簡單；
2. 容許在不一樣層次上抽象（含DSL）；
3. 支持多種編程範式；
4. 儘量適用於更多的領域；
5. 可定製語言子集（方言）；
6. 可編譯執行，也可解釋執行。

高效 包括：
1. 編寫快，越快越好（考慮工具支持與純手寫）；
2. 編譯快，越快越好；
3. 除錯快，越快越好；
4. 執行快，越快越好。

還有一些特性沒有羅列出來。
仔細考慮一下，上述各特性不乏相互對立的，如何取得平衡，徹底視應用環境而定。
這些特性考量將與設計哲學相互影響，最終決定一門編程語言的編寫風格與使用方式。
但終究，一門編程語言被設計出來的主要目的，是在成本最小化的基礎上，儘量好地解決某些問題。
另外，不從架構角度考慮開發與運維、用戶操做的關係，作出來的東西必然到外都是坑，且很難持續。
不要隨便看不起一門編程語言，它被髮明出來必然有其用處。
在恰當的時機用適當的語言解決正確的問題比什麼都重要。

 

好奇號火星車的開發語言大部分就是 python 只不過執行時是C
好奇號火星漫遊車使用的是BAE製造的 RAD750處理器，運行的是Wind River Systems開發的嵌入式實時操做系統VxWorks。根據開發者的幻燈片介紹(PDF)，好奇號代碼共250萬行，程序語言是C，可能是用Python 腳本自動生成，NASA JPL共有30名程序員參與開發，測試團隊超過10人，超過一百萬行代碼是手寫。程序包括150個獨立模塊，每一個模塊執行不一樣的功能，高度耦合的模塊組合 成組件。

若是去編寫一個很精密的東西，沒有一個嚴謹的類型系統是很難想象的。
咱們的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.

可見語言的選擇多麼重要

 

 

應該這麼說，在大型項目上，Python社區相對於Java、C/C++等語言，缺少足夠的經驗和範例。而Python自己也有必定的缺陷，這一點在大型項目開發時會被放大。
但 是大型項目，每每都不是一兩種語言開發而成的。通常來講C/C++、Java是最經常使用的，若是是B/S架構的項目，那麼JavaScript必不可少。如 果腳本寫的很是複雜，可能會用Perl或Python來代替Shell。若是是運行在Windows平臺下，又是C/S架構，也可能會加入C#。
另外，不是代碼行數多就叫大型項目，這個項目得要有必定的技術含量。

 

最終能寫上千萬行項目、或者要命的項目（譬如說衛星和戰鬥機，一個下來也要幾百萬行的）的語言，都是那些能作、而且有人投入精力去作其靜態分析工具的語言，譬如C/C++，C#和Java。因此說python確定是沒戲的（這跟他的性能沒有關係）。說實話，10萬行代碼一點都不算多，就算是充滿了各類DSL、奇怪算法和設計模式的www.gaclib.net（恰好10萬行），我至今仍然可以把細節都裝在腦子裏。我以爲python的上限應該取決於那我的本身的水平，不過大約也就在幾十萬行上下了。

 

隨着傳統靜態語言對自動類型推導和函數式寫法的支持，個人確認爲動態語言是要被淘汰的。
固然我在扯淡裏王垠對語言有不少思考，是值得參考的。
包 括不少特定目的的語言也逐步再也不須要，好比awk，ant。好比如今的build工具通常都會是全功能的通用語言，scala的，rust的，具體我已經 忘了，但隨着好比java，scala這些對lambda的支持，通用語言配合lib已經能夠達到聲明式語言，動態語言，函數式語言的簡潔了。
咱們須要靜態類型系統來幫助咱們，由於咱們大腦能力有限，咱們是謙卑的程序員。

 

用python的好處就是這位兄弟還在跟你講python怎麼很差的時候 你的1k行的代碼都快寫完了..
語言之爭歷來都是毫無心義，好的設計架構纔是最重要的

 

代碼行數和大型項目有什麼關係？我認爲python不太適合大型互聯網應用，固然首先說豆瓣是一個特列，他們有太多的牛人，說真的，把這羣牛人彙集起來用什麼語言開發都行，只要他們願意。
緣由有幾點：
1. python沒有多線程，沒法利用多核，也更別提強大的多線程包了。我以前想經過python腳原本測試一個java RPC框架的最大併發能力，卻沒有辦法，由於單個python腳本根本沒法壓榨機器。而java得益於大神DougLea開發concureent包，提 供了各類多線程開發中須要使用各類利器：Executor，Atomic，Lock, BlockingQueue等。
2. python沒有一個強大，高性能的web應用服務器。gunicorn和uwsgi已經算python最好的web應用服務器了，但性能真的差強人意。
3. python缺少一系列診斷工具。jvm提供的jstack,jstat,btrace真是太強大了，而python...提一個基本需求吧：誰知道如何實時dump線上運行的python thread stack？
4. python沒有一款合適的web開源框架。web.py太簡單，基本等於從零開始開發，表單驗證，middleware,csrf啥都沒有，只有一個url mapping。而django的性能太差，又給你一堆沒用的東西。
5. 有人會反駁說python沒有多線程，但有纖程（協程）啊！是的，但python若是要使用gevent，有太多的坑要踩。你除了本身的代碼須要考慮纖程，還要考慮mysql,mongoDB,redis,memcached等客戶端。
6. python大部分開源庫的connection沒有pool，或者是這些conection pool不能很好的和gevent一塊兒工做，這在大型互聯網開發中是很恐怖的。緣由是，不少conection pool是經過threadlocal實現的(參考python memcached的源代碼（https://pypi.python.org/pypi/python-memcached/）)，而纖程的threadlocal實現有點奇葩。
python是一門好語言，但我的以爲python更適合在天然語言處理，機器學習，火星車開發，探月工程等單機系統。不適合須要支撐大流量訪問，業務快速發展，團隊成員都是屌絲沒有豆瓣大神的互聯網應用。

 

雖然在TL組的另外一個帖裏回覆過這位microcai，既然在這裏看到就再說一下吧。
在那個帖裏，他說道：

我給出了詳細的 python 爲啥很爛的解釋
https://avlog.avplayer.org/3597082/python%E6%98%AF%E4%B8%AA%E7%83%82%E8%AF%AD%E8%A8%80.html
我可不是那種簡單的給打個標籤 缺少根據在那裏胡扯 的那種人.
誰要是不一樣意能夠逐條反駁.

但 是說實話，他這段偏偏就是「缺少根據在那裏胡扯」，並且是從開始提到python就扯——好比解釋器比編譯器（他還給說成了彙編）簡單，除了C++那種變 態級別的編譯器，python的解釋器不比其它編譯器簡單多少。另外，python也須要編譯爲pyc，除非說.net/java也是解釋語言，況且就算 是編譯成目標代碼，也有cython這種間接方式，或是pypy這種動態方式。
固然我不會真的逐條反駁這麼浪費時間的，上面這條就足夠說明他的問題了。

回到樓主的問題上：python是否不適合大型項目？
成功的例子參見 @洪強寧 等人的答案。

事 實上項目管理的根本問題是對人的管理。java之因此適合作大項目，很大緣由在於比較容易找到一幫水平差很少的人，而且管理起來也比較容易。python 的優勢是易學，雖然找一大幫人不容易，但培養起來比較快，規劃得當問題也不太大。可是C++就不一樣了，找一幫會C++的人不難，可是水平良莠不齊，如頂樓匿名人士所說「你修不盈新手挖的坑，扶不正老人搭的廟」，就算是找到一幫C++高手，還各有各的習慣和愛好。至少python還有pythonic這條陽關道。

 

不要鬧，看這裏 (⊙o⊙) --> http://en.wikipedia.org/wiki/List_of_Python_software#Commercial_uses
固然，不得不認可，純用Python不是一個好主意。膠水語言就應該起到膠水的做用。創建結構清晰，易於控制的框架。內部結合別的語言實現（不得不說，Python和別的語言結合很棒。。固然，我只知道C的狀況）。
其次，不少時候，項目的問題不是Python形成的。 Disqus的C同志曾在PyCon2011講過一個lecture，應該能對lz有所幫助。
傳送門在此：Watch PyCon 2011: Disqus: Serving 400 million people with Python

 

1，世界上沒有垃圾的語言，只有垃圾的程序員。
2，絕大多數項目的瓶頸根本再也不工具自己，而在於使用工具的人。
3，絕大多數程序員對語言的理解深度與高度根本沒資格攻擊。

不說python,說JAVA,其實JAVA優(平)秀(庸)的緣由,但從語言歷史上來講,我的以爲JCP是個很重要的緣由,JCP從較長遠的眼光,以步履薄冰的方式保證JAVA的兼容性和大一統,避免重蹈C++分裂和碎片的格局,so....python....

 

寫一個☆‘Hello,☆world!’, 用
50年前的☆Fortran,
40年前的☆C,
30年前的☆C++,
20年前的☆Java, 和
10年前的☆Python,
如今☆哪一個
還能夠☆編譯☆運行？」
又詩爲證：
「Python,
膠水語言，
在大項目中，
註定☆打醬油。
醬油☆豆瓣，
豆瓣☆醬油，
一對☆好朋友。」
—— 嚴肅地說，Python 是個有用的東西，然而它的創始人朝秦暮楚，一下子忽悠大夥兒用別用 open, 用 file，一下子又把 file 給廢了。一下子忽悠大夥兒別用 range, 用 xrange, 一下子又把 range 給廢了，把 xrange 也給廢了。如此等等。至於給 print 加劇定向這種先有個樓房又搭個窩棚，而後號召你們去住窩棚的腦抽設計，危害性算小的，我就不說了。

 

 

寫大項目主要是邏輯的管理，和人的管理能力，與語言沒關，有些語言強制加了管理能力，就省了不少管理的規劃。舉個淺顯的例子。
彙編語言是最沒管理能力的，甚至變量就是內存和寄存器
C語言有點管理能力，至少分了全局，局部，函數，函數體內變量隔離
彙編就不說了，C語言對於沒經驗的幾我的來講很難寫大型程序，
可是簡單的規劃一下就能夠寫了
例如，每一個變量都前綴我的的名字，int tom_var; char jerry_var;float xx_var;
而後若是須要共用的，就寫 int public_var;
函數一樣處理，這是個很是好的技巧。。。。。。。
可是這種技巧一直被別有用心的公司諷刺
因而出現了C++;c++ 其實把名字換成了命名空間，而後把一些函數加了class頭，而後引入了面向對象的東西。可是class裏面加了太多的歧義和難於理解。
因而又出現了，java ，強制用包，類

java算是編譯語言走到的極點，算軟件工程的產物，加了太多管理和約束的東西
致使寫代碼又羅嗦，又麻煩。適合大工程，可是效率很低（開發效率）

python出現了，更接近人的語言，高度的邏輯化，用python 基本上比java的邏輯減小了3倍。
大項目本質上是大邏輯的管理，python從理論上說能寫比java大3倍的項目

一個語言只要具有了，函數，類，模塊，包就是一個具備良好管理能力的語言。
若是你以爲什麼語言寫不了大程序，仔細思考一下你的邏輯管理能力
或許 c是個好的鍛鍊方式，若是沒有類，每一個文件變量會衝突，你該如何解決呢！
分割線----------------------------------------分割線
吐槽。。。。加班中。。。寫代碼。。。。。隨便看到，忍不住吐槽。。。。。，繼續寫。。。

 

 

首先：全部語言之爭都是意氣之爭。「xx是個爛語言」基本等價於「我就是個譁衆取寵的oo」。工程師這個羣體難以獲得與貢獻匹配的社會尊重，緣由同此，nerd多有中二病。
結論：原連接po主毛病多，別理他。

下面的內容和原帖關聯度並不高，由於看了一些技術經驗很少的回答，一股強烈的學生氣（最近看到很多貌似在校生臆想的回答被推薦呀@_@），因此從商業項目的親歷角度說一點實際狀況。

關於靜態檢查，梁前輩說的很好了，這的確不是關鍵。
關鍵在哪裏？在語言的使用者，工程師。
python寫小程序很是棒 -> py工程師中寫小項目的比例較高 -> 用py寫大型項目的案例中會出現對大型項目的不適應。
——是人。不是語言。
大型項目常見更高比例的性能挑戰 -> C程序性能好 -> 用C語言的工程師大型項目豐富 -> 統計規律發現用C程序寫的大型項目成功率高。
——因果倒置。統計學的常見誤區。參考這個案例：統計發現增長烤箱能夠下降青少年犯罪率。

另外一個緣由有些很差聽，關於性能部分，商業（大型、高成本）軟件的狀況一般是這樣的：
0.01%的性能不足風險，可能成爲將來項目失敗時被放大到99%的決策者能力緣由；
因此一般關於平臺、語言決策，有性能不足的風險時出於自我安全的緣由，會優選高性能語言。
誠如梁前輩所言，真正有性能須要的項目很少，可是哪一個項目又沒有那麼一丁點性能風險呢？
由於「py性能不足」緣由而選擇不使用py的項目，90%是用py作毫無性能問題的。例如web網站，用什麼寫不行啊？哪一個正常語言會「寫不出來」web網站麼？

最後，大型項目的決策者本人的技術背景和年齡，也決定了一些項目的選型導向。

最後，舉幾個專業領域你們都看得出的case說明「大型項目」這個概念自己有不少方面的複雜度和挑戰，舉那麼一兩個網站的例子並不具備廣泛性：
1 google把C++代碼全都換成py，會掛。
2 taobao把java所有換成py，不會掛。
3 Cray把C/C++換成py，會掛。
以上案例絕對不是由於：
「py超過10w行開發效率相對於其餘語言降低」
——這個觀點已經被各位前輩批臭了。

匿名，由於完全煩透了在技術討論的時候，不看內容，而只關心「你作過什麼項目，憑什麼這麼說」這種對人不對事的中二思惟，尤爲是語言之爭的時候。——我沒有提到什麼超過一千的回答吧？

 

我的以爲，一切腳本語言都不適合大型項目，這是顯然的。腳本嘛，就像膠水同樣，主要用途是用來鏈接複雜組件的。這就是它的做用。

 

不少人都在討論語言難易,私覺得無論作什麼,以爲難就是沒學好.本身不行還找這個那個的理由.就像身無分文的乞丐成天奢望着能有份不用幹活有有錢賺的工 做. 吾認識一隻浸淫C/C艹 20+年的技術總監, 那水平就是隻有想不到的,沒有作不到的. 在他看來寫程序是整個項目中很是簡單的一個環節, 跟說話似的.

 

我雖然是Python初學者，但也好歹是專業人士，看完那個討論，發表一下意見。
Python縱然不少問題，但它看起來比較「美」，就好象爲毛大 家忽然喜歡起Mac，討厭Windows同樣。iphone就那麼好用麼，快捷麼，固然不是。Nokia當時搞了好多對比，發短信，搜索啊，說 iphone並不那麼智能。iphone發開比Anroid快捷麼，固然也不會。但就是好像"美"一點。看起來好就是好。
語法糖沒什麼很差，不要瞧不起，我就喜歡甜的。
但Python沒有編譯時檢查，確實讓C語言程序員崩潰，這點我不喜歡。我喜歡有微甜的，有庫的，有框架的，能編譯的，工程化的，輕巧簡單的。
Go貌似不錯，符合個人要求。
固然沒有哪一個語言是萬能的，個人理想配置就是Go, Python+PyPy, C/C++ with lib。

 

python/ruby這些新（創立時間不新，但被程序員接受時，每每在他們學過幾個語言以後）的語言，不只僅支持庫強大，自己的表達能力也比較強悍/精煉。
但規範性好像低了，規模大恐怕不易管理好。
可是一樣的項目規模，python實現的代碼會少不少；
一樣的代碼規模，python能實現的項目規模會大不少。
再大，才須要比較當心

 

我學過C/C++,java,nasm,javascript,sed,awk等等，都實際開發過，雖然經驗其實不多。最後我見到python，我漸漸喜歡python的幾乎每一個特徵，縮進，特殊的else，鴨子理論，列表解析等等！
問題的關鍵是標準：，
有的性能潔癖
有的追求易讀易維護
有的追求優雅地處理問題，大概是python無出其右了。

《編寫可讀性代碼的藝術》

1. 可讀性基本定理：代碼的寫法應當使別人理解它所需的時間最小化。

2. 把條件、循環以及其餘對控制流的改變作得越「天然」越好，使讀者不用停下了重讀你的代碼。
3. ……

 

豆瓣用Python和Django你敢說爛？

 

語言只是個工具，python做爲動態語言，有快速開發的優點，遇到大項目時，架構是項目成敗的關鍵，至於bug量，徹底的團隊的水平相關，與語言無關

 

python太方便了。。 以致於有人產生了他不能適合複雜的錯覺。。。
只看到python簡單的一面，沒觸摸到python精巧的一面。。
固然，它有缺點，還需完善。

 

大型項目這個問題太籠統了。
就我的見解，這個問題分紅兩個方面。
若是系統規模很大，內部關係很複雜，可是又不能借助數據庫，必定要本身硬編碼實現業務邏輯，那請遠離一切動態類型的腳本語言，靜態類型的語言中類型檢查在這種狀況下很是必要；
若是能夠依賴數據庫（存儲過程，觸發器，約束等），那用什麼語言都只是個控制和表現層的東西，無所謂。
若是系統規模很大，可是核心很小，只是外部依靠插件等方式外接提供的功能，那能夠選擇性地使用Python在合適的地方便可。

 

Openstack 算大型項目了吧，它的開發語言是 Python。

 

python不適合作大型項目我以爲主要仍是在動態語言這點上吧，也不是說不適合，而是項目一大就須要足夠的掌控能力，而不像java，找個新手把框架熟悉一下就能夠寫的馬馬虎虎。
固然還一點就是GIL，不過能夠經過其餘方式來規避...。

直接開地圖炮吧。
1 拼寫常常出錯你須要的是unittest和藥，編譯器救不了你，它只會把拼寫錯誤變成邏輯錯誤，並且更難發現
2 你須要的是更好的設計，而不是更多的代碼
3 50w行Python？固然吃力了，這至關於400w行c++呢。

python只是一門語言，一個工具而已，題主難道不知道openstack嗎，這但是千萬行級別的代碼。
利益相關：我的十分喜歡用python開發，那感受不是通常的爽。惋惜被弄到作前端開發，不過前端學的一坨屎。。

 

工業上python作工具鏈挺快挺好用的

 

python是個垃圾的語言，是什麼領域都能作都作很差的語言，在動態語言中最爲複雜，縮進語意是致命的設計錯誤。每種語言都能開發大型程序，但不是能開 發的就適合，dos仍是彙編寫的呢，能說彙編比c更合適嗎？豆瓣用python多用了多少機器和多費了多少人力大家知道嗎？Openstack選擇 python是個歷史錯誤，惋惜rackspace當年的那幾個程序員不會go語言，有人用1000C++代碼和pythpn幾百行對比，自己就是個傻逼 的行爲，幾百行那是由於python把高度封裝的代碼作成了標準庫罷了。最後的最後，縮進語義在實際開發中不會加快開發，相反它很影響開發，由於縮進自己 是屬於編程風格的，但卻夾雜了最重要的程序邏輯，這種設計是低智商的行爲，它使得你實現功能時不只考慮邏輯，還得考慮如何縮進來達到效果，而不是直接放在 ｛｝或者begin end中就完事了。

 

最近在細讀第二遍Python學習手冊，以爲Python的語言特性仍是滿精緻複雜的，不過是否是符合大項目這個問題，我以爲要看具體場景，有的時候可能徹底要用靜態語言，有的時候多是混合動力的，固然最後一種也不是沒可能。

 

python實現的的開源的。。不小的項目蠻多的。。openstack之類的挺牛的～～～感受比較適用於開發週期短，需求變化頻繁的服務中～～ 代碼多了帶來的複雜性，感受全部的語言都有這個問題，不注意總體結構，碼啊碼天然就亂了，介個應該是設計上的問題～～<DP>和<重構>那兩本書，講的就是這個吧,,額，，，再宏觀點還有。。<soa>