# 特拉維斯·奧利芬特：NumPy、SciPy、Anaconda、Python 與科學計算

> NumPy 作者回顧 Python 科學計算生態的誕生，從開源社群維護談到 Anaconda 與資料科學的普及。

- 原標題：#224 – Travis Oliphant: NumPy, SciPy, Anaconda, Python & Scientific Programming
- 期數：第 224 期
- 釋出日期：2021-09-22
- 嘉賓 / 主題：特拉維斯·奧利芬特：科學計算
- 網頁版：https://lex.qiaomu.ai/tw/ep/travis-oliphant/
- 官方頁面：https://lexfridman.com/travis-oliphant/
- 精讀字數：約 17381 字（閱讀約 39 分鐘）

> 本文為 lex.qiaomu.ai 基於原始訪談的 AI 改寫中文精讀，非官方翻譯；引用請註明出處並連結網頁版。

2005 年，楊百翰大學的一位助理教授發現自己處在一個尷尬的位置：他報名開了一門課，學生先選了又退，最後一個人都沒剩下，他手上多出了一整個學期的空白時間。他決定用這段時間做一件事，把當時社群裡分裂成兩派、互不相容的兩套陣列庫，捏成一個所有人都能用的東西。

這件事最後變成了 NumPy。

它今天幾乎是 Python 科學計算的空氣和水。PyTorch 的張量、TensorFlow 的運算、Pandas 的底層，所有用 Python 做過數值運算的人，都踩在它上面。寫第一版的人用了四個月把程式碼敲出來，又用了十四個月才讓它真正能用，而且從來沒有因為這件事拿到過一分錢工資。

這個人叫特拉維斯·奧利芬特（Travis Oliphant）。他後來還寫了 SciPy，創辦了 Anaconda，現在在做一件更冷門也更難的事：試著讓開源軟體本身能持續賺到錢。

## 四年級的 BASIC，和一臺 2K 記憶體的電腦

特拉維斯寫的第一段程式，是四年級課上的一段 BASIC 迴圈，跑在 Atari 800 上，用 GOTO 語句跳來跳去。他對程式設計最早的哲學衝擊也來自那個時候。老師告訴他，不要用 GOTO，那不是好的軟體工程實踐，寫程式碼是有規則的。

他當時的感覺是，哦，原來這個遊戲是有規則的。這種感受一直等到高中選修 Pascal 的 AP 電腦科學課才再次出現。至於 C 語言，他到了大學才第一次正經接觸。

真正讓他對程式設計產生感情，是十歲那年。父親買回一臺 TI Timex Sinclair，本來只是衝著電子表格去的，但他硬是讓父親加裝了 BASIC 擴充套件。那臺機器只有 2K 記憶體，他們額外買了 16K 擴充套件包。儲存靠磁帶機，數字位會變成聲音錄進去。他至今還記得那個聲音。

十二歲時家裡換了 TI 994A，機器有精靈圖、有圖形、有音樂。你能程式設計讓它唱歌。他說就是在那臺機器上，他第一次真正愛上了程式設計。

他從小就喜歡數學，但他對這件事有一套挺清醒的判斷：很多人覺得自己不喜歡數學，其實是因為小時候接觸數學的方式就是死記硬背。乘法口訣背得熟的、短期記憶好的，就被判定為數學好。他自己恰好短期記憶不錯，所以一路都被認為數學好。真正吸引他的，是解題的過程。計算機在他眼裡就是解題能力的延伸。

不過他那時候並不覺得電腦是大腦的延伸。太原始了。從一個念頭到真跑起來，中間隔著一大堆繁瑣勞動。這種門檻今天仍然存在，只是低了一些。也正是這一點，讓他在很多年後遇到 Python 時有一種強烈的感覺：我可以直接用它思考。

## 學一門外語，和學一門程式語言，是一回事

訪談中間有一段很有意思的岔路。萊克斯和特拉維斯聊到了語言和思維方式的關係。特拉維斯母語是英語，第二門流利的語言是西班牙語。他說起那種感覺：有一天你開始在夢裡說西班牙語，然後你開始用它思考。語言不只是工具，它會帶著你往某些思維路徑上走。

萊克斯接上來說他自己俄語流利，俄語背後壓著兩次世界大戰、幾千萬人餓死、承諾被反覆撕毀的歷史。所有那些痛苦和憂鬱都在語言裡，在那些悲喜交加的歌曲裡，在押韻詩歌的傳統裡，在那種從愛到恨反覆擺盪的情緒光譜裡。陀思妥耶夫斯基和托爾斯泰都寫俄語，但陀思妥耶夫斯基其實不太依賴語言的音樂性，所以他翻譯成英文之後仍然能讀，因為故事和哲學密度本身承擔了大部分工作。可詩歌就沒法翻譯了。

特拉維斯順著這個說了一句挺重的話：這個世界上有很多天才，我們永遠接觸不到，只因為科學和技術世界的通用語是英語。很多聰明人永遠冒不出水面，我們就是碰不到他們。這也是他傾向於支援技術民主化、支援那些讓普通人手裡多一件工具的東西，而對集權式結構抱有本能警惕的原因之一。

然後話題自然地切到了 Python。**Python 是特拉維斯第一門真正享受用來的語言**，有意思的是，萊克斯也有同樣的感受。兩個人的體驗出奇一致。

## 1997 年，回頭看自己寫的程式碼還能讀懂

特拉維斯第一次接觸 Python 是 1997 年，那時他在 Mayo Clinic 讀生物醫學工程博士。之前他是電氣工程背景，做過衛星資料，用過 MATLAB、Perl、VMS 上的指令碼，以及 Fortran 周邊的一堆工具。作為一個常年處理資料的人，他對語言的選擇其實很挑剔。

1997 年他把能看到的語言都過了一遍，Yorick 也看過，最後留下來的只有 Python。原因是它有兩個東西，讓他沒有把它過濾掉。

第一是陣列。1995 年，MIT 畢業生吉姆·胡古寧（Jim Hugunin）寫了一個叫 Numeric 的庫，那是 Python 裡第一次有陣列物件，而且是一維以上的、二維三維四維都能表示的陣列。今天的說法叫張量，特拉維斯說他至今還是堅持這種東西應該就叫 ndarray，這場命名之爭他輸了。

第二是複數。很多程式語言的作者會覺得，複數不過是兩個浮點數，使用者自己搭一下就行。特拉維斯不這麼看。對一個做電氣工程、天天和 FFT 打交道的人來說，**複數是把物理世界和數學世界連起來的一種代數結構**。如果語言裡沒有它，每個團隊都要自己重新實現一遍，而且實現方式各不相同，互相之間還合不到一塊去。

真正讓他“愛上”Python 的，是 1998 年發生的一件小事。他回頭看自己 1997 年寫下的程式碼，居然還能看懂。而三年前用 Perl 寫的程式碼，回頭看完全想不起來當時在說什麼。

他沒有變成一個 Python 專家，但他發現自己可以持續用它，而不需要成為專家。**這個差別，是他最終押注 Python 的根本原因。**

Python 用縮排代替花括號，這在當年是個不小的飛躍。特拉維斯承認這個設計有具體麻煩：複製貼上容易出錯，製表符和空格混用會出問題，早期終端處理不好。他說自己幾乎沒有真正被困擾過，反而很喜歡那種乾淨：視野裡沒有多餘字元，看一段程式碼就是在看它本身。

Perl 也追求簡潔，但那種簡潔走向了另一個結果。Perl 社群有一種風氣，誰的程式碼寫得越緊湊、越短、越接近謎語，誰就越厲害。到最後寫 Perl 變成了一件必須成為專家才能讀懂的事。Python 允許你不必成為專家就能幹活。特拉維斯用了一個很貼切的說法：寫 Python 的時候，你可以調動自己每天都在用的那個“英語語言中樞”，不需要額外開一個腦區。

他還提到一個一直好奇的問題：如果一個人母語是日語或中文，用非拉丁字元長大，學程式語言的時候會是什麼體驗？Python 語法裡的那些英文單詞能不能借用他們的母語中樞？他說自己完全沒研究過這件事，不知道答案。但他猜，這大概不容易。

## 被低估的 APL 傳統

聊到陣列程式設計，特拉維斯把話題往回拉了幾十年。

這種“把整個陣列當一個物件來運算”的思路，最早的語言是 APL，誕生在 1960 年代。APL 是一個天才式的設計，也是一個註定小眾的設計。它不只引入了新符號，還引入了全新的鍵盤，因為 QWERTY 鍵盤上打不出那些字形。那個年代鍵盤佈局還沒那麼固化，所以設計者的思路是，那就換一個鍵盤唄。結果這件事顯然沒有成。

APL 社群還有一種文化，跟 Perl 很像：誰會寫更短的程式碼誰厲害。有人以能用 30 個字元寫出“生命遊戲”為榮。APL 裡有表示求和的符號，有“副詞”這種概念，本質上相當於一個運算子上的高階方法。用這套工具，人真的會開始按維度思考世界。

特拉維斯說了一句挺值得琢磨的評價：**如果一個人只受過傳統電腦科學訓練，他很容易覺得，n 維陣列不過是個實現細節。可你真的把它做成語言裡的一等公民之後，人的思維方式是會改變的。**

他順手吐槽了一下微軟。微軟文化上一向不太懂陣列程式設計，所以過去很多年反覆錯過這一塊。當然現在好一些了。

MATLAB 是這條傳統的繼承者。特拉維斯用得很多。他在 MATLAB 之後用 Numeric，再用 SciPy 把缺的東西一點點補上。

## 那個沒人報名的學期，和 NumPy 的誕生

2004 年，特拉維斯在楊百翰大學做助理教授，正卡在終身教職的考核期上。評審委員會給他的反饋是：你做得不錯，論文也在發，但你花在開源上的時間有點多了，能不能少做點那個，多做點論文和經費申請。

與此同時，他目睹了一件讓他很不舒服的事。科學計算社群分成兩派。一派用 Numeric，一派用新的 NumArray。NumArray 是哈勃望遠鏡團隊在 Perry Greenfield 帶領下推動的，他們要用 Python 處理哈勃的影象，但 Numeric 的陣列型別不夠豐富、廣播語義不夠穩定、操作不夠多。所以他們另起爐灶。

然後 ND Image 出來了，一個影象處理庫，裡面有形態學工具，膨脹、腐蝕、開運算、閉運算。作為醫學影像背景的人，特拉維斯知道這些東西有多重要，他自己一直想在 SciPy 里加，但一直沒時間。

問題是 ND Image 只支援 NumArray。

於是整個生態裂成了兩半。**Numeric 和 NumArray 的資料互不共享，一個程序裡可以同時存在一個 G 的 Numeric 資料和一個 G 的 NumArray 資料，兩份記憶體、兩套程式碼、兩個互相做重複勞動的社群。**

在特拉維斯看來，這是技術層面的事情，但後果是社群層面的：一個剛起步的年輕群體正在自我消耗。

恰好那年，他原計劃開的一門數字 MRI 課沒人報，學生先報了名又退了，最後一個人都沒有。他手上多出了一整個學期的空白。

他決定把這個分裂合上。

他花了四個月寫出 NumPy 的第一版，又花了十四個月讓它真正可用。他後來回顧說，那四個月的高強度編碼是全程最艱難的部分。**NumPy 裡最核心的技術貢獻，是一個叫 dtype 的新型別物件。**除此之外，他把廣播（broadcasting）的語義真正定下來，把原來分散在 Numeric 和 NumArray 裡的能力整合到一個陣列物件裡。

最折磨人的部分不在技術，在溝通。

為了讓兩派都願意過來，他必須同時相容 Numeric 和 NumArray 兩套 API。**今天 NumPy 裡很多看起來莫名其妙的複雜度和角落設計，其實是那段歷史的化石，為的是照顧當時兩個社群的使用習慣。**如果從零設計，很多東西不會寫成那樣。特拉維斯說這話的時候沒有抱怨的意思，他是在講一個普遍規律：你看到程式碼裡某個奇怪的設定，先別急著問為什麼是這樣，它很可能是一個歷史產物。

他對這件事的態度被萊克斯稱讚為“有共情、沒有自我”。萊克斯說，你看 JavaScript 框架的分裂，一個框架派生出無數分支，每次都在重複同樣的故事。要真的把一群人聚起來，你得先放下自己的 ego，真正去聽。不只是聽，還得真的理解對方為什麼喜歡某個 API、某種命名風格、某種呼叫方式，然後才能在新的東西里保留那種吸引力。

特拉維斯補充了一點：光聽還不夠，你得有足夠的熱情真的把它做出來。敷衍地點頭說“我聽到了”，然後什麼也不動，這套辦法沒用。他說這對他來講是一種人生哲學，他一生都在追求這種對他人價值的珍視。

## 2006 年，他知道這件事成了

NumPy 釋出之後，一開始還是不確定的。六個月左右，開始有人加入。弗朗塞斯克·阿爾特德（Francesc Alted）、羅伯特·科恩（Robert Kern）、查爾斯·哈里斯（Charles Harris），這些人後來成為 NumPy 的中堅力量。特拉維斯說他們是真正的無名英雄，得到了應該得到的關注遠遠不夠。

他自己當時也需要支援。他說那個階段他其實最需要的是鼓勵，這些人透過貢獻程式碼來給他鼓勵。

真正讓他確定“我們成了”的時刻發生在 2006 年。那一年，約翰·亨特（John Hunter）決定讓 Matplotlib 直接依賴 NumPy。在那之前，Matplotlib 支援 Numeric 和 NumArray 兩種後端，使用者裝哪個它就適配哪個。

亨特把這條路砍掉、只留 NumPy 的那一天，特拉維斯說他心裡清楚：這事穩了。

接下來 2006 到 2009 年，是一段加速期。他形容自己被 NumPy 後來的影響震住了。他知道這個東西會有用，完全沒想到會這麼有用。

原因還是那個詞：語言。**人開始用 NumPy 的方式思考問題了。**一旦陣列作為一個整體物件進入你的思維，你看資料的方式就跟以前不一樣。這開啟了全新的一整套思路。

## SciPy：一個偷偷想做成作業系統的庫

SciPy 其實位元拉維斯寫 NumPy 更早開始。1998、1999 年，他還在讀博，每天用 Python 處理醫學影像，一邊用一邊發現手邊缺東西：沒有常微分方程求解器，沒有數值積分，沒有最佳化器。

他當時的做法很像一個毛頭小子。他在郵件列表上看到有人在討論，要是有一個最佳化庫就好了，要是有個積分庫就好了。他想，反正我自己也要用，那就我來寫吧。

他開始給 Python 寫擴充套件模組，第一個是讀 DICOM 格式的 IO 包。這是他第一次寫 C 擴充套件。他覺得這個組合很有意思：Python 是指令碼語言，你能用它做高層思考；C 是底層語言，你能用它補上 Python 缺的部分。圭多·範羅蘇姆（Guido van Rossum）當年寫過一篇講引用計數的文章，沒有那篇文章，特拉維斯說自己會完全迷失。

然後他遇到了 Netlib。那是 1960、1970、1980 年代積累下來的幾百個 Fortran 程式，全部是已經被人寫好、測試過的數值演算法。Fortran 77 其實是一門挺不錯的語言，Fortran 90 他甚至覺得是自己最喜歡的 Fortran 版本，因為它有複數、有陣列，語義層次夠高。你不會想用它從頭寫一個程式，但寫一個子程式完全沒問題。

於是就有了一條非常務實的路徑：把 ODE 求解器包成 Python 模組，把 Quadpack 積分包出來，一個模組一個模組地做。這些東西最初是分開發的，你要用哪個就單獨裝。後來打包成了一個叫 multipack 的東西。

1999 年，一個高中生寫了 multipack 的 Windows 安裝包。這個高中生叫羅伯特·科恩，他後來成了 NumPy 的核心貢獻者。特拉維斯說，Windows 安裝包出現的那一刻，他第一次意識到了一件事：**二進位制安裝包對使用者的增長有決定性影響。**

這個認識後來直接影響了 Anaconda 的誕生。

2001 年，SciPy 正式釋出。艾瑞克·瓊斯（Eric Jones）和特拉維斯·沃特（Travis Vaught）在奧斯汀創辦了 Enthought，把特拉維斯手裡的 multipack、Perry Peterson 寫的 F2Py，還有其他一些散件整合到一起，裝上就能用。

SciPy 最初的願景其實很大。他們想做的是一個完整的研發環境，有陣列、有數學、有繪圖、有 REPL。換句話說，他們想把 MATLAB 整個搬進 Python。

最後這個願景沒有完全實現。原因很有意思。

特拉維斯說，**開源社群有一個內在的協作規模上限。**人數少的時候，大家協作得很好。一旦成功、人變多了，共識機制就開始失效，出現政治，出現大組織裡那種難以決定方向的困境。做基礎設施是分散式協作最擅長的事，可要把基礎設施擰成一個完整的產品交付出去，那需要產品管理，而產品管理恰恰不是這種協作模式自然長出來的東西。

繪圖的那部分後來由約翰·亨特單獨承擔下來，就是 Matplotlib。亨特當時在量化金融行業工作，覺得需要更好的繪圖工具，於是自己動手寫了一個。2001 年釋出，和 SciPy 是獨立的庫。

SciPy 會議也是 Enthought 在 2001 年創辦的，五十來個人，大部分是實踐中的科學家，關心的是怎麼用程式碼把研究做得更好，以及怎麼不再依賴 MATLAB。這個會議一直辦到今天，是很多人最喜歡的會議之一。

特拉維斯在這裡補了一句挺關鍵的自我定位。他說他本人並不反對專有軟體，也不是開源原教旨主義者。**他不喜歡 MATLAB 的地方非常具體：他寫了程式碼、發表出去，然後告訴別人“你要跑我的程式碼，必須先買一個 MATLAB 授權”。**這個問題驅動了他後面二十年的幾乎所有選擇。

## 讀斯托曼讀出來的問題

訪談裡有一段很坦白的自白。特拉維斯說，他當時讀理查德·斯托曼（Richard Stallman）的文章，很欣賞他對智慧財產權法的思考，也覺得那種集體協作的理想要是真的能成該多好。然後他讀到一句話，大意是：不生孩子，就沒這個問題。

那一刻他停下了。他當時已經有三個孩子，後來一共六個。他意識到自己沒法上這趟車。

他給自己定了一個方向：一定有辦法既保留開源的文化，又能賺到足夠養孩子的錢。

這個念頭把他推向了一個自己完全陌生的領域：經濟學。他在博士期間一邊讀資本論，一邊讀亞當·斯密，一邊讀米塞斯。**他說自己對教育體系有一種羞愧感：他高中是畢業致辭代表，大學成績也很好，一路都是好學生，可關於錢是怎麼運作的、價格是怎麼形成的，他一無所知。**

他讀到米塞斯 1920 年那篇討論社會主義共同體經濟計算問題的論文。核心論點很簡單：沒有私有產權，就不會有真實的價格；沒有價格，官僚就無法知道資源該怎麼分配。價格體系是在人們自由交換的過程中湧現出來的，而這些交換的前提是交換者對交換物有處置權。這套資訊流，自上而下的體制拿不到。

特拉維斯說，這個論證讓他豁然開朗。**價格其實是一種訊號機制，和開源社群裡那種“誰能解決問題誰就有影響力”的機制是同構的。**區別只是前者用貨幣計價，後者用聲譽和貢獻計價。

## 寫書、定價、賺夠 25 萬就免費

2005 年前後，特拉維斯面對一個很現實的問題：他在寫 NumPy，但手上沒有經費，還養著一個研究生。他不想按學術界的常規套路去跑經費申請。他做了一個實驗。

他寫了一本書，叫《NumPy 指南》（Guide to NumPy），自己出版、自己定價、自己用 PayPal 收款。他設定了一個規則：如果他靠這本書賺到 25 萬美元，或者過了五年，他就把書免費開放。

結果是：三年賣了 3 萬冊，賺了 9 萬美元。他用這筆錢付了自己研究生的工資，一年兩萬五。

他收到過大概五封罵他的郵件，說他靠開源的東西賺錢是壞人。更多人表示理解：書是可以收費的，這是圍繞開源做商業的一種合理方式。

這個實驗有個意外收穫。幾年後，DARPA 有個專案的負責人叫 Chris White，他記得特拉維斯的名字，正是因為當年讀過這本書，覺得這種定價模式很有意思。Anaconda 後來申請 DARPA 經費的時候，本來沒有去 demo day，按慣例不可能拿到經費，但因為 White 認識特拉維斯，他們破例拿到了。**那 9 萬美元的書，最後變成了幾百萬美元的科研資金。**

一年半之後特拉維斯去了 Enthought，有了全職工作，書也就順勢開放了。他說當時有個社群小組正在做 SciPy 的文件，需要書裡的內容，他就直接放開了。

萊克斯說，這件事放到今天再做一遍，大概能賺得多得多，因為社交媒體和工具的槓桿完全不一樣了。特拉維斯同意。他說他這幾年也想過再寫一兩本書，還試過僱槍手，但都沒成。原因也很實在：他被手上正在做的事情吸得太滿，靜不下心。

## 離開學術，加入 Enthought，然後是 Anaconda

2006、2007 年，特拉維斯的終身教職評審回來了。結果是把系裡劈成了兩半。有人是他的鐵桿支持者，有人堅決反對。事情一路鬧到大學校長那裡，最後的結論是：過兩年再來一次。

他當時的反應是：算了吧。

他打了個電話給艾瑞克·瓊斯，說想過來一起做事。2007 年他搬到了德州。他在 Enthought 待了四年，瓊斯讓他當了總裁。他們一起幫瓊斯買下了合夥人的股份。這件事最後沒有善終，他和瓊斯今天不再是朋友。特拉維斯說他仍然尊重瓊斯，仍然覺得遺憾，但那件事有兩面，他不想細談。

2012 年，他和彼得·王（Peter Wang）創辦了 Continuum Analytics，2015 年改名 Anaconda。這個名字今天幾乎是 Python 資料科學的同義詞。

Anaconda 最初的兩個技術方向是：讓資料科學能真正擴充套件到大規模機器上；確保 Web 這波浪潮不會繞過 Python 社群。現實推著他們走了一條更務實也更急迫的路。

真正讓他們動起來的是一個具體的痛點。2012 年，谷歌園區有一次聚會，圭多也在。會上他們直接跟圭多說：Python 的打包問題必須解決，使用者拿不到東西。圭多的回答是：你們自己去解決，我不覺得我們會去做。

圭多確實從來不太關心打包。特拉維斯說他問過圭多這個問題，圭多的回答是：我不用它，我不裝新庫。作為語言的創造者，這個立場也算合理，你需要什麼就直接放進發行版裡。

可普通人碰到的就是這道坎。特拉維斯舉了一個讓他印象很深的例子。**當時有人說，別改 NumPy 了，我花了一週才把 Python 環境裝好，你一改我就得全部重灌。**

那一刻他意識到問題有多嚴重：一個庫不敢改，原因不在技術上有什麼顧慮，而在安裝這個環節太痛苦，使用者不允許。

## Conda 要解決的不只是 Python

Conda 的設計決策其實很激進。他們決定做一個跨作業系統的包管理器，Windows、macOS、Linux 都支援同一套邏輯，而且不侷限於 Python，任何語言都能裝。

為什麼？因為 SciPy 裡面全是 Fortran，scikit-learn 的底層鏈著一堆 C++。**Python 原來的包管理方案，尤其是早期，根本不處理二進位制依賴這件事。**而二進位制依賴恰恰是科學計算生態最卡脖子的地方。

Conda 最初最出名的用法，就是一句命令裝 scikit-learn。scikit-learn 依賴 SciPy、NumPy 以及底層的 Fortran 和 C++ 二進位制，用 pip 裝極其痛苦。而從 2013 年到 2017、2018 年，這是安裝 scikit-learn 唯一的靠譜方式。

pip 後來透過 wheel 機制補上了很大一塊。但 wheel 有個根本性的取捨：它不處理多方依賴，遇到二進位制依賴就直接 vendor 進來，把所有東西打進一個包。**一旦底層依賴變了，整個 wheel 都得重新構建。**所以特拉維斯說，TensorFlow 到今天也不該用 pip 裝，用 pip 裝 TensorFlow 是個糟糕的主意，但很多人就是這麼做，因為文件裡這麼寫的。

這裡有個挺荒誕的現象。Conda 早於 pip，而且解決了很多 pip 解決不了的問題。但因為網際網路文件的長尾效應，你在網上搜任何“怎麼裝 TensorFlow”，前十頁全是 pip。2016、2017 年的時候 Conda 還會出現在搜尋結果裡，現在基本消失了。

特拉維斯給出的實用建議是混合用法：**用 Conda 搭底層環境，裝 NumPy、SciPy、scikit-learn 這些有複雜二進位制依賴的大件；然後用 pip 在上面裝那些純 Python 的小工具。一定要小心 pip 裝 OpenCV 或 TensorFlow 這類東西，因為它們一旦進來就很難更新。**

他還提了一個一直想加但沒能加進 pip 的功能：允許 pip 把依賴問題委託給系統包管理器。pip 裝東西的時候，遇到某些依賴可以轉交給 Conda 或者 RPM 處理。這個功能不復雜，但需要有人去做，而這件事一直缺錢。

Conda 還有一個長期沒解決的組織問題。特拉維斯說，任何專案一開始都是公司支援的，哪怕那家公司就是你自己一個人。**要真正病毒式傳播、成為基礎設施，它必須變成社群驅動的。**需要有人做治理，需要把外部貢獻者拉進來。Conda Forge 社群做到了這一點，Conda 本身一直沒能真正社群化。他直言，這是他認為 Anaconda 這家公司應該更推進的方向，這場仗不該由公司來打。

## Numba：讓“Python 慢”這個理由消失

Python 慢，是一個長期被拿來當笑話講的點。想快就用 C++，想舒服就用 Python，這是很多人腦子裡的二分法。

Numba 想改變這個分法。它的目標是：你寫 Python 迴圈，然後它被編譯成機器碼。

這個想法其實位元拉維斯寫 NumPy 的時候就有了。NumPy 裡有個東西叫 vectorize，你傳進去一個處理標量的 Python 函式，它會給你一個能作用在陣列上的通用函式（ufunc）。聽起來很美，實現上是假的：它會遍歷陣列，每次呼叫都跳回 Python 直譯器，所以極慢。

特拉維斯一直想要一個真正的版本。2009、2010 年，他找人試著用 PyPy 做過，效果不好，太重。2012 年他和彼得剛創辦 Anaconda，手裡有了錢，他又想起這件事。他當時聽朋友戴夫·比斯利（Dave Beasley）講過 LLVM，突然意識到，這就是那個答案。

於是他寫了一版 Numba，核心思路非常直接：**把 Python 位元組碼對映到 LLVM IR，然後讓 LLVM 負責生成機器碼。**

Numba 本身是用 Python 寫的。它自己不做解析，也不做程式碼生成，只負責從 Python 位元組碼翻譯到 LLVM 中間表示。特拉維斯說，這體現了 LLVM 真正的價值。它不好在“虛擬機器”這個命名上，好在它是一個大家能協作的公共地表。**在 LLVM 之前，你想擴充套件 GCC 或者 Intel 編譯器，那是另一回事；LLVM 出現之後，編譯器後端第一次變成了一個大家可以一起搭的公共基礎設施。**

Numba 被重寫過三次。特拉維斯說，這讓他第一次理解了為什麼電腦科學的課程是那樣設計的：編譯器真的很難寫，它會用到幾乎所有核心概念，樹結構、型別推導、pass 流水線。寫一個能跑的原型很容易，寫一個不變成義大利麵條的編譯器是另一回事。

Numba 的商業模式也很聰明：免費版跑 CPU，商業版 Numba Pro 跑 GPU，它是最早的 CUDA JIT 之一。2012、2013 年你就能寫一個 ufunc，跑在 GPU 上，自動並行化，速度提升千倍。**大公司願意為了速度付錢，這是一條靠譜的商業路徑。**

特拉維斯總結了兩類人願意為開源軟體掏錢：一類為好的使用者介面付錢，一類為速度付錢。

## 回到那個 np.sqrt 的爭論

訪談裡聊到一個具體的技術八卦。安德烈·卡帕西（Andrej Karpathy）在特斯拉帶自動駕駛團隊，他在推特上說，把資料載入裡的 np.sqrt 換成 math.sqrt 得到了顯著的效能提升。然後有人回帖說，用 Python 原生的平方根（也就是冪運算 0.5）還能更快。

特拉維斯對這件事的解釋很清晰。**如果你對一個標量呼叫 NumPy 的數學函式，它一定比 Python 原生的慢。**原因是 NumPy 的數學函式是通用函式，它要處理的不只是標量，還要處理任意維度陣列，所以即使是標量，它也要先廣播成零維陣列，然後走完整個通用函式的機器，最後再把結果解包出來。

作為對比，Python 執行時裡那個平方根就是純 C 呼叫，因為它只需要處理標量這一種情況，可以做大量特化最佳化。

那什麼時候該用陣列？特拉維斯給了一個粗略的經驗值：**資料量低於一千，甚至一萬左右，Python 原生方案可能更快；超過一萬，你就該用陣列了。**因為陣列帶來的並行、快取區域性性、SIMD 最佳化都會開始起作用。

他還補了一句更重要的判斷：別在這上面過度糾結。**他對“過早最佳化”這個說法是認同的。**你為了最佳化某個具體呼叫省下的那點時間，可能遠不如你為了最佳化它而犧牲的程式碼清晰度來得重要。

## Python 2 到 3：一場關於慣性的課

Python 3 從 2008 年釋出，到 2020 年 Python 2 正式停止支援，中間拖了十二年。這個跨度裡有很多教訓。

特拉維斯的判斷很直白：**Python 3.0 到 3.2 其實沒什麼值得升級的東西。**在他看來，Python 3.3 才算真正的 Python 3.0，因為那時候才湊夠了一波讓人願意動的特性。3.4 開始有人想要，3.5 加入了矩陣乘法運算子 @，那時候變成了不得不升級。

更深層的問題在共情上。

一個使用者為什麼要從 Python 2 升到 Python 3？除了修復了一些圭多自己看不慣的東西（比如 print 從語句變成函式），早期版本里幾乎沒有什麼讓使用者感到“值得付這個遷移成本”的東西。**你沒法單純靠“這是新版本”就讓一個龐大的人群搬家。**慣性一旦形成，改變它就非常困難。

特拉維斯還提到了一個容易被忽略的現實：Python 一直沒什麼錢。圭多有一份工作，但那份工作不是全職做 Python。整個語言生態的核心，幾十年來都建立在志願者勞動之上。這既是它的力量，也是它的風險。

萊克斯順著說了一句挺有意思的話：也許這是一種特徵，不是缺陷。就像奧運會運動員常年資金不足，恰恰是這種匱乏激發了偉大。

特拉維斯沒有完全同意，也沒有完全反對。他說這確實可能是部分原因，但他不認為錢是壞事。他也不認為有錢和保持價值觀互斥。

## Quansight、Labs、OpenTeams：給開源裝一臺經濟引擎

2018 年，特拉維斯離開 Anaconda，創辦了 Quansight。它的官方使命是“把資料連線到開放經濟”，本質上是一家資料科學全棧諮詢公司。

真正的創新在裡面。Quansight 下面有三個不同性質的東西。

第一是諮詢服務，做正常的生意，幫企業搭資料基礎設施、訓練團隊、解決使用 Dask 和 GPU 的具體問題。

第二是 Quansight Labs，一個非營利性質的機構，專門養開源專案的維護者。**它的模式叫“社群工單”：企業可以付錢讓某個人去改進 Spyder、NumPy 或者 SciPy，但不能指定具體做什麼，只能提出自己的優先順序和期望。實際的開發方向由維護者和社群共同決定。**Quansight 每個專案的利潤都會有一部分直接流向 Labs。

第三是 OpenTeams，這是特拉維斯最興奮的部分。他的判斷是：企業在軟體上遇到的問題，很大一部分不在買不到工具，而在買到的工具都需要大量定製，而定製要靠昂貴的諮詢公司。**開源方案加上同樣的定製，成本可以低得多。**OpenTeams 想做的就是把這件事變成一個網路：一頭連企業客戶，一頭連像 Quansight 這樣的服務商，中間做銷售、質量控制和交付保證。

他還想在開源和風投之間搭一座橋。他創辦了一個叫 Quansight Initiate 的基金，一部分 carry 直接流向 Labs。**他的想法是：每一個風投基金都該配一個開源研究實驗室，因為投資人對早期專案有天生的資訊優勢，而實驗室對社群有天生的資訊優勢，兩者結合可以形成正迴圈。**

這套東西聽起來很理想化，但特拉維斯已經做過一輪了。他對 Anaconda 時期的評價是：那時候創新太多，本來可以拆出五六家公司，因為結構沒搭好，都留在了內部。Dask 現在衍生出了兩家公司，Bokeh 也可以是一家，JupyterLab 又衍生出好幾家。**他想做的就是把這種自發的生態湧現，變成一套可以複製的孵化機制。**

## 錢花在哪裡，是一個巨大的錯配

訪談裡有一段沉重的對比。911 二十週年的時候，特拉維斯算了一筆賬：美國在中東各項行動裡花了超過六萬億美元。他說，把政治放一邊，光是想一想，把這筆錢裡的一小部分分給那些寫“讓世界運轉的工具”的程式設計師，會帶來多大的影響。

他說這就是他二十年來一直在試圖解決的問題。為什麼支撐全球科學和工業的基礎設施，是由志願者在業餘時間維護的？為什麼一個能影響幾千萬人的庫，它的作者從來拿不到工資？

萊克斯接了一句很有畫面感的話：**一起做貿易的國家不會打仗，也許一起寫程式碼的國家也不會。**特拉維斯說這個比喻好，因為開源本身就是跨國界的，沒有國界概念。而商業是有轄區、有法律、有邊界的。這兩者之間的摩擦，是他每天在處理的實際問題。

他談到在伊朗、巴基斯坦做過線上會議，遇到過程式設計師和科學家。他說這種接觸有一種人性化的力量。**我們平時接觸到的關於其他國家的認知，大多是浮在表面的段子，而那些段子和真實的普通人之間，差距非常大。**

他說如果未來大國之間真的會發生衝突，最可能的形式是網路戰。而這三個國家都有一流的開發者。如果這些開發者之間有大量協作，那可能就是一層防止衝突升級的底層基礎設施。

## 一款語言，一款編輯器，一張桌子

聊到工作環境，特拉維斯說自己是 Emacs 派，從寫 SciPy 和 NumPy 開始就是 Emacs 加 Linux。SciPy 和 NumPy 全部是在 Emacs 裡、在 Linux 機器上敲出來的，版本控制先是 CVS 再是 SVN，Git 是後來的事。

他開玩笑說，有一次他發推特說 Emacs 比 Vim 好，被罵慘了，最後把推特刪了。他不打算再碰這種話題。日常臨時編輯他還是會用 Vim。

關於 Lisp，他承認自己年輕時完全看不懂，覺得那些括號在阻擋思考。現在回頭看，他越來越理解 Lisp 的價值，也開始欣賞 Clojure 和 Hy 這類把 Lisp 思路帶到別處去的嘗試。

他也明確說，Lisp 很難真正進入大眾。**因為世界上大部分是“偶爾程式設計的人”。他們不打算以程式設計為職業，也不想面對各種精巧的語言設計，他們只想把手裡的事搞定。**這就是為什麼 BASIC 當年如此成功，也是為什麼微軟當年應該把 BASIC 那套思路在十年前就換成 Python。

他自己不用多螢幕。他說他在腦子裡習慣快速切換，物理螢幕太多反而分心。只有在一頭看資料、一頭要敲東西的時候，第二塊螢幕才真的有幫助。

至於作業系統，他用了十年的 MacBook。原因非常不極客：他經常要做演示、插投影儀，Linux 桌面上那些驅動折騰真的折騰不動了。

## 怎麼找到對的人

關於招聘，特拉維斯給的第一個建議很直接：**先去做一個開源專案，讓人們在上面貢獻，然後從貢獻者裡招人。**

他說傳統的面試很難。簡歷是候選人想讓你看到的版本，不是真實。一兩個小時的面試他判斷不出來，除非他跟你一起工作過幾周。

他更在意一種更底層的東西：一個人是否從根本上承認自己需要學習。他把“學習”當成公司裡最重要的價值觀之一。如果一個人覺得自己什麼都懂了，他會走得很辛苦。**謙卑是學習的第一步。**

在他自己的經歷裡，最常見的一種感受就是：他懂的東西越來越多，同時也越來越意識到自己懂的這點東西在整個圖景裡只是很小的一部分。所以他傾向於多聽，少說。他還提到妻子會提醒他，他現在有時太急於把自己的想法說出來，要讓別人也有時間說話。

## 什麼樣的程式設計師能做得好

聊到這個問題，特拉維斯給了一組相當誠懇的回答。

**第一是好奇。**沒有好奇心的程式設計師會變得平庸，會失去動力，最後做不出真正好的東西。

**第二是別想一次做完全部。**人的精力有限，每個人擅長的方向不同。最有效的方法永遠是縮小問題：定義清楚輸入、定義清楚輸出、寫下來你到底想做什麼，哪怕只是寫幾行字。很多人一上來就接一個大專案，想一口氣做完，最後迷失在裡面，做得一塌糊塗。

**第三是善用別人的工作。**別覺得從 Stack Overflow 上抄程式碼有什麼問題。沒有人是從零開始做所有事的。但要抄得明白。**你可以複製貼上，但要理解它為什麼這麼寫。**這就是好奇心起作用的地方。盲目複製貼上，你永遠學不到東西。

**第四是對技術炒作週期保持警惕。**每隔幾年就會有人說，測試驅動開發是答案，或者物件導向是答案，或者敏捷是答案。**這些口號裡通常有一點點真東西，值得你學。它幾乎肯定不是所有問題的答案。**

## 怎樣才能做出下一個 SciPy

特拉維斯給的答案很短，而且都是動詞。

聽。聽誰？聽有需求的人，也就是所有人。聽很多人。

然後做。你會摔倒，第一版很可能做得很爛，這沒關係。**迭代才是創新的核心。**真正卡住很多人的是那種心理上的猶豫：我們知道它現在很差，下一次會更好。態度本身才是過不過得去這道坎的關鍵。

也別指望這東西像刷短影片一樣能帶來即時快感。好的東西不會那樣出來。你得習慣深度問題，習慣在那裡坐一兩個小時不動。

萊克斯問他，寫 SciPy 和 NumPy 的時候孤獨嗎？特拉維斯說，非常孤獨。你必須有內在的驅動力。那個內在驅動有一個具體來源：**他必須首先相信這件事在某種角度上是對的，是這個世界需要的，然後才能一直做下去。**SciPy 對他來說就是這樣的東西：Python 已經有一批有影響力的人了，它需要更多庫，這件事本身是好的，那就去做。

有一個數字他特別強調：一個新的開源專案，**至少要給它 18 個月，才能真正知道反饋夠不夠。**六個月是不夠的。即使你做的東西完全正確，六個月後它也只是剛剛浮現出來。你在跟人打交道，而人有慣性，不會改變得那麼快。

## 作為一個導師，被差評是什麼滋味

訪談裡有一段他談教學的段落，值得單獨拎出來。

特拉維斯在楊百翰大學教過很多課，訊號處理、機率論、電磁學。他很想當一個好老師。他的學生給他打過差評，理由是他講得太高深了。

他反思說，他的問題在於把學生的現有水平估計得太高，以為他們已經懂了，於是就直接往下講。他心裡是尊重學生的，甚至可能正是因為太尊重，所以一上來就假設對方跟他站在同一水平線上。

他講了一個具體的細節。第一年教書，他準備了一堆投影儀透明膠片，一進教室就打得很興奮地一路講過去。兩週後做小測驗，全班什麼都不會。

他意識到問題，把膠片收起來，轉身開始用黑板。**黑板逼他慢下來。**寫字的速度限制了講課速度，學生終於有時間消化、有時間思考。他自己也因此變得專注。他的板書不好看，可他愛上了那個版本的自己。

這件事後來影響了 SciPy 的設計理念。**他們一直知道 SciPy 有一個教學層面的屬性：要把知識遞到人手裡，而不是炫耀自己懂多少。**名字不能太長，函式要直觀，文件要能真正把人送進細節裡去。

## 一個人的顯示卡，兩派人的戰爭

聊到今天的生態，特拉維斯提到一個讓他很在意的事：GPU。他指出，**NumPy 本該直接在 GPU 上跑。**今天你需要裝一個完全獨立的庫叫 CuPy，這本身就是歷史遺留問題。從原理上講，陣列沒有任何理由不能在 GPU 上工作。原因全都出在 NumPy 當年那個型別系統的設計，讓擴充套件變得過於困難。

他反省說，如果當年 dtype 的實現能更貼近 Python 3 的型別系統，後來的發展會順很多。Numba 能更好地接入，漸進型別會更容易，GPU 支援會平滑得多。**他說當年他只有 4 個月寫第一版，對 Python 2 的型別超程式設計機制理解還不夠深，這個教訓他記到今天。**

現在他正在推一個叫 data-apis.org 的專案。它不做統一陣列，它做統一介面。**不同的庫可以有各自的實現，但至少對外暴露一套統一的 API。**他說現在陣列社群的分裂比 2005 年更嚴重，因為牽扯到的人和錢都多得多了。行業當然養得起多套技術棧，但效率損耗也是真實的。他傾向於讓實現層競爭，讓介面層協作。

他也去 Google 和 Facebook 分別談過。他講得挺坦率：TensorFlow 和 PyTorch 都晚了，兩家本來都是 C++ 庫，等到發現必須支援 Python 時，倉促加了一層外掛。**他說 TensorFlow 早期那個 NumPy 介面是他見過最難看的 API 之一。**他當時在一個會議上直接跟演講人說，這個 API 以後不要在 PyData 大會上再展示了。他承認自己平時批評太少，這是他難得發飆的一次。

兩家後來走的路也不同。Facebook 更願意讓社群參與庫本身的結構，Google 則更傾向於讓社群用，但不容易讓社群改。這背後還是那個老問題：**你要照顧的是給錢的少數大客戶，還是給你帶來活力的多數駭客？**特拉維斯傾向後者，但他也承認這個平衡很微妙。太偏向駭客會破產。

## 每次填空白的時候，你填的是善意還是惡意

訪談裡有一段他講得相當動情。他說自己後來意識到，2012 年那封離開 NumPy 的公開信，對他是很艱難的。做任何有影響的事，你都不可能被所有人喜歡。你會被質疑，被批評，有些批評是需要的，因為他不可能什麼都做對。

他真正在意的是另一件事。**當資訊不完整時，人傾向於用最壞的假設去填補空白。**他會收到一些批評，那些批評基於的是對他的動機最惡意的解讀。他心裡會想，這個結論是從哪來的？我願意接受批評，可你完全誤解了整件事。

他說他寧願先假設對方是善意的。**當你對別人投射善意時，對方也往往會真的向你靠近。**這種機制有病毒式的擴散效應。

萊克斯補充說，推特和 Facebook 早年就發現了負面情緒能帶來更高的參與度，所以整個系統在結構上是鼓勵負面的。這場對抗，我們一直在打。

特拉維斯同意。**負面更容易，太容易了。**而且我們的腦子天生對負面更敏感，可能是一種防禦機制，怕不趕緊躲開就會被吃掉。

但他說，一個軟體工程團隊要是真想把事做成，就必須全員練習投射善意。這不是道德要求，它就是工程要求。

## 微軟當年如果出價出對了

特拉維斯透露了一個細節。2014 年，Anaconda 收到過微軟的收購意向。當時微軟剛買了一家 R 語言公司，也想在 Python 這邊補一塊。但那個出價來自離薩提亞·納德拉（Satya Nadella）還差兩級的人。如果那次出價是 Scott Guthrie 親自發起的，特拉維斯說，他今天大機率就在微軟了。

他說這話的時候沒有遺憾的意思，更多是一種對歷史分叉點的觀察。他對微軟後來在開源上的轉變評價很高。**微軟的文化裡有一件一直做得很對的事：他們知道自己的權力來自開發者。**當年鮑爾默那句關於開發者的名言在網路上被嘲笑，但那份底層認識是真的。收購 GitHub 在他看來是個聰明的動作，表明他們知道開發者在哪。

可他也指出，微軟對 GitHub 的整合還沒有形成像 OpenTeams 那樣的拓撲結構。**對開發者表達支援和真的讓開發者賺到錢，是兩件事。**

他順便講了一個關於企業營銷的觀察。他見過很多公司想用錢來跟開發者群體建立關係，但方式很拙劣。他的建議是：**直接把錢給最受歡迎的開源專案。**這是成本最低、效果最好的營銷投入之一。把一個百萬美元的營銷預算裡的一小塊，直接投給 NumPy、SciPy、Jupyter，換來的是開發者的好感和長期的信任。他希望企業把這件事理解成營銷，而不是慈善。這筆賬在 ROI 報表上說得清。

## 給高中的一個建議，和給世界的一個希望

訪談的最後，萊克斯問了一個比較籠統的問題：對今天的高中生和大學生，有什麼建議。

特拉維斯的回答分兩層。

第一層是家庭。他說，找到你愛的人，然後承諾於他們。**家庭就是你愛的、並且承諾的人，這個概念比血緣更廣。**它給你一種任何別的東西都給不了的錨。

第二層是別急著下定論。他說他看到很多高中生已經覺得自己什麼都懂了，他自己當年也這樣。這可能是自然的。可你真的要給自己十年的時間去看世界，因為你會變，你現在的立場很可能不是你十年後的立場。

他說他年輕時候非常自由意志主義，特別討厭美聯儲，現在他的觀點變得更有層次了。這本身就是成長的一部分。

他給出的最核心的一條建議，是**建設，而不是摧毀**。

他說，人的本能是遇到不喜歡的東西就去攻擊它。更好的方式是：**造一個新東西去替代它，把人吸引到你的道路上來。**你不需要摧毀一樣東西才能建立另一樣東西。

而這一切，最終都落在好奇心、愛和那些具體的事情上。不要只跟著錢走。找到你相信是對的東西，然後一直做下去。給這件事足夠長的時間。

訪談的結尾，萊克斯留了一句在程式設計圈流傳的玩笑，叫霍奇森定律：任何足夠先進的 Lisp 應用，最終都會用 Python 重新實現一遍。

## 如果你現在就想動手

從特拉維斯這幾十年的經歷裡，能挑出一些今天就能開始做的事。

- **從一個真實的、你自己的小痛點開始寫工具。**SciPy 的起點是他做 MRI 研究時發現自己缺一個 ODE 求解器。從一個具體的不方便開始，別從宏大的願景開始。
- **給專案至少 18 個月的耐心。**六個月看不出反饋很正常。如果你覺得方向對，先撐一年半，別在第六個月就下結論。
- **寫程式碼前，先寫下你要解決什麼。**定義清楚輸入和輸出，哪怕只有幾行。大部分失敗的專案不是寫不出來，是沒想清楚要寫什麼。
- **複製貼上，但要理解。**Stack Overflow 和自動補全工具是起點，不是終點。每次抄完，問自己一遍這段在幹什麼。
- **預設對方是善意的。**尤其在資訊不完整的時候。這麼做能真讓團隊跑起來，這是工程實踐，不是天真。
- **如果你在管技術團隊，先做一個開源專案，再從貢獻者裡招人。**簡歷和一兩小時面試看人，遠不如一起工作兩週準。
- **如果你是公司決策者，把營銷預算的一小塊直接投給支撐你業務的頂級開源專案。**回報率遠比你想的高，而且能長期生效。
- **搭 Python 環境時用 Conda 打底，pip 補細節。**科學計算那一層依賴複雜二進位制，別用 pip 硬裝 TensorFlow、OpenCV 這類東西。
- **不要為了最佳化一個具體呼叫糾結太久。**先讓程式碼清楚、可讀，再做最佳化。NumPy 對標量慢，這是設計取捨，不是 bug。
- **做建設者，不做摧毀者。**遇到你不喜歡的東西，造一個更好的替代它，而不是在評論區裡罵它。特拉維斯這四十年做的每一件事，本質上都是這樣。
