工程哲學：松本行弘（Matz）

重點摘要

• 為人而設計，而非為機器。 Matz 把程式設計師的快樂當作目標函數，讓帳單由矽片來買單。每一處語法抉擇，都先回答「讀到它的人會有什麼感受」，再去考慮「位元組能跑多快」。
• 最小驚訝，是「我」的驚訝最小。 這條原則並非對初學者期待的民意調查，而是一位嫻熟的作者把自己的挫敗感降到最低，而衡量的時點是在你把 Ruby 學透「之後」。
• MINASWAN：文化是一種設計產出。 「Matz 友善，所以我們也友善」表明，一門語言的社群是可以設計的表面，而不只是語法下游的偶然產物。
• Ruby 是一種品味的不懈貫徹。 它的連貫來自融合——把 Perl、Smalltalk、Lisp、Ada、Eiffel 調和為單一的聲音，而非委員會折衷的平均值。

這條原則

「於我而言，人生的目的之一是獲得快樂。程式設計師在能夠專注於程式設計的創造性一面時，常常感到快樂，所以 Ruby 的設計就是為了讓程式設計師幸福。」 – Yukihiro Matsumoto¹

大多數語言設計都為機器而最佳化：編譯速度、記憶體配置、指令數量，全是矽片在意的東西。Matz 把優先次序顛倒過來。他認定鍵盤前的那個人才是真正重要的對象，而機器的職責就是服務於他。「機器應當服務於人，」他說，「程式設計師卻常在不知不覺中服務於機器。讓機器來服務你吧。」²

這裡說的快樂是一條硬性的設計約束，而非披著工程外衣的軟性情懷。如果人的快樂就是目標函數，那麼每一處語法選擇、每一個方法名、每一項預設值，都變成一個關於讀寫程式碼的人會有什麼感受的問題，而非位元組能跑多快。Matz 把這種取捨擺得明明白白、坦坦蕩蕩：Ruby 願意花掉機器的週期，來換取程式設計師的舒適。同樣的信念讓品味成為一套結構性的系統，而非一種裝飾——做事的人的體驗成了承重的核心關切，而不是收尾時才補上的事後之舉。

一個決定統轄了隨後的一切：為人而設計，而非為機器。 語法、文化、社群箴言，全都位於它的下游。本文餘下的篇幅，將追溯一個人對自身幸福的追求，如何固化為一種站得住腳的工程立場——以及為何「服務於人」原來與「服務於機器」一樣嚴謹，而不是從後者的退縮。

來龍去脈

Yukihiro Matsumoto 於 1965 年 4 月 14 日生於日本大阪府，四歲起在鳥取長大。³ 他形容自己是個語言迷——不是語言學家，而是個「程式設計」語言迷。直到高中畢業他都是自學成才的程式設計師，後來在筑波大學取得資訊科學學位，並在那裡一個專攻程式語言與編譯器的研究室工作。³ 痴迷在先，Ruby 是它最終的產物。

他在 1993 年 2 月為 Ruby 命名——這個名字是在與同事石塚圭樹的一次線上聊天中冒出來的，那時還沒寫下任何程式碼——隨後用了好幾年把它打造出來。¹³ 動機源於不滿。「我真的很想要一門純正物件導向、又易於使用的指令稿語言，」他解釋道，「我四處找過，卻找不到。」⁴ Perl 很強大，但在他的品味裡算不上真正物件導向；Python 是物件導向的，但在他的品味裡又不夠令人愉悅。於是他造出了自己想用的語言。他在 1995 年 12 月 21 日發布了第一個公開版本。³

這個名字是個小玩笑。兩人選定 Ruby 作為一種寶石，算是對 Perl 的致意——Ruby 部分上正是在回應那門語言。先有 pearl（珍珠），再有 ruby（紅寶石）：一個像增量升級一樣命名的後繼者。⁴ 多年裡，Ruby 主要是個日本本土現象，郵件列表和文件都是日文。全球性的突破來得更晚，且來自外部：David Heinemeier Hansson 在它之上建立了 Ruby on Rails，而 Rails 在 2000 年代中期把 Ruby 帶向了世界其餘各地。⁴ 一個人為自身幸福而造的語言，成了一代人 Web 應用的底座。

這項工作

Ruby 的設計：快樂與最小驚訝原則

關於 Ruby 被引用最多的觀念，便是「最小驚訝原則」——語言應當以你預期的方式行事，好讓你把注意力放在問題上，而非工具上。Matz 認同這條原則，卻糾正了一種常見的誤讀。「最小驚訝原則，意思是『我』的驚訝最小原則，」他說，「而且它指的是在你把 Ruby 學得非常透徹之後的最小驚訝原則。」⁵

那句糾正，把整套哲學濃縮在一句話裡。他沒有去調查程式設計師、再把他們的期待取個平均。他設計這門語言，是為了把「我」的挫敗感降到最低，賭的是：一門讓自己的作者——一位嫻熟而苛刻的使用者——感到愉悅的語言，等到別人也達到嫻熟時，同樣會讓他們愉悅。「我想把程式設計時自己的挫敗感降到最低，所以我想把程式設計的力氣也降到最低，」他說，「我想讓自己在程式設計中獲得樂趣。」⁵ Ruby 是一門擴展開來的私人語言。它的一致性不是委員會的一致性，而是一種品味不懈貫徹的一致性。

為人設計，而非為機器

Matz 把軟體當作面向人的媒介，而非給硬體的一組指令。「別低估人的因素，」他說，「即便我們坐在電腦前，它們也是媒介。我們是在為人、與人一起工作。說到底，我們的大多數任務都與人有關。」⁵ 他把這一點推到口號之外：在 Matz 看來，介面就是整個產品。「如果你的系統介面糟糕，沒人會用它。所以系統的介面、它的表面——無論是面向使用者還是面向其他機器——都極其重要。」²

隨之而來的推論，是拒絕屈從於機器的偏好。被問及人與電腦的關係時，Matz 直言不諱：「我們是主人，它們是奴隸。」⁶ 機器之所以存在，是為了服務於程式設計師的意圖；一門逼著人像 CPU 那樣思考的語言，把這層關係弄反了。Ruby 的區塊、它萬物皆物件的模型、它易讀的方法名——Array#each、Integer#times、String#upcase——無不耗費實作上的複雜度，好讓表面讀起來就像意圖本身。

MINASWAN：文化作為一種設計產出

Ruby 最不尋常的產物不是某項特性，而是一條社群規範。Matz 以友善、耐心的舉止聞名，這種氣質蔓延成了一句箴言：MINASWAN——「Matz 友善，所以我們也友善。」⁷ 在 Ruby 早期，每當郵件列表上的討論變得火藥味十足，社群成員便援引它來把氛圍拉回更溫和的基調。它不斷傳播，終於成了一種身分認同。⁸

大多數語言設計者錯失的教訓是：「文化」同樣是一個設計表面。語言不止於它的語法——它是提出一個問題便能得到慷慨回答的體驗，是讀到一個作者在意你是否讀懂的程式庫的體驗。Matz 設計了語法，又以身作則地設計了圍繞它的社會姿態。一門為讓程式設計師幸福而生的語言，養出了一個矢志友善的社群，因為驅動二者的是同一種價值——社群，就是把最小驚訝原則用在了人身上。

mruby：受限空間中的哲學

2012 年 4 月，Matz 把 mruby 開源——這是一個輕量、可嵌入的 Ruby 實作，專為執行在完整 Ruby 過於沉重之處而生：微控制器、嵌入式系統、消費電子裝置。⁹ 它符合 ISO/IEC 30170 Ruby 規範的一個子集，以一個帶位元組碼編譯器和虛擬機器的小型直譯器的形式發布，能像 Lua 那樣嵌入 C 或 C++。¹⁰

mruby 之所以耐人尋味，恰恰在於它把這套哲學放到壓力之下檢驗。當你只有幾千位元組的 RAM、再無週期可揮霍時，「為人而設計」還能存活嗎？Matz 的答案是：保住 Ruby 的表現力，同時甩掉執行時的重量——把書寫 Ruby 的快樂帶到韌體層，而不是逼著嵌入式開發者退回到 C。這場以人為本的賭注，即便在對它最不友好的地方也站住了腳。

這套方法

Matz 的方法，是把同理心形式化為一種設計紀律。反覆出現的動作，不是去問「對機器而言什麼是正確的？」，而是問「那個人會有什麼感受？」——然後無論這個答案要求多大的實作代價，都照付不誤。

第二個動作是融合。Ruby 公然是衍生而來的：Perl 的實用主義與正規表示式、Smalltalk 的純物件模型與訊息傳遞、Lisp 的靈活性、Ada 和 Eiffel 的若干片段。⁴ Matz 並未發明新的典範。他從自己欽佩的語言裡偷來最好的點子，再把它們調和成一種連貫的聲音。鮮有設計者能施展那種品味——取用而非發明的紀律，以及讓借來的零件相融而非相撞的更難的紀律。最小驚訝原則部分上是一種「內在」的一致性——一旦你學會 Ruby 的某個角落，下一個角落便會按頭一個教給你的預期那樣行事。

第三個動作，是對取捨的誠實。Matz 從不假裝 Ruby 是快的那個選擇，他直白地說出來，而不是一邊標榜溫情、一邊悄悄為跑分而最佳化。代價真實而具體：因為 Ruby 裡萬物皆物件，連整數都是一等物件，算術也是透過向它傳送 + 訊息來完成，而非執行一條裸的機器指令。¹⁴ 5.times 或 (1..n).map 的便利——把數字當作你可以與之對話的物件——其代價是分派與配置的開銷，而 C 的 int 永遠不會有這筆開銷。Matz 選了清晰可讀的表面，讓執行時去承擔這張帳單，這正是那個被直白說出的賭注。

影響鏈條

塑造他的人

Larry Wall 與 Perl。 Ruby 繼承了 Perl 務實、把事做成的稟性，以及它的正規表示式基因。Matz 本人就把 Ruby 定位為對 Perl 的回應——保留其實用性，修正他眼中所缺的真正物件導向。（直接影響）⁴

Smalltalk。 「萬物」皆物件——整數、類別、nil——而計算透過傳送訊息發生，這一信念來自 Smalltalk。它是 Ruby 物件模型中最深的結構性繼承。（直接影響）⁴

Lisp、Ada 和 Eiffel。 Lisp 貢獻了靈活性，以及語言應當向程式設計師彎腰的那種意識；Ada 和 Eiffel 貢獻了語法與設計上的其他具體片段。Ruby 便是這場融合。（成型影響）⁴

他所塑造的人

Rails 時代的 Web。 Ruby on Rails 讓 Ruby 成為一代新創公司的預設語言，並給「開發者幸福感」配上了商業論據：更幸福的程式設計師交付得更快，於是這門以人為本的語言不只靠手感、更靠經濟帳贏得了專案。

一代人的基準期待。 在 Ruby 之後，程式設計師開始期待語言是「令人愉悅」的——讀來如散文，寬容，討人喜歡。這份期待重塑了更新的語言若想被認真對待所必須跨過的門檻。

Crystal 與 Elixir。 Crystal 幾乎原封不動地借用了 Ruby 的語法，同時透過 LLVM 後端編譯為原生程式碼。¹¹ José Valim 為 BEAM 打造的函數式語言 Elixir，把 Ruby 那種符合人因工程的稟性帶入了並行的世界；對許多借來的構造，Valim 都歸因於他「先前在 Ruby 上的背景」。¹² Ruby 的美學，比它的執行時活得更久。（風格脈絡）

貫穿始終的主線

這裡有一種富有成效的張力。Matz 為人的幸福而最佳化，並坦承自己為此花掉了機器的週期。工程的另一極則為機器而最佳化——John Carmack 數著每一個週期，直到一個畫格塞進預算；Linus Torvalds 捍衛「好品味」——那種讓特殊情形自行消失的資料結構。Carmack 和 Torvalds 問的是硬體配得上什麼；Matz 問的是人配得上什麼。兩極都沒有錯。最好的系統活在二者之間的爭論裡——既要富有表現力到讓人樂於書寫，又要嚴謹到不至於冒犯機器。Matz 正是一個證明：「為人而設計」是一種正當而嚴謹的工程立場，而不只是一種安慰。（系列銜接）

我從中汲取的

我做開發者工具和 AI 智慧代理框架，而 Matz 的賭注正是我一再下的那一注：處在迴路之中的人，才是真正重要的對象。一個程式撰寫代理，正如一門程式語言，是人的意圖與機器的執行之間的介面。如果它讓你驚訝、與你較勁，或逼你像機器那樣思考、而非思考問題本身，那它就失敗了——無論其內部有多麼精巧。內部之所以存在，全部意義就在於讓體驗對那個人而言清晰可讀。這也正是我把表面保持誠實、把技術堆疊保持輕薄的原因——免建置宣言就是把最小驚訝原則用在了工具鏈上。正如 Matz 拒絕假裝 Ruby 很快，我也寧願對取捨誠實，而不去掩蓋它：品質是唯一的變數，而程式設計師的幸福是品質的一部分，並不與之對立。

常見問題

Yukihiro Matsumoto 的工程哲學是什麼？

Matz 設計程式語言，是為了人的幸福與生產力，而非機器的效率。他言明的宗旨是：「Ruby 的設計就是為了讓程式設計師幸福。」¹ 他把程式設計師的體驗——可讀性、快樂、最小驚訝——當作首要的設計約束，並接受較慢的執行時，作為服務於此的誠實代價。「機器應當服務於人，」他說，「讓機器來服務你吧。」²

Ruby 中的最小驚訝原則是什麼？

它指的是語言應當以一位有經驗的使用者所預期的方式行事，從而把摩擦降到最低。Matz 澄清說，它的意思是「『我』的驚訝最小原則」——他設計 Ruby，是為了把自己作為嫻熟使用者的挫敗感降到最低，而且是「在你把 Ruby 學得非常透徹之後的最小驚訝原則」，並非頭一天的初學者所感到的驚訝。⁵

MINASWAN 是什麼意思？

MINASWAN 代表「Matz 友善，所以我們也友善」——這是從 Matsumoto 友善、耐心的舉止中生長出來的 Ruby 社群箴言。早期的 Ruby 使用者援引它，在郵件列表上確立慷慨的基調，它便成了 Ruby 文化身分的一部分。⁷⁸ 它體現了這樣一個觀念：一門語言的社群本身就是一個設計表面。

哪些語言影響了 Ruby？

Ruby 是一場刻意的融合。它汲取了 Perl 的實用稟性與正規表示式、Smalltalk 的純物件模型與訊息傳遞、Lisp 的靈活性，以及 Ada 和 Eiffel 的若干元素。Matz 把自己欽佩的特性組合進一門連貫的語言，而非另創一種新典範。⁴

出處