工程哲學:Guido van Rossum,可讀性至上

重點摘要
- 程式碼被閱讀的次數遠多於被撰寫的次數,因此 van Rossum 將 Python 優化成服務於日後讀這行程式碼的人,而非機器,也非當下動筆的作者。
- 有意義的縮排讓閱讀變得誠實——您所看到的縮排就是實際執行的區塊結構,所以一段 Python 程式的外觀無法對它的行為說謊。
- 「應該有一種顯而易見的做法」意味著陌生人寫的程式碼讀起來仍像出自同一人之手——讓眾人收斂到單一慣用寫法,是送給每一位未來讀者的禮物。
- The Zen of Python 出自 Tim Peters,而非 van Rossum——這是常見的誤植。Peters 只是提煉出早已內建於語言之中的價值觀。
核心原則
「Guido 的關鍵洞見之一,是程式碼被閱讀的次數遠多於被撰寫的次數。」——PEP 8,將此洞見歸功於 Guido van Rossum1
這是語言設計史上最安靜的一句革命性主張,幾乎所有人都點頭認同,然後又置之不理。請慢慢讀這句話。程式碼被閱讀的次數遠多於被撰寫的次數。您只敲一次的一行程式碼,日後會被讀上數十次——被核准它的審查者、延伸它的同事、繼承它的陌生人,而最常讀它的是您自己,在半年之後,努力回想當初到底是什麼意思。如果這是真的,那麼原始碼真正的受眾,既不是機器,也不是動筆當下的作者,而是日後閱讀它的人。而一門語言,理應為它真正的受眾而優化。
幾乎沒有一門語言做到這點。1980 年代的系統語言為編譯器與機器而優化;腳本語言為作者當下的便利而優化,這正是為什麼其中許多語言在寫完隔天就變得無法閱讀。Guido van Rossum 的賭注是:您可以改為替讀者而優化——讓清晰成為預設值,並由文法本身強制執行,使其在數十年間於整個社群中複利累積。他賭對了,而且幅度之大幾乎無人預見。The Zen of Python 把同一個價值濃縮成每位 Python 程式設計師都讀過的三個字:「Readability counts.」2
那份信念,與品味是一套技術系統這個論點背後的信念如出一轍——品味是一套技術系統,而非您口頭宣稱的某種感覺。可讀性不是事後用風格指南外掛上去的軟性偏好。在 Python 中,它是結構性的——內建於語法之中,讓語言不會像放任您寫出可讀版本那樣輕易地放任您寫出不可讀的版本。van Rossum 押的是:只要把清晰的那條路設成阻力最小的路徑,整個生態系便會在無人下令的情況下朝清晰漂移。
背景脈絡
Guido van Rossum 於 1956 年 1 月 31 日生於荷蘭海牙,1982 年取得阿姆斯特丹大學數學與電腦科學碩士學位。3他進入位於阿姆斯特丹的荷蘭國家數學與電腦科學研究院——Centrum Wiskunde & Informatica(CWI)工作,而他職涯中最具塑造性的經驗正在那裡等著他:ABC 程式語言。
ABC 由 Leo Geurts、Lambert Meertens 與 Steven Pemberton 在 CWI 設計,是一門以易學易讀為目標打造的教學語言,van Rossum 在 1980 年代中期投入數年參與其實作。4ABC 做了兩個會迴響至他日後一切作品的選擇:它以縮排標示區塊結構——所謂「off-side 規則」,沒有大括號,也沒有 begin/end——並把可讀性視為首要設計目標,程式通常只有對應 Pascal 或 C 版本的四分之一大小。4van Rossum 因此愛上了縮排這個構想;他後來表示,這做法掃除了關於大括號該放哪裡的那些無謂的宗教戰爭。5但 ABC 也有致命缺陷——單體式的實作、難以擴充的封閉設計、把它隔絕在真正的 Unix 程式設計師之外的學術孤立性。他用過這門可讀的語言,也看清了這門課的兩面:哪些構想是真正的好點子,哪些是害死它的錯誤。
接著就是那則著名的起源故事,而它確實如傳說所言那般發生。「六年多以前,1989 年 12 月,」van Rossum 寫道,「我在找一個能讓我在聖誕節前後那一週有事可做的『業餘』程式專案。」6他在 CWI 的辦公室因假期而關閉。他著手打造一門腳本語言,保留 ABC 最好的構想——可讀性、縮排——並修正它的錯誤,這次瞄準的是 ABC 從未觸及的 Unix/C 駭客。至於名字,「當時心情有點不正經(又是 Monty Python 飛行馬戲團的鐵粉)」,他選了 Python。6不是那條蛇,而是那個喜劇團體。他於 1991 年首度公開發布第一個版本。3

作品
可讀性與有意義的縮排
van Rossum 從 ABC 帶過來、影響最深遠的單一設計決定,正是新手爭論不休、老手卻早已視而不見的那一個:縮排即語法。 在多數語言裡,區塊結構由大括號或關鍵字標示,縮排只是人眼會用、編譯器卻會忽略的裝飾。這意味著兩者可能互相矛盾。大括號說一回事,縮排說另一回事,程式碼看起來在做一件事,執行的卻是另一件事——這就是經典的縮排誤導臭蟲,正是這一類錯誤製造出 Apple 惡名昭彰的 goto fail SSL 漏洞:一行多餘的縮排語句,落在了一個視覺上看似涵蓋它的 if 之外。
Python 讓這類臭蟲在結構上不可能發生。您所看到的縮排就是實際執行的區塊結構。不存在第二個隱藏的真相讓它得以背離。van Rossum 從 ABC 繼承這點,是因為它終結了大括號擺放位置的爭論,但更深層的回報恰恰呼應他的原則:它讓閱讀變得誠實。讀者眼中所感知的程式形狀,依定義,就是直譯器執行的形狀。45

誠實的結構,也是為什麼 Python 在非程式設計師眼中會是那個樣子:像一段恰好能執行的結構化虛擬碼。這正是用意所在。van Rossum 自稱是個非常仰賴視覺的人,他把表層設計得平易近人,把結構設計得清晰可見,好讓「讀程式碼」與「理解程式」之間的落差,小到文法所能做到的極限。
The Zen of Python 與「一種顯而易見的做法」
1999 年,資深核心開發者 Tim Peters 把驅動 Python 的設計價值寫成二十條格言。它們最終被奉為 PEP 20,The Zen of Python,並隨語言本身一同出貨:在 Python 提示字元下輸入 import this,它們就會印出來。歸屬問題很重要,卻常被弄錯:這段文字的作者是 Tim Peters,不是 van Rossum。2但這部 Zen 是對 Guido 設計感性的提煉——Peters 是在闡明那些早已內建於語言之中的價值,一如一位好評論家把藝術家的意圖闡述得比藝術家本人還清楚。
兩句話承載了整套哲學。「Readability counts.」 以及:「There should be one– and preferably only one –obvious way to do it.」2後面這一句,是對 Perl 那句名言「There’s more than one way to do it」蓄意的反轉。van Rossum 的 Python 押注於另一個方向:一門提供單一顯而易見做法的語言,正是一門無論誰來寫、程式碼看起來都一樣的語言,這意味著任何人都能讀懂任何別人寫的東西。收斂到單一慣用寫法不是對作者的束縛;它是送給每一位未來讀者的禮物。(就連這條格言本身的標點——把「and preferably only one」夾起來的破折號——也是個狡黠的玩笑,暗示這條規則在陳述自身時被稍微違反了一下。)
BDFL 與治理:2018 年的卸任
在 Python 的大半生裡,van Rossum 對語言設計握有最終決定權,頭銜源自 1995 年一場 Python 聚會上半開玩笑的稱呼,後由 Barry Warsaw 定為永久:BDFL,Benevolent Dictator For Life(終身仁慈獨裁者)。7這是一套貨真價實的治理模式。語言的變更都經由 PEP 流程——Python Enhancement Proposals,一套開放、書面化、有存檔的機制,任何變更都透過它被提出、辯論、定案——但當共識破局時,由 BDFL 拍板。這套機制運作了數十年,因為 van Rossum 的品味,正是社群所信任的那樣東西。
它終結於單一個運算子。PEP 572 引入了「海象」賦值運算式 :=,而那場辯論異常激烈——van Rossum 頂著大聲且持續的反對聲浪硬是推動了它。2018 年 7 月 12 日,在它獲准數天後,他在 python-committers 郵件清單上貼出一封標題為「Transfer of power」的電子郵件。「既然 PEP 572 已經定案,」他寫道,「我再也不想為一個 PEP 戰得這麼辛苦,卻發現有那麼多人鄙視我的決定。」他給了自己「一個永久脫離 BDFL 身分的假期」,而——這是最關鍵的部分——斷然拒絕指定接班人(「我不打算任命繼任者」),把如何發明自己政府的難題留給了社群。8社群也做到了:一個由五人組成、經選舉產生的指導委員會(Steering Council),經 PEP 8016 批准,如今治理著 Python。這位仁慈的獨裁者,刻意廢除了獨裁。
Python 的影響力
這場對可讀性的押注,複利累積成了軟體史上最龐大的成果之一。正因為 Python 是人們讀得懂的語言,它成了人們教得了的語言——如今它是全球大學最主流的入門語言。正因為它既可讀又可擴充,它成了科學計算的黏著劑:NumPy、SciPy、pandas,以及整套資料科學技術堆疊。又因為資料科學技術堆疊早已建立在 Python 之上,深度學習革命也是用 Python 打造的——PyTorch、TensorFlow、JAX,以及您聽過的幾乎每一個模型,都由這門語言驅動;這門語言,是一位荷蘭程式設計師在一個聖誕假期裡,為了讓人眼讀來輕鬆而設計出來的。van Rossum 本人於 2020 年結束退休生活,加入 Microsoft 參與 Faster CPython 專案,目標是讓直譯器大約快上一倍——用他自己的話說,這是回歸本源。9
方法
這套方法只有一個信念——為讀者而優化——並以三十五年罕見的一致性貫徹始終。
為閱讀程式碼的人而優化。 不是為機器,也不是為動筆當下的作者。每一個表層決定——縮排、精簡的關鍵字詞彙、對清晰的堅持——都服務於日後讀這行程式碼的人,因為那個人才是真正的受眾,而且這樣的人多得多。1
讓結構可見,讓閱讀誠實。 縮排就是區塊結構,所以眼睛所感知的,就是直譯器所執行的。語言拒絕讓程式碼的外觀與它的行為背離。4
偏好一種顯而易見的做法。 抗拒為同一件事提供五種慣用寫法。收斂到單一清晰的慣用寫法,意味著陌生人寫的程式碼讀起來仍像出自同一人之手。2
取其精華,修其錯誤。 Python 就是 ABC 的可讀性與縮排,減去 ABC 那單體、封閉、不可擴充的設計。van Rossum 並非無中生有;他是一位對前人成果挑剔的編輯。45
公開治理,並懂得何時放手。 PEP 流程讓設計決策公開且書面化。而當他作為最終權威反倒成了社群的負擔、而非對社群的服務時,他抽身離去——並拒絕欽點接班人,逼出了一個能取代他、且能長久存續的制度。8
影響鏈
誰塑造了他
ABC,以及 CWI 的 Lambert Meertens、Leo Geurts 與 Steven Pemberton。 ABC 交給 van Rossum 他兩個定義性的構想——縮排即語法,以及可讀性為首要目標——並藉由自身的失敗,教會了他那些負面的教訓:別打造單體,別封閉設計,別忽視在第一線工作的程式設計師。Python 就是被救回來的 ABC 那好的一半。(直接、具塑造性的影響)
Modula-3。 它乾淨的模組與例外設計,影響了 Python 自身的設計,提醒我們 van Rossum 是刻意向他所欣賞的語言借鏡,而非每個輪子都重新發明。(直接影響)
C 與 Unix 文化。 C 給了 Python 它的實作語言(CPython 是用 C 寫的),也給了它目標受眾——ABC 從未觸及的那群 Unix/C 駭客。Python 的構想,本就是要成為架在 C 之上的那層可讀腳本,能以 C 擴充,為 C 的世界當黏著劑。(具塑造性的影響)
他塑造了誰
地球上最龐大的程式設計社群。 以多數衡量標準而言,Python 如今是全世界使用最廣的程式語言,也是教給初學者的預設第一語言。整整一個世代,學會了用一種專為閱讀而設計的語法去思考程式。
資料科學、AI 與科學計算。 NumPy、pandas、PyTorch、TensorFlow——整個現代 AI 時代的工具,都坐落在 Python 之上,因為 Python 正是研究者讀得懂、又擴充得了的語言。這場對可讀性的押注,間接地,為我所投身的領域承重。
開源治理。 BDFL 模式,以及它刻意瓦解為一個經選舉產生的指導委員會,成了一個被反覆研究的範本:一個由個人品味領導的專案,如何能在那個人的權威消失之後依然存續。
貫穿的主線
Yukihiro Matsumoto 為了程式設計師的幸福與最小驚訝原則而設計 Ruby;van Rossum 則為了讀者而設計 Python。它們是兩大「喜悅」語言,是同一種直覺瞄準了略有差異的目標——Matz 為書寫時的感受而優化,van Rossum 為閱讀時的感受而優化——這正是為什麼它們如此頻繁地殊途同歸,以及它們的社群何以彼此惺惺相惜。Donald Knuth 則從學術界出發,以文學式程式設計(literate programming)抵達了同一個終點:那個激進的主張——程式是一部為人類而寫的文學作品,機器能執行它幾乎只是副產品。van Rossum 把這份信念建進了一門語言的文法裡,而非一套方法論。而當 Bjarne Stroustrup 把零開銷效能擺在第一位,任由 C++ 長成一門得花上數年才能流暢閱讀的語言時,van Rossum 把可讀性擺在第一位,並接受直譯器的緩慢作為代價——兩位設計者,最高優先順序恰好相反,各自以對方拒絕花用的那種貨幣付帳。(系列銜接)
我從中學到什麼
我牢記的一課是:可讀性不是禮貌;它就是真正的產品。程式碼被閱讀的次數遠多於被撰寫的次數,所以讀起來清晰的那個版本,才是更有價值的版本——而「我之後會把它整理乾淨」,是一個我此刻正悄悄背棄某位讀者的承諾。van Rossum 的手法,是把清晰的版本設成預設值,讓做對的事成為阻力最小的路徑,而非一樁需要自律的功夫。這與品質是唯一的變數是同一條標準:問題從來不是「這能跑嗎?」,而是「下一個讀到這裡的人,能不能像他所需要的那樣快地理解它?」
在我如今打造東西的世界裡——代理(agent)、工具迴圈、提示、那些其他代理與未來的我會在凌晨兩點讀到的代理框架程式碼——誘惑恰恰與「可讀性至上」相反:炫技的單行程式、隱晦的狀態、同一件事散落在一份沒人能整個記在腦中的程式庫裡的五種寫法。van Rossum 的做法,是挑出那一種顯而易見的做法,並讓結構誠實,好讓您所讀到的,就是實際執行的。那份信念——清晰,一旦化為結構、並由系統的文法強制執行而非交託給意志力,便會在日後每一位讀到它的人身上複利累積——正是從一個 1989 年的聖誕節業餘專案,貫穿到一個 2026 年的代理框架的那條主線。讀者就是受眾。為他們而打造。
常見問題
Guido van Rossum 的工程哲學是什麼?
van Rossum 的核心信念是:程式碼被閱讀的次數遠多於被撰寫的次數,所以一門語言應該為閱讀它的人而優化。1他把 Python 圍繞著「可讀性作為首要的、結構性的目標」來打造——不是事後外掛上去的風格準則,而是透過有意義的縮排、精簡的關鍵字詞彙,以及「應該有一種顯而易見的做法」這個原則,內建進文法之中。2他並將此與另一件事相配:透過 PEP 流程公開治理這門語言,並於 2018 年刻意卸下最終權威的身分。8
Python 為什麼用縮排而非大括號?
van Rossum 從他 1980 年代在 CWI 參與的 ABC 語言,採納了以縮排為基礎的區塊結構(「off-side 規則」);他喜歡它終結了關於大括號該放哪裡的無休止爭論。45而它之所以歷久不衰,更深層的理由是它讓閱讀變得誠實:在大括號語言裡,縮排只是裝飾,可能與大括號互相矛盾,於是程式碼可能看起來在做一件事,執行的卻是另一件事(縮排誤導臭蟲)。在 Python 中,您所看到的縮排就是實際執行的區塊結構——不存在第二個隱藏的真相讓它得以背離。
The Zen of Python 是誰寫的?
是 Tim Peters,一位資深的 Python 核心開發者,寫下了 The Zen of Python——那二十條被奉為 PEP 20、並在您執行 import this 時印出的格言。它並非由 Guido van Rossum 所寫,這是一個常見的誤植。2它所做的,是把 van Rossum 自己的設計價值提煉成令人難忘的形式——像「Readability counts」與「There should be one– and preferably only one –obvious way to do it」這樣的句子,闡明的正是那份早已內建於語言之中的感性。
Guido van Rossum 為什麼卸下 Python 的 BDFL 身分?
van Rossum 以 BDFL——Benevolent Dictator For Life(終身仁慈獨裁者) 的身分領導 Python 數十年,這個頭銜源自 1995 年一場 Python 聚會上半開玩笑的稱呼。7他在 2018 年 7 月 12 日請辭,就在 PEP 572(海象運算子 :=)在爭議中獲准數天之後;這個提案是他頂著沉重的反對聲浪硬推過關的。在一封標題為「Transfer of power」的電子郵件中,他寫道:「既然 PEP 572 已經定案,我再也不想為一個 PEP 戰得這麼辛苦,卻發現有那麼多人鄙視我的決定」,給了自己「一個永久脫離 BDFL 身分的假期」,並明白地拒絕指定接班人。8社群以一個經選舉產生、由五人組成的指導委員會取代了他。
資料來源
-
“PEP 8 – Style Guide for Python Code,” peps.python.org,作者為 Guido van Rossum、Barry Warsaw 與 Alyssa Coghlan。「Guido 的關鍵洞見之一,是程式碼被閱讀的次數遠多於被撰寫的次數。」該準則隨即引用了 PEP 20 的「Readability counts」。 ↩↩↩
-
Tim Peters,“PEP 20 – The Zen of Python,” peps.python.org。作者為 Tim Peters(非 Guido van Rossum);由
import this印出。內含「Readability counts.」與「There should be one– and preferably only one –obvious way to do it.」。 ↩↩↩↩↩↩ -
“Guido van Rossum,” Wikipedia。1956 年 1 月 31 日生於荷蘭海牙;1982 年取得阿姆斯特丹大學碩士;曾在 CWI 協助開發 ABC;於 1989 年 12 月著手撰寫 Python 直譯器,1991 年首度發布;名字取自 Monty Python 飛行馬戲團。Google(2005–2012,在此打造了 Mondrian 程式碼審查工具)、Dropbox(2013–2019)、Microsoft(自 2020 年 11 月起)。 ↩↩
-
“ABC (programming language),” Wikipedia。由 Leo Geurts、Lambert Meertens 與 Steven Pemberton 在 CWI 設計;一門以教學/可讀性為導向、使用縮排標示區塊結構(off-side 規則)的語言;程式大約只有對應 Pascal 或 C 版本的四分之一大小。van Rossum 在 1980 年代中期參與 ABC 的實作,並把它的縮排與可讀性構想帶進了 Python。 ↩↩↩↩↩↩
-
Bill Venners,“The Making of Python: A Conversation with Guido van Rossum,” Artima。van Rossum 談如何為 Unix/C 駭客打造 Python,作為 ABC 的後裔——保留 ABC 較好的特性(可讀性、以縮排分組),同時修正它的問題;以及他如何因縮排終結了大括號擺放位置的爭論而漸漸喜歡上它。 ↩↩↩↩
-
Guido van Rossum,“Foreword for ‘Programming Python’ (1st ed.),” python.org。「六年多以前,1989 年 12 月,我在找一個能讓我在聖誕節前後那一週有事可做的『業餘』程式專案。」關於名字:「我為這個專案選了 Python 作為暫定名稱,當時心情有點不正經(又是 Monty Python 飛行馬戲團的鐵粉)。」 ↩↩
-
“Benevolent dictator for life,” Wikipedia。這個詞於 1995 年首度用於 van Rossum 身上;由 Ken Manheimer 在一場 Python 聚會上創造出「Benevolent Dictator」,Barry Warsaw 則建議加上「for Life」。亦見 Guido van Rossum,“Origin of BDFL,” Artima,將此詞追溯至 1995 年的一場聚會。 ↩↩
-
Guido van Rossum,“[python-committers] Transfer of power,” python-committers 郵件清單,2018 年 7 月 12 日。「既然 PEP 572 已經定案,我再也不想為一個 PEP 戰得這麼辛苦,卻發現有那麼多人鄙視我的決定。」他宣布自己正「給自己一個永久脫離 BDFL 身分的假期」,並表明「我不打算任命繼任者」。背景:“Guido van Rossum resigns as Python leader,” LWN.net。PEP 572(海象運算子)位於 peps.python.org/pep-0572. ↩↩↩↩
-
“A Team at Microsoft is Helping Make Python Faster,” Microsoft for Python Developers Blog,談 van Rossum 於 2020 年加入 Microsoft 投入的 Faster CPython 專案,目標是讓直譯器速度大約提升一倍。亦見 “Guido van Rossum’s Ambitious Plans for Improving Python Performance,” The New Stack。van Rossum 談結束退休生活:「我向 Microsoft 應徵並獲得錄取……我選擇回歸我的本源。」 ↩