L Peter Deutsch#

人物背景#

L Peter Deutsch 是一位神童型程式設計師，1950 年代末期，11 歲時就開始程式設計。他的父親從 Harvard 的 Cambridge Electron Accelerator 帶回一份關於設計計算的備忘錄，裡面有些程式碼引起了年幼的 Deutsch 的興趣，從此踏上程式設計之路。

14 歲時在 MIT 的 PDP-1 上實作了 Lisp 直譯器（僅數百行組合語言）
在 UC Berkeley 大二時參與 Project Genie，寫了大部分作業系統核心（940 分時系統）
加入 Xerox PARC，參與 Interlisp 系統和 Smalltalk 虛擬機的開發
幫助發明了 JIT 編譯（Just-In-Time Compilation）技術
在 PARC 分拆公司 ParcPlace 擔任 Chief Scientist
在 Sun Microsystems 擔任 Fellow，撰寫了著名的 “Seven Fallacies of Distributed Computing”
Ghostscript 的作者——PostScript 檢視器，5-10 萬行 C 程式碼
1992 年因 Interlisp 工作獲得 ACM Software System Award
1994 年被選為 ACM Fellow
2002 年退出專業程式設計，轉而學習音樂作曲

程式啟蒙之路#

11 歲的偶然接觸#

父親帶回 Cambridge Electron Accelerator 的備忘錄，裡面有程式碼
被其中的「某種東西」吸引——一直對符號的表意系統感興趣
後來有機會為 Accelerator 的設計計算寫了一小段程式碼

14 歲的 PDP-1 Lisp#

在 MIT 找到 TX-0 和 PDP-1
拿到 Lisp 1.5 程式設計手冊的早期油印版
Lisp 有種數學味道讓他著迷——他一直有數學傾向
在 PDP-1 上實作了 Lisp 直譯器，不只是翻譯手冊，還需要自行設計 reader、tokenizer 和資料結構

Deutsch 回憶他早年的程式設計方法：「我做大部分程式設計的方式是先做資料結構設計。年輕時我的直覺足夠可靠，能指引我走向正確的方向——不是百分之百準確，但夠接近了。」

為何被程式設計吸引？#

回顧 50 年，他發現自己一直被表意符號系統（denotative symbols）所吸引
不只是自然語言，還包括各種「發聲有效果」的語言
這也解釋了他後來轉向音樂——音樂也是一種語言族群，有形式結構但不如程式語言嚴格

第一個有趣的程式#

第一個程式是為 Cambridge Electron Accelerator 做的計算
第二個讓他感興趣的是浮點數輸出格式化程式——在十進位機器上還算容易，但在批次處理的組合語言環境中仍然不簡單

重要專案經歷#

Project Genie（Berkeley 940 分時系統）#

大二時加入，幾乎寫了整個作業系統核心（約 10,000 行組合語言）
核心雖然不大，但資料結構設計開始變得重要——行程表、就緒佇列、I/O 緩衝區、虛擬記憶體追蹤
開始意識到軟體介面的重要性——系統呼叫的設計、核心與 shell 之間的介面
受 MULTICS 影響，從一開始就有核心與 shell 的清晰區分

Ghostscript#

他最大的單一系統，5-10 萬行 C 程式碼
到 1999 年底，基本上每一行程式碼都是他親手寫的
三個關鍵架構決策：
1. 語言直譯器與圖形完全分離——直譯器不知道任何圖形資料結構
2. 圖形庫使用驅動介面——圖形庫懂像素和曲線渲染，但盡量不知道裝置細節
3. 驅動程式實作基本繪圖命令——最初只有 draw-pixmap 和 fill-rectangle

Deutsch 的設計原則：「如果你有一個在多個領域運作的東西，而這些領域本身沒有太多耦合或互動，那就是放置強軟體邊界的好地方。」

先寫了一個沒有任何圖形的 Level 1 PostScript 直譯器
從開始到能輸入 3 4 add equals 並得到 7，大約花了三週
開發環境是 MS-DOS 上的精簡版 Emacs 和 C 編譯器
10 年後回頭看原始碼，大約 70-80% 的結構和命名慣例依然保留

設計哲學：先做資料結構#

先深入研究 PostScript 手冊
可能做了一些紙上筆記，然後直接開始寫 C 的 header 檔案
「先做資料。先粗略分割成模組。我仍然相信，如果你把資料結構和它們的不變量做對了，大部分程式碼就會自然地寫出來。」

程式設計思維的演變#

從小程式到大系統#

早期在 UNIVAC 和 PDP-1 上的程式基本上是單體式的
在 PDP-1 上的關鍵轉變：開始做資料結構設計
在 Project Genie 時開始出現介面設計意識——模組間怎麼溝通
建構越來越大的系統時，每寫一段程式碼都先問：「這段程式碼和周圍一切的介面是什麼？什麼傳入？什麼傳出？」

系統思維 vs. 小規模程式設計#

與非常聰明但缺乏大規模程式設計經驗的工程師合作時有過嚴重分歧
那些人是好的程式設計師、好的設計者，但不是系統思考者
他們不僅不習慣從系統角度思考變更的影響，甚至不知道這是一個該問的問題
「對我來說，理解大規模設計問題的人和不理解的人之間的區別就在於：你是否知道需要問哪些問題。」

對程式設計的深層思考#

為什麼程式設計這麼難？#

Deutsch 深入思考了一個根本問題：

演算法層面可以用數學作為基本模型，有數千年的數學歷史可依靠
系統程式設計層面則完全不同——von Neumann 計算和 Algol 家族語言與物理世界有著根本性的差異
我們的感官和大腦是為了應對物理世界而共同演化的，期望人們能在軟體世界中做得好是不合理的
「成為一個非常好的程式設計師，你需要有某些與眾不同之處。也許『有問題』說得太強了，但成為健全人格的特質和成為優秀程式設計師的特質——重疊並不多。」

Deutsch 認為物理世界有層次性（次原子、原子、化學等），且 99.9% 的時候可以用聚合方式理解。但軟體世界不是這樣——每個小零件都可能與其他零件互動，我們遠遠沒有找到讓這變得容易的方法。

指標（Pointer）的根本問題#

Deutsch 認為所有包含指標或參考概念的程式語言都有深層問題：

現實世界中沒有「指標」這種東西
傳遞和儲存指標是局部操作，但其後果會隱性地建立起一個圖——資料在程式不同部分之間流動、參考被傳播
即使在單執行緒程式中，也有幾種複雜的共享和通訊模式，沒有辦法描述或推理
Python 和 Java 的參考也是指標——超過一定規模後，與 C/C++ 有同樣的問題（除了記憶體損壞）

程式語言 40 年來沒有質性進步#

沒有任何程式語言在質性上比 Simula-67 更好
Java 與 Simula-67 相比並沒有好多少
Smalltalk 稍微好一些，但它基本上在 1976 年就已經存在了
他日常使用 Python，認為它比 30 年前的任何東西都好得多，但只是量的提升

純函數式語言的希望#

純函數式語言確實切斷了指標的 Gordian Knot
如果他要設計一個語言，會在純函數部分（只談值、沒有指標概念）和另一個領域（談共享、參考和控制的模式）之間做根本性的切割
承認 Haskell 等人在這方面走在他前面
也關注 E 語言——基於 capability 的概念，使用 port（通訊通道）而非指標

對程式正確性的看法#

博士論文是關於程式正確性證明
不再使用「程式正確性」這個詞了——現在說的是讓開發系統盡可能幫你確信程式碼做的是你想讓它做的事
舊的做法（歸納斷言機械式地對照程式碼檢查）有很多問題
未來的方向不在斷言，而在更強大、更深層的宣告式符號（declarative notations）
Jim Morris 曾說：「型別檢查器只是尼安德塔人的正確性證明器。」——如果有突破，會來自更強大的宣告式方法

軟體作為資本資產#

費用 vs. 資產的心態#

Deutsch 堅定地站在「軟體應被視為資本資產而非費用」的陣營
在 ParcPlace 推廣物件導向時，核心訊息之一就是：「你應該把軟體當作資本資產來對待」
資本資產需要持續的維護和投資，你不能把建構成本只算在當下的專案上

對 XP（極限程式設計）的質疑#

不太喜歡 XP——雖然與客戶緊密耦合有其道理，但客戶自己也不知道自己要什麼
擔心 XP 不重視軟體的長期可維護性：專案「完成」後呢？可維護嗎？可支援嗎？可演進嗎？
快速原型開發或任何不把軟體開發當作工程來對待的方式，他都嚴重質疑其長期品質
業界老話「快、好、便宜——三選二」——如果快又便宜，不太可能好

物件重用的承諾#

當年物件導向的賣點是可重用元件——去「老物件店」買零件拼裝
實際上被重用的東西要嘛非常小（圖示、網頁設計），要嘛非常大（整個語言、Apache/Mozilla 這類擴展架構）
中等規模的類別和類別群組重用並沒有真正實現

Ghostscript 中過早特化的教訓#

在架構層面選擇了像素導向（pixel-oriented）而非平面導向（plane-oriented）的色彩表示
這使得處理特殊色（如金色、銀色等非 CMYK 墨水）變得非常笨拙
原因是他對印刷業一無所知——Ghostscript 最初只是螢幕預覽工具
教訓：需求總是會往你沒想到的方向改變

程式語言偏好#

為何選擇 Python 而非 Smalltalk？#

雖然 Deutsch 是 Smalltalk 虛擬機的重要貢獻者，但他更喜歡 Python：

Python 有清晰的「什麼是程式」的概念——有模組（module）概念，模組宣告它們需要什麼
Smalltalk 的 image 模式中，根本沒有「程式」這個獨立實體——無法可靠地與他人分享部分程式碼
Python 可以在 Emacs 中編輯，一次看到更多行程式碼
Smalltalk 一次只能看到一個方法，這讓他發瘋
image 概念對單人快速原型很好，但對想把軟體當作資產分享的人來說很糟糕

為何不再用 Lisp？#

Deutsch 是重量級 Lisp 駭客（博士論文就是 600 頁的 Lisp 程式），但：

再也受不了 Lisp 語法——語法確實很重要
隨著年齡增長，每平方英寸的資訊密度越來越重要
中綴（infix）語言的資訊密度高於 Lisp
必須先過濾掉所有括號——不是智力問題，但讓大腦的符號辨識機制做了額外的工作
Lisp 在語彙上太單調（lexically monotonous）
Python 語法較好：中綴運算子讓運算元相鄰、迴圈和條件用關鍵字而非前綴
認為 Perl 是「語言設計的可憎之物」

語言系統的三腳架#

語言系統由三個支柱組成：語言本身、函式庫、工具。

Python 有很棒的語言、優秀的函式庫，但幾乎沒有工具
Lisp 有極佳的彈性但可讀性差
Smalltalk 有很好的 JIT 編譯器，但 image 模式是致命弱點
他曾嘗試用 Smalltalk 的 JIT 編譯器來為 Python 提速（pycore 專案），但 Python 和 Smalltalk 物件模型的不匹配讓這變得太困難

導師與影響#

Calvin Mooers#

information retrieval（資訊檢索）一詞的創造者
設計了一個給普通人用的程式語言——後來成為 TRAC
Deutsch 在高中或大學時期與他合作設計了這個語言
是他早期非常支持性的角色

Danny Bobrow#

長期朋友和導師
在整個職業生涯中一直是指導性的角色

Jerry Elkind#

PARC 計算機科學實驗室的經理
不是程式設計師，但教會 Deutsch 一個影響深遠的道理：要度量
「有時候——也許比你以為的更多——你的信念或直覺就是不對的，所以要度量。甚至有時候你以為不需要度量的東西也要度量。」

這個「度量」的教訓深刻影響了 Deutsch。從在 PARC 開始（大約 35 年前），每當他要做涉及大量計算或資料的事情時，他都會先度量。

對「Coder」一詞的反感#

Deutsch 是書中唯一一位對書名中「coder」一詞有強烈反應的受訪者：

對 programmer 這個詞也有輕微的負面反應——它不能告訴你這個人實際帶來什麼技能
Coder 更糟——它與整個軟體生產過程中最小、最狹隘的部分相關聯，如同建築中的「砌磚工」
也不喜歡 computer science——應該叫做工程和應用數學的組合，很少有真正的「科學」成分
他自己選擇的稱呼是 software developer——涵蓋從架構到編碼的一切，但不包含理解問題領域和需求的部分

成為優秀程式設計師的特質#

直覺與天賦#

在能力巔峰時，擁有極其可靠的直覺——做事情就是會正確
部分是運氣，部分是經驗已經內化到無意識的程度
隨著遠離軟體的日子越久，這種直覺變得越來越不可靠
據說要成為大師，需要在面前經歷大約 20,000 個具體案例
他在業界 45 年中經歷的案例正在逐漸變得不那麼容易存取

符號世界的舒適度#

一直在符號世界中如魚得水——符號及其模式就是他的日常
他的音樂伴侶則是從另一個方向來的——在吉他上即興，很少寫任何東西下來
認為應該程式設計的人是那些在符號世界中感到舒適的人

在 MIT 的早期經歷#

15-16 歲時重寫了 Jack Dennis 的 PDP-1 文字編輯器
原始碼是 Tech Model Railroad Club 的人寫的——「很聰明的人，但我看那些程式碼覺得很多都很糟糕」
但他猶豫把這歸結為人的問題——更像是他對「程式碼應該是什麼樣子」的看法不同

從程式設計到音樂作曲#

Ghostscript 的倦怠#

從 1986 年開始，Ghostscript 是他主要的技術專案
到 1992-93 年幾乎成為唯一的大型技術專案
到 1998 年開始感到倦怠——不僅做所有技術工作，還做支援、管理、一人公司的一切
僱人接手業務和工程後，到 2002 年徹底不想再看到 Ghostscript

嘗試定理證明#

55 歲時覺得可能還有一個大型專案的精力
去了 UT Austin 的 J. Strother Moore II 的團隊——做了一個關於「定理證明能否幫助改善 Ghostscript 可靠性」的報告
隨機挑了 20 個 Ghostscript bug，分析定理證明是否能幫助發現或預防
結論：不太有用——形式化「軟體應該做什麼」本身就是一個 Herculean 的工作
定理證明技術作為改善軟體可靠性的實用技術，基本上已經失敗了

維也納的頓悟#

2003 年夏天在維也納的舊音樂器博物館
看到 Leopold Mozart 的鋼琴、Brahms 用來練習的鋼琴、Haydn 家中的鋼琴
突然領悟：他之所以找不到下一個令人興奮的軟體專案，不是因為找不到，而是他已經不再對軟體興奮了
他進入軟體的動機之一是相信軟體能讓世界更好——他不再相信這一點了
決定轉向音樂作曲——一種可能持續比幾年更久的對世界的貢獻

「那個小小的閃電降臨了，我突然感覺到，我能對世界做出可能持續超過幾年的貢獻的方式——不是改變世界讓它變更好，而是貢獻一些東西——是做音樂。那是我決定從五十年的事業中深呼吸然後走開的時刻。」

仍然在程式設計#

忍不住——做了一些有趣的小專案
一個是郵件伺服器的垃圾郵件過濾技術（攔截率 80-95%）
另一個是開源的音樂樂譜編輯器——因為 Finale 和 Sibelius 都太糟糕了
樂譜編輯器經歷了四次架構重寫，最終採用方程式程式設計（equational programming）——用方程式定義變數值，讓實作自行決定何時求值
他仍然享受程式設計，但它不再是「給任何人」的——如果幾週不寫程式也沒關係

對軟體產業的悲觀#

軟體業的根本困境#

軟體實踐在 50 年中基本沒有大幅改善
軟體是一門細節的學科——這是根本問題
在我們理解如何組織軟體使我們不必思考每個小零件如何與其他零件互動之前，事情不會真正變好
要真正改善，需要丟掉所有包含指標概念的語言，重新面對資訊占用空間、存在於時間中、位於特定位置的事實

對計算未來的看法#

對計算的未來不太樂觀
個人計算和互動式計算曾經是他相信的理想——把計算能力交到人們手中，可能抗衡企業權力
從未預料到企業對網際網路的影響程度——曾以為網際網路是不可控制的，但中國證明了可以
看到的是一個被不道德壟斷者主宰的世界，他在其中看不到自己的位置

「建構軟體的方式今天比起 30 年前好不了多少。」——Deutsch 認為這是因為我們對程式設計的基本模型（指標、von Neumann 架構）有根本性的問題，而不僅僅是工具或方法論的問題。