Joe Armstrong 面對面

Joe 老爺子是 Erlang 世界裡的一個圖騰。

他書中的句子，他的公開演講或是私下的談話，都被不同的人到處引用 —— 今年的 code beam，好些 speaker 用 Joe 的原話來佐證自己的觀點。Joe 因為 Erlang 的誕生被視作天才，視作英雄，視作傳奇。但 Joe 自己卻將其歸功於 Ericsson 的「大度」：你知道 Ericsson 為什麼把 Erlang 開源了么？因為有一天高層突然宣布：所有項目只能使用 C++ 或者 Java，不能用除此之外的任何語言。於是我們跟頭頭們商量，既然 Erlang 我們自己都不待見了，那乾脆開源吧，頭頭說：隨你便，我不關心。於是 Erlang 才得以擺脫 Ericsson 的控制，獲得新生。

感謝 Ericsson 的愚蠢決定，否則這個世界便少了一門如此奇特而優雅的語言，而我也無法對半個地球外的一位老人頂禮膜拜。

如果你對 Erlang 沒有了解，可以讀一下我之前的文章：上帝說：要有一門面向未來的語言，於是有了 erlang。

在那篇文章里，我介紹了 Joe 的 worldview：

• everything is a process.
• process are strongly isolated.
• process creation and destruction is a lightweight operation.
• message passing is the only way for processes to interact.
• processes have unique names.
• if you know the name of a process you can send it a message.
• processes share no resources.
• error handling is non-local.
• processes do what they are supposed to do or fail.

他關於 Erlang 的所有想法，都或多或少和這個 worldview 相關。

跟老爺子坐在一起沒聊多久，我就問了個「中二」的問題：「Erlang 在未來有沒有打算引入 type system？」我知道 type system 會讓 hot code reload 變得難以處理；也知道 type system 會讓這門語言變得複雜，但就是莫名其妙問了這麼一句。Joe 沒有直接回復我，而是這樣娓娓道來 ：

John Hughes（haskell 的發明人之一）在談起 haskell 時總會說：think type first。而我會說：think concurrency first。這是這兩門語言的本質不同。我並不關心 type system —— programming is not about code, it』s about understanding。良好的類型設計反映了設計者對所設計系統的理解，然而 type system 並不能幫助你更好地理解你所設計的系統。在一個對所處理的問題理解錯誤的情況下，一個人可以寫出正常編譯通過的代碼，並且這代碼是可以測試通過的 —— 因為作者對 problem 理解是錯誤的，因而他寫出的 test case 也是錯誤的。一切都如此漂亮，可是軟體卻並未解決問題。

所以糾結 type system，寄希望於 type system 讓你不犯錯誤（或者讓工程團隊不犯錯誤），這是在尋找銀彈。

think concurrency first。我們的世界本來就是並發/並行的。OOP 試圖用一種錯誤的方式來描繪世界，因而得到的是複雜且不好理解的系統。比如一個電梯調度系統 —— 三部電梯停在各自的樓層，等待指令來決定如何運行。你如果試圖用 OOP 描述電梯，為其設置屬性，提供方法，其實是把問題複雜化了。三部電梯就是三個獨立的 process，有他們自己的 state（所停樓層），它們把 state 通過 message 傳遞給調度系統，調度系統根據用戶輸入的 message，給最合適的 process 發消息，然後 process 決定自己如何行動。如果你 think concurrency first，那麼，你對問題首先更容易理解，也更容易建模。

隨後，老爺子一錘定音：

if you want type system, use a different language.

整個談話中，老爺子語速很快，往往我還在思考他拋出的上一個結論時，他就把下一個問題拋出來了 —— 這讓你很難想像他已經是 67 歲的「高齡」。偶爾，他的思維會跳躍到物理學，比如 Minkowski space —— 跟一個差一點成為物理學家的計算機先驅談話就是這麼不著痕迹地在時空中跳躍。我問他還在寫代碼么，他給了我非常肯定的回答 —— 他說他在試圖解決一些非常基礎的問題。當我問是什麼問題時，他狡黠一笑：你聽了我明天的 keynote 就知道了。

我的好友孫博談到白日夢旅行時，常說的兩個詞就是想像力和好奇心。想像力和好奇心是人類作為一個物種而言，最珍貴的品質。在聊天的過程中，Joe 老爺子的聲音始終是柔和的，探尋的，他不斷地拋出問題，像兒童一樣處處充滿好奇心，又像哲人一樣通過問題啟發你探尋事物的本源。他看問題的角度經常出乎我的意料，天馬行空卻扣著關鍵之處。講一會，他會笑一笑，親和地像一個鄰家老爺爺，毫無架子，毫無世故，彷彿對面坐著的不是一個跪著的仰慕者，而是許久未見的忘年交。

聊著聊著，我漸漸輕鬆起來，問題也隨意起來。我問他對這次 Code Beam 怎麼看？他坦率地說聽了幾場，這屆 speaker 不行。我會心一笑。他繼續說 —— 人們在演講的時候往往忽略了問題，而直接給出答案。people didn』t really distinguish problem & solution. what』s your problem? why are you doing this? 在你的問題沒有闡述清楚之前，我們之間無法達成共鳴，那麼我為什麼要關心你的答案？不解決問題，或者不解決我關心的問題（你要想辦法讓我關心），再光鮮亮麗的 solution 都是沒有意義和價值的。我戰戰兢兢，汗出如漿 —— 因為，我自己的講稿也是上來就是談 tubi 的 elixir service 是如何構建，部署，升級和監控的，並沒有談我們遇到了什麼問題，為什麼要這麼做，尤其是講為什麼要單做一個軟體來做 release 時，非常突兀。好在，有了這次談話，我正式講的時候花了六七分鐘來把 problem 和 why 講清楚。

順著 whats your problem 這個話題，他說做研究，找好的 problem 要 look at cracks on a marble floor：

我們現在有太多太多的編程語言了 —— python，ruby 這樣如此相似的語言，為什麼我們需要發明兩個？有了 Java 為什麼還要有 C#？大家把太多太多精力都放在構建一門更好的語言，可是，真正稱得上有自己思想的語言很少。大部分語言可以被歸到幾個類目下面。如果把一門門語言看成一個 blackbox 的話，那麼，大家都只顧自己的一畝三分地；如果把一台台機器看成一個個 blackbox 的話，那麼，大家擠在一方小小的土地上廝殺，此消彼長。我們應該更多地 build things outside the boxes。在 blackbox 之間，廣袤的領地，無人問津。blackbox 如何被連接在一起，如何 communicate & collaborate，還有大量的工作要做。

說到興起，他繼續提點我：look at cracks 也分場合，優先選擇那些重要的 cracks。他給我講了個 Altair 的故事 —— 補充一下：Altair 是 PC 時代的先驅 —— apple I 就是受其啟發而發明的，而蓋老師在 DOS 之前的主營業務 Basic，生意也是始於 Altair Basic。他說七十年代末，Altair 在 geek 群體間已經很火爆，有個混 synth 圈子的哥們尋思著為 Altair 做一款 synth 的工具，必定火爆。結果軟體吭哧吭哧做出來，也就幾個人感興趣。所以你可以在一個小眾的，還未被認識的領域有所作為，但不要試圖在兩個小眾的領域的交集間有所作為。這樣的話市場太小了，你熬不過黎明前的黑夜。

接下來我問老爺子怎麼看 blockchain？

老爺子一下子聲音提高了八度。what are you talking about? are you referring cryptocurrency? or open ledger? or smart contract? or something else? people usually mixed these things up with 「blockchain」

我趕忙說，我們先聊聊 cryptocurrency，或者 bitcoin。你覺得…

老爺子打斷我的話：bitcoin is morally wrong. Isn』t it?

接下去差不多十分鐘時間，老爺子就像拷問戰犯一樣，拷問 bitcoin，或者更嚴格地說，拷問毫無意義浪費資源，讓地球變暖的 PoW。我好幾次想插嘴，想把話題往技術上撩，都被老爺子彈開了。老爺子情緒激昂，我怕我再執拗下去，被放在火上烤的就不是 PoW 而是我 —— 畢竟，morally wrong 這頂大帽子是實錘，辨無可辨，因而我知趣地放棄這個話題，靜靜做個好聽眾。

Bitcoin created a world of mess… As a software engineer, our responsibility is to reduce complexity, or to reduce entropy….

這句話我很認同，複雜是軟體的天敵，我們搞這麼多 principles，methodologies，paradigms，patterns，目的都是減少複雜度。我曾經寫的一篇文章：是時候想想該怎麼刪代碼了 提過一個思路：以構建可刪除的代碼為設計目標。這也是一種降低 complexity，減少軟體中的 entropy 的方式。

在抨擊完 bitcoin 道德上立不住後，老爺子顯得有些疲態，我趕緊順勢把話題扯回到 Erlang —— 我還有一堆來自於朋友圈的問題有待發問。我挑了個簡單的：你最喜歡 erlang 哪一點？

老爺子立刻精神起來，目光炯炯：

簡單。你看我們處理 concurrency 的方式 —— 這是唯一一個把 security，isolation，fault tolerance 完整地，且又簡單清晰地，涵蓋在內的方案。我們八十年代解決掉的問題，大家現在還在窮盡心力去解決。

我一個快 70 的老頭兒，如果從凳子上摔下來，我能 recover 我自己么？顯然不行。我只能發個 signal（message）給你，然後你把我扶起來 —— 甚至，我都不用主動發，我們之間有 link（link 是 erlang process 之間的一種連接），使得你密切關注著我，以至於我一旦跌倒，你立刻得到視覺上的通知（就像 {EXIT, Pid, Reason} 一樣），於是你很快把我扶起來。這就是 fault tolerance，簡單，明了，不用深奧的計算機知識佐證（說你呢，exception handling），小朋友都能懂。這個方案之所以淺顯易懂，是因為這是很自然的 solution，我們每天就是如此生活。你再看，process 只能通過 message 通訊，所以 process 和 process 完全獨立（isolation），就像一個個人。由此一個 process 的問題也很難擴展到整個系統，因而 security 也得到了保證。

「完全贊同！」我附和道。「而且 message passing 作為 concurrency 的一種方式，不僅適用於單機，也無縫適用於分散式系統。其它方案，單機內部一種模式，機器間還是要 message passing，因而不得不在兩種模式間切換，考慮起來很複雜。」

老爺子點點頭。「一件事情如果過於複雜，那麼一定是哪裡出問題了 —— 大部分情況下是對問題的理解出現偏差」。老爺子話鋒一轉：

人們總是為沒有想明白的問題創造解決方案，這是個嚴重的問題。比如說 JSON。what』s the reasoning? 我不理解為什麼我們需要發明 JSON，也許是 JSON 之前的交流方式太複雜，或者太不可用，所以它就出現了？像 JSON 這樣的 serialization 方案，human readable 絕對是個偽命題。想想網路上傳輸的內容 —— 它們不過是 signal 而已，傳輸的是一個個 bit —— 那為什麼我們要用 text，而不是 binary 來節省帶寬，降低消耗？human readable 在屏幕上是有意義的，在網路上，在內存中，完全是無稽之談。

聊了一個多鐘頭，快到午餐時間了。老爺子沖我狡黠一笑：你是不是準備了一堆問題？還剩什麼問題想問的？我想出去走走，活動活動筋骨了。

我看了看我剩下的問題：

• What』s the future direction of erlang/OTP?
• How do you see current status of distributed erlang? Any plan to improve it? for example, will we have gen_raft, or gen_pbft? or replace the full mesh network to p2p network?
• How do you compare erlang and elixir?
• How do you do trade off between performance and debugability, giving that OTP put so many efforts to make things traceable?

還有不少，我便挑了幾個問他。

對 erlang/OTP 里加入更多的 distributed consensus behavior，如 gen_raft，老爺子是無所謂的態度。他說這不重要。他雖然有能力影響 OTP team，但這是他們的選擇。對於 elixir，老爺子讚賞有加，說他有三個孩子，erlang 是第三個，elixir 是他所喜愛的小孫子。另外一個 erlang VM 上的語言，他的老友 Robert Verding 的 LFE（Lisp Flavored Erlang），就沒那麼好運氣了 —— 老爺子說這是遠房的侄子。對於 performance，老爺子看法一直未變：correctness is 1st, performance is the last thing I considered。這讓我想起他曾經說過的：

Make it work, then make it beautiful, then if you really, really have to, make it fast. 90% of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful!

臨了，我問老爺子對中國的印象。他說他很喜歡中國，很喜歡北京，還拿了他和夫人在天安門前的合影給我看。我說，那你打算什麼時候再去中國看看啊？他笑笑，那看你們什麼時候邀請我來中國參加有關 erlang 的大會啊。

一些題外話：

• 是的，這裡的對話並非原話 —— 我 iPad 上面記錄的以及我回憶的，還有很多素材我記不起來或者不知道怎麼擺進來。對話的順序也根據行文的需要進行過調整。
• Joe 是英國人，地道的英國腔。瑞典是他的第二故鄉。
• Joe 問了我一個有趣的問題 —— 在做某個研究前：How do you know if someone else has done it?

推薦閱讀：