Fran Allen#

Fran Allen 原本計畫成為一名數學老師，1957 年為了償還學生貸款而進入 IBM Research 擔任臨時程式設計師。她的第一項任務是教 IBM 科學家們使用剛發明的 Fortran 語言。沒想到這份「臨時工作」一做就是 45 年，她在 IBM 投入了一系列編譯器專案，包括 STRETCH-HARVEST 機器的編譯器、從未實現的 ACS-1 超級電腦，以及她自己領導的 PTRAN 專案。PTRAN 開發了 Fortran 程式自動平行化的技術，並發展出 Static Single Assignment (SSA) 中間表示法，如今被廣泛應用於靜態與即時編譯器中。

2002 年，Allen 因「對最佳化編譯器理論與實踐的開創性貢獻」獲頒 Turing Award，成為該獎項 40 年歷史中首位女性得主。她也是首位獲得 IBM Fellow（IBM 最高技術榮譽）的女性。

背景與進入程式設計的契機#

Allen 擁有數學學士學位與物理副修，在紐約州教了兩年書後前往密西根大學攻讀碩士
在密西根大學主修數學，為滿足跨領域選修要求而選了一門計算課程（當時 computer science 尚不存在為獨立學科）
該課程使用 IBM 650 機器，學生需學習機器本身運作原理、組合語言，並親手在機器上執行程式
IBM 650 是一台鼓式記憶體（drum machine）機器，指令儲存在不斷旋轉的鼓上，程式要跑得快就要精心安排指令在鼓上的位置

加入 IBM#

為償還學貸而需要工作，恰好 IBM 招募人員到校園拜訪
面試時甚至不清楚自己是在應徵 IBM Research 的職位
在等待教職面試結果時接到 IBM 電話，當場答應並前往 Poughkeepsie 的研究實驗室報到
IBM 當時正在快速擴張計算領域，沒有正規的電腦科學課程，從各種背景招募人才

Allen 的第一項任務是教 IBM 科學家使用 Fortran。她在 1957 年 7 月加入，而 Fortran 才在同年 4 月 15 日作為產品發布。IBM Research 下令 9 月前所有程式設計都必須使用 Fortran。

那些科學家們使用的是 IBM 704 機器，習慣直接在機器上寫組合語言，不相信高階語言能達到接近的效能
這是科學家們最後一次採用新語言的時代——他們至今仍在使用 Fortran

重要專案經歷#

Monitored Automatic Debugging System#

在 Fortran 編譯器與 Stretch 編譯器之間參與的專案
這是一個非常早期的作業系統，為 IBM 704 的組合語言層級除錯系統
只有三人參與開發，他們在電腦上安裝了按鈕，包括一個「panic button」
Allen 的任務之一是將組合語言程式轉換為直欄二進位格式（column-binary）

Allen 在這個專案中閱讀了由資深程式設計師 Roy Nutt 撰寫的原始程式碼，發現它非常優雅。這次閱讀程式碼的體驗培養了她日後的習慣：透過閱讀優秀程式設計師的程式碼來學習新語言和新技術。

STRETCH-HARVEST 編譯器#

Stretch 機器始於 1955 年，目標是比當時世上任何機器快 100 倍
硬體具有極複雜的並行性：多路交錯記憶體、管線化運算單元、多指令同時執行、look-ahead 單元
編譯器是機器成功的關鍵，因為記憶體延遲問題的複雜度已超越手寫組合語言程式設計師的能力
Allen 負責最佳化器（optimizer），其他人負責剖析器（parser）、暫存器分配器（register allocator）等
四位負責大型組件的專案監督者中，三位是女性

專案管理結構#

約三人負責整體編譯器設計
四人組成的團隊負責設計介面與各大組件的整合
Allen 帶領 17 名程式設計師進行實作
設計與編碼幾乎同步進行，受客戶需求與截止日期驅動
當時尚無「軟體工程」的概念，團隊間有大量的合作自由度

IBM 360 與 Cleanroom 流程的誕生#

IBM 360 專案（由 Fred Brooks 主導）遭遇嚴重的軟體危機
硬體工程師被調來管理軟體，帶入了硬體領域的嚴格設計紀律：設計審查、設計規格等
事後有人提出 Cleanroom 軟體工程紀律，聲稱若遵循其流程就能寫出完美程式
IBM 產品開發大力推行 Cleanroom 流程：設計者與程式設計師分離，非互動式的開發方式

Allen 認為 Cleanroom 流程在實踐中令人沮喪——設計者與程式設計師無法互動。而且軟體的生命週期很長，需求會改變，環境會變化，過於詳盡的規格往往無法長期維持。

PTRAN 專案#

Allen 領導的重大專案，專注於顯式並行性（explicit concurrency），而非 CPU 管線中的隱式並行性
目標：使用者以自然的循序方式撰寫 Fortran 程式碼，由編譯器自動進行最佳化並利用並行硬體
概念是處理既有的「dusty decks」（舊程式碼庫），自動利用硬體的平行元件
建立在 Dave Kuck（伊利諾大學）等人的既有研究基礎上
團隊約 10-12 名核心成員，來自 NYU、MIT、伊利諾等不同學校，背景多元

Static Single Assignment (SSA)#

PTRAN 團隊開發了 SSA 中間表示法
Allen 起初不相信 SSA 能在合理時間內實作，直到她親自檢視了團隊成員的程式碼和資料結構
看完後她說：「就是這個。它可以運作。」
SSA 如今被廣泛應用於現代編譯器中

程式碼閱讀與除錯#

閱讀程式碼的方法#

學習新語言或新實作的方式：取一份優秀程式設計師寫的程式來閱讀
通常先了解解決方案的結構，然後從中間開始，尋找核心部分（kernel piece）
這是學習演算法和語言優雅用法的絕佳途徑

除錯故事#

MAD 系統的深夜電話：

機器操作員半夜來電，一個程式無法執行
系統有自動校驗和（checksumming）機制來確保資料正確性
Allen 在電話中突然意識到自己寫的校驗和程式碼沒有處理某個特殊情況
即使程式正確也無法通過校驗關卡

Stretch 的「那個 bit 為什麼被設定了？」：

一個喜歡通宵工作的同事丟了一份厚重的除錯輸出到她桌上
指著一個特定的 bit 問為什麼它被設定了
Allen 立刻知道原因——那不是 bug，只是他不認識的某個設定
他整晚都在假設那是錯誤的根源

對程式語言的看法#

對 C 語言的強烈批評#

Allen 認為 C 語言嚴重損害了電腦科學的發展
C 出現時，她的團隊正在最佳化和程式變換方面取得很好的進展
C 的設計動機是解決高階語言無法處理的三個問題：中斷處理、資源排程、記憶體分配

Allen 的觀點：到 1960 年，我們已有一長串優秀的語言——Lisp、APL、Fortran、COBOL、Algol 60——這些都比 C 更高階。自 C 發展以來，我們嚴重倒退了。C 破壞了我們在自動最佳化、自動平行化、高階語言到機器的自動映射方面的進步能力。 這也是為何編譯器在大學裡幾乎不再被教授的原因之一。

若 C 僅限於作業系統核心使用，她認為是合理的
但像 C 這類語言完全過度指定（overspecify）問題的解法，正在摧毀電腦科學作為一門學科
即使 Java、Python 等較新語言比 C 高階，Allen 認為它們仍然過度指定了資料的位置

對高效能運算的展望#

多核心時代的效能提升需要軟體層面的突破
需要更高階的語言層級來駕馭多核心
資料管理和計算的局部性（locality）是尚未解決的核心問題
應該「將資料帶到計算元件」而非現在的「以參考方式存取資料」

軟體工程與團隊管理#

設計方法#

Allen 總是喜歡先有一個圖像——一個模型
常用流程圖和介面規格來思考系統各部分如何互動
在無法頻繁存取機器的年代，流程圖是思考和規劃的重要工具
有時是正式的流程圖，有時只是在黑板上非正式地解決問題

程式碼審查的價值#

在 PTRAN 專案後期，每週五下午花半天做程式碼審查
逐一解釋程式碼中的錯誤，持續了約十個月
過程痛苦但絕對值得

團隊所有權與協作#

採用協作式工作，但每個人擁有特定的程式碼區塊
理論研究者被鼓勵將理論轉化為程式碼
純實作者則被鼓勵將成果寫成論文
理論與實踐的結合是團隊強大的關鍵

管理風格#

在 IBM Research 早期，管理不是升遷或加薪，只是技術管理的角色
她被送去上管理學校，但認為管理能力部分源於在農場長大、身為六個孩子中的老大
管理的重要教訓：對新想法保持開放——曾經拒絕團隊使用 hashing 的提議，結果他們週末自行改造系統，效能大幅提升

招聘與人才觀#

面試方法#

面試時首先尋找的是對事物的熱情
不在乎熱情的對象是否與程式設計或電腦有關
如果一個人無法對任何事物產生熱情，他們就不適合這個團隊

什麼區分最優秀的程式設計師#

能夠讓她「靈光一閃」的人——帶來新的、有趣的思維方式
她花很多時間思考系統，所以喜歡能展示新觀點或新解法的人
也依賴他人的判斷——當發現自己對某人的評價高於團隊共識時，那通常是一次學習經驗

給年輕程式設計師的建議#

不要急著跳入管理層
先建立技術聲譽——無論是一篇好論文、一個演算法、還是出色的程式碼
建立了堅實的技術基礎後，再轉向管理會更得心應手

自我認同與職業思考#

科學家、工程師還是藝術家？#

自認為是電腦科學家
參與了電腦科學作為學科的萌芽發展
對「任何名稱中有 science 的東西到底算不算科學？」這個問題有切身感受
編譯器是非常古老的領域——比作業系統還老

從程式設計師到理論家的轉變#

坦言自己不是非常好的程式設計師——容易犯錯，對細節不太注意
對系統如何運作更感興趣，而非把所有細節做對
如果有足夠的錢讀博士，會選擇成為幾何學家
在 PTRAN 專案中的技術貢獻是架構層面的：掌握整體系統如何運作的宏觀圖像
認為這種能力部分來自在農場長大的經歷——農場是一個由輸入和輸出組成的大系統

女性在計算領域的變遷#

早期的開放環境#

1959 年左右，女性在程式設計領域扮演重要角色
IBM 自 1899 年起就有非常明確的多元化政策
Stretch 編譯器四位主要負責人中三位是女性
並非因為「我們必須僱用更多女性」的政策，而是他們僱用了合格的人
IBM 在種族問題上也立場鮮明——在 Poughkeepsie 住房仍隔離的年代推動了改變

性別認同的挑戰#

以 F.E. Allen 的名字發表論文（使用名字縮寫在當時很常見）
在一次 IBM 內部會議上，組織者按字母排列住宿，發現 “Fran Allen” 是女性後給了她閣樓裡的女傭房間

轉變的根源#

1960-1970 年間，電腦科學從工程學院中獨立出來
工程學院幾乎全是男性，IBM 開始要求新進人員具備特定學歷和課程
符合條件者幾乎全是男性
同時，程式設計從「最新的軟性領域」變成一種「專業」，管理流程增加

Allen 的觀察：早期軟體被視為「最新的東西」，也被認為是科學中較「軟」的部分。女性在 ENIAC 和 Bletchley Park 上就是程式設計師——「computer」這個詞就是她們的稱號。但在工程和物理等「較硬」的傳統科學中，女性並不多。

多元化的重要性#

目前計算機科學中女性比例約 8%，是所有領域中最低的
計算是改變社會的領域，沒有多元群體的參與，成果不會對社會所有方面都有用
即使是高度技術性的工作（如編譯器最佳化），多元背景的團隊也更強大
PTRAN 團隊的成功部分歸因於成員來自不同學校、不同文化背景的多元組合

教育問題#

需要在初中階段改變數學教育——許多女孩在那個階段放棄數學和科學
家長和社會的態度會大幅影響孩子的選擇
Allen 成長於農場，母親就是農場的合夥人，所以她自然認為自己可以做任何事
對「50/50 by 2020」目標感到相當沮喪

Turing Award 與職業反思#

獲獎感受#

得知獲獎時首先想到的是那些從未被認可的女性同事
很多女性的工作被竊取——在許多案例中，研究成果被歸功於他人
提到 Edith Schonberg 是傑出的電腦科學家，寫了一篇關於平行程式碼除錯的論文，被拒絕後卻被審查委員會的人發表了三篇衍生論文
Allen 感覺獲獎是遲到了——40 年中有 50 位男性得獎而沒有女性，這對社群是一種尷尬

在 IBM Research 的整體職業#

認為在 IBM Research 工作是她人生中最幸運的事之一
IBM Research 坐落在產業和學術之間——她將其比喻為一面石牆，站在上面可以向兩邊看
NSF 的一份報告顯示，多個數十億美元的產業（圖形學、網際網路、高效能運算、電晶體）都是學術界和產業界共同貢獻的成果
智慧財產權是阻礙學術界和產業界合作的最大問題之一

對自己職業的總結#

用一個詞概括自己的職業和做事方式：「探索」（exploring）
喜歡探索想法、專案、甚至人的邊緣
但有個反面：她是個「開創者而非完成者」——被新事物吸引
編譯器領域很適合她，因為電腦不斷帶來新挑戰，需要解決的問題也越來越有挑戰性

電腦科學領域的吸引力#

每天都有新想法的潛力——看到什麼新東西就會說「噢，那是新的」
整個領域非常頻繁地被刷新
Isaac Asimov 曾說電腦會讓每個人更有創意——計算將開啟創意的時代
Allen 認為我們需要給這個領域一個更人性化的身份，讓更多人覺得它有吸引力
需要清楚表達：我們為什麼喜歡這個領域、什麼讓人興奮、為什麼它是一個好領域

重要觀點總結#

關於程式之美#

「美的程式是對問題的簡單直接的解決方案；它具有某種內在結構和明顯性，而這些並非從問題本身顯而易見。」

關於理論與實踐#

強烈主張理論與實踐必須結合在同一個專案中
理論者應將想法實作為程式碼，實作者應將成果寫成論文
這種結合是她認為自己領域最有效的工作方式

關於軟體工程流程#

認同 Brooks 的「先建一個然後丟掉」的觀點
但批評這導致了很多人在開始建造之前完全不思考
「先建一個」不等於「不用思考就開始寫」

關於計算的未來#

過去 50-60 年建立了驚人的遺產，但也留下了需要消除的人為產物
多核心是回頭重新審視許多事物的絕佳機會
需要全新的思維來駕馭多核心——不能只是在現有架構上堆疊層次
資料的正確性和完整性將變得越來越重要

關於女性在科技領域的經驗#

「在 ENIAC 和 Bletchley Park 上，女性就是程式設計師——‘computer’ 這個詞就是她們的稱號。」

早期程式設計被視為「軟性」學科，女性自然參與
當它變成「專業」並從工程學院獨立出來後，女性被制度性地排除在外
多元化不只是政治正確——它讓團隊更強大、產出更好