“Python 不是數據科學的最佳語言！”

近來，Python 在各大編程語言榜單上持續霸榜，成為增速最快的語言之一。從數據分析到深度學習，從科研到工程項目，幾乎無處不在。但它真的適合所有的數據科學任務嗎？對此，本文作者結合自己二十多年帶實驗室的經歷，深入探討了 Python 在數據科學中的優勢與局限，并對比了 R 的使用體驗，得出這樣一個結論——Python 并不是做數據科學的最佳語言。那么，他為什么這么說？我們一起看看他的最新觀察。

原文鏈接：https://blog.genesmindsmachines.com/p/python-is-not-a-great-language-for

作者 | Claus Wilke 責編 | 蘇宓

出品 | CSDN（ID：CSDNnews）

我已經準備好踩進語言之爭這趟渾水了。但我先說一句最重要的：用你最熟的工具。比如你熟悉 Python？那就用 Python。再補充一句：做哪件事最合適用哪個工具就用哪個工具。如果剛好還是 Python，那也沒問題。

還有就是，如果你本來就天天用某個工具，順手拿它來干點別的活，也完全正常。你一天到晚拿錘子敲釘子，用它開瓶啤酒、撓撓背，也都說得過去。同樣地，你整天寫 Python，用它順帶做做混合線性模型，也沒毛病。

如果你用得順手，那繼續用就行。但如果你越用越覺得別扭、感覺一些事情明明不該這么難，那這篇文章可能就是給你看的。

首先，我提出一個觀點——大家對“Python 是數據科學語言”這件事過度依賴了。它的局限性其實相當明顯。有許多數據科學任務，我寧可用 R 完成，也不愿用 Python。

之所以 Python 在數據科學領域如此普及，我認為更多是歷史偶然，加上一種“各方面都還行”的通用性，而不是它在數據科學上有某種天生優勢。

與此同時，我認為 Python 在深度學習上確實表現不錯。PyTorch 之所以成為行業標準是有理由的。這里我談的數據科學，并不包括深度學習，而是指其他那些工作：數據清洗、探索性分析、可視化、統計建模等等。

正如開頭提到的，如果你本來就有充分理由每天都在用 Python（比如訓練 AI 模型），那么順便用它把剩下的事情一起做完也可以。我自己在教授深度學習課程時就是這么做的。但這并不能抵消我在 Python 世界里做數據分析時常常感到的笨拙與不便。

來自一線的觀察

我先談談自己的親身經歷，不做任何原因分析。我帶領計算生物實驗室已經二十多年了，期間合作過大約三十位能力很強的研究生和博士后。實驗室的規則是：每個人可以自由選擇任何想用的編程語言和工具，我從不干預。

結果往往是，大多數人會選擇 Python。

下面是我經常遇到的情況：一位學生來辦公室向我展示一些結果。我說：“這很好，你能不能把圖換一種方式快速畫一下？”或者“能不能快速算一個我剛想到的量，并畫出來看看？”諸如此類的需求。通常這些都是我知道在 R 里幾分鐘就能搞定的任務，比如把箱線圖改成小提琴圖、把折線圖改成熱力圖、把直方圖換成密度估計、把原始值換成排序值再計算等等。

幾乎毫無例外，使用 Python 的學生總會回答：“這要花點時間，我得回去研究一下，弄好再告訴你。”

我要強調的是：這些學生都非常強。問題并不是他們不懂工具，而是工具本身似乎就比較笨拙，讓我以為是“非常簡單的請求”，卻經常變得一點也不簡單。

無論原因是什么，我都不得不得出一個結論：Python 在數據分析上的某些基礎環節出現了結構性問題。可能是語言本身的問題，也可能是庫生態的問題，或兩者共同作用，但結果是真實存在的，而且我長期都能看到類似情況。

事實上，我再舉一個例子，以避免你認為“這是學生水平問題”。

去年秋天，我和一位資深的數據科學家一起教授生物學的 AI 課程。他所有工作都用 Python，對 NumPy、pandas、matplotlib 都熟得不能再熟。在課上，他負責帶學生做 Python 練習，我負責講理論。這讓我可以觀察到一位 Python 專家如何現場解決各種數據分析問題。

我的反應往往是：“為什么要寫得這么復雜？”許多我認為用 R 幾行就能寫出的東西，在 Python 里卻變得又長又繞。我自己要是不花大量時間重新訓練大腦、適應完全不同的編程思維，就根本寫不出那些代碼。這種陌生感并不是“陌生但優雅”，而是“陌生、怪異、且繁瑣”。

而我很確定原因不在于同事，他非常厲害。真正的問題，似乎就在這些工具的底層設計上。

什么才是適合數據科學的語言？

退一步講，選擇數據科學語言時有一些基本考量。這里說的數據科學，是指剖析和總結數據、尋找模式、擬合模型、繪制可視化——也就是科研人員在日常數據分析中會做的所有工作。這與數據工程或應用開發并不相同。

數據科學高度依賴交互式探索，需要大量快速試驗性的分析。因此，適合數據科學的語言必須支持解釋執行，并能在交互式 Shell 或 Notebook 中使用。性能反而是次要的。當你做一個線性回歸時，你根本不會在意是 50ms 還是 500ms；你關心的是：能不能立刻打開 Shell，寫幾行代碼，幾分鐘內得到結果，而不是新建工程、寫一堆模板代碼、取悅編譯器，還要花比運行更久的時間等待編譯。

既然交互性和低啟動成本是必須，那候選自然落在 Python、R、Matlab、Mathematica 這類腳本或數據科學語言上。也包括 Julia，但說實話我對 Julia 了解不足，不好評價。它可能非常優秀，但我也看到不少深度用戶對它有所保留。本文就不展開。Matlab、Mathematica 之類的商業語言，以及缺乏生態的 Octave 也先放一邊。現實選擇就是 R 和 Python。

繼續之前我想補充一下關于性能的看法。性能通常要以犧牲語言其他特性為代價：程序員額外負擔（如 Rust）、更高的隱蔽 bug 風險（如 C），或兩者皆有。在數據科學里，高 bug 風險不可接受，而程序員便利性遠比極致性能重要。電腦足夠快，而思考會痛。我寧愿少費心力告訴電腦該做什么，多等一會兒。有真正性能瓶頸時，我完全可以在明確需求后把關鍵路徑重寫成 Rust。

把“邏輯”與“搬運工作”分開

不讓分析變得更困難的關鍵，就是把“分析邏輯”與“實現細節”分離。我希望能用概念層面的描述來寫分析代碼：數據要怎么處理、目標是什么；而不想被迫去操心底層細節，比如數據類型、數字索引、循環、手動拆裝數據表等等。

只要我開始管這些事，那多半是在被“繁瑣的機械勞動”拖累。

舉個例子，來看 Palmer 群島的企鵝數據集。里面有三種企鵝分布在三座島上。假設我要計算“島 × 物種”兩個維度下的體重均值和標準差，并排除體重缺失的記錄。

理想的數據科學語言應該能讓我以接近自然語言的方式完成這個任務，用的代碼量與我剛用英語描述的句子詞匯量差不多才算優秀。R 和 Python 都做得到——只是難易度差別很大。

下面是使用 tidyverse 風格的 R 代碼：

  )

再來看等價的 Python 代碼，使用 pandas 完成相同任務：

)

這兩個例子整體上非常相似。以這種規模的分析任務來說，Python 做得還不錯。我個人覺得 R 語言的代碼可讀性略好一些（注意 Python 里有多少引號和括號），但差別不算大。

兩者的流程也一致：取 penguins 數據集、去掉體重缺失的記錄、按“物種 × 島嶼”分組，然后分別計算均值和標準差。

對比一下只用 Python 基礎語法、完全不依賴數據處理庫時的等價版本：

          f"SD: {result['body_weight_sd']:6.2f} g")

這段代碼明顯長得多，里面到處是循環，還得把數據集拆開再重新拼回去。不管你喜歡哪種語言，應該都能看出來：不用管這些瑣碎步驟、直接表達你要做什么的版本，比被一堆雜事拖住的版本好太多了。

簡單來說，我覺得 Python 代碼之所以動不動就變成“苦力活”，是因為無論你多想保持高層抽象、寫得清爽一點，語言本身或者它的庫，總會出來添亂，讓你不得不去處理那些底層細節。

【活動分享】2025 年是 C++ 正式發布以來的 40 周年，也是全球 C++ 及系統軟件技術大會舉辦 20 周年。這一次，C++ 之父 Bjarne Stroustrup 將再次親臨「2025 全球 C++及系統軟件技術大會」現場，與全球頂尖的系統軟件工程師、編譯器專家、AI 基礎設施研究者同臺對話。

本次大會共設立現代 C++ 最佳實踐、架構與設計演化、軟件質量建設、安全與可靠、研發效能、大模型驅動的軟件開發、AI 算力與優化、異構計算、高性能與低時延、并發與并行、系統級軟件、嵌入式系統十二大主題，共同構建了一個全面而立體的知識體系，確保每一位參會者——無論是語言愛好者、系統架構師、性能優化工程師，還是技術管理者——都能在這里找到自己的坐標，收獲深刻的洞見與啟發。詳情參考官網：https://cpp-summit.org/