在大型項目上,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>

要回復問題請先登錄註冊