Grace Hopper 如何讓程式更接近人類語言？Mark I、A-0、FLOW-MATIC 與 COBOL

Grace Hopper 如何讓程式更接近人類語言？Mark I、A-0、FLOW-MATIC 與 COBOL

讀者問題與人物定位

Grace Hopper 常被簡化成「發明編譯器的人」或「發明 COBOL 的人」，但這兩個句子都把長期合作的技術鏈壓扁了。更好的問題是：一組原本以數字代碼表達的指令，如何被翻譯、連結、執行和維護，最後變成商業機構願意採用的語言？Hopper 的貢獻在於她持續把機器可執行性、程式設計者的工作流程和組織標準放在同一張設計圖上。

她在二戰末期加入 Harvard Mark I 團隊，之後又在 Mark II、Mark III 等大型機器上工作。這些機器以繼電器、延遲線和穿孔介質處理計算，除錯成本遠高於今日在編輯器裡重跑一個測試。Hopper 從這種環境看到，若每一個程序都要由專家手工翻成位置和代碼，機器越快，人的溝通瓶頸反而越嚴重。

「更接近人類語言」不是要讓電腦理解自然語言的所有歧義，而是讓資料處理規則使用穩定、可分析的詞彙。Hopper 的方法是建立編譯器和中間表示，讓人以較高層次的符號描述工作，再由工具產生低階操作。這個轉變涉及語法、符號表、記憶體位置、錯誤診斷與執行效能，並非替換幾個英文單字那麼簡單。

本文也會把個人、團隊和標準組織分開記錄。Hopper 提出早期工具、推動 FLOW-MATIC 並參與 CODASYL 的語言協調；其他工程師設計硬體、實作編譯器、整理規格和建立 COBOL 編譯器。只有把這些角色標出來，讀者才能理解她為何重要，同時避免「單人發明整個商業語言」的常見誤讀。

技術如何運作：從 Mark 機器到編譯器

Mark I 的程式輸入以紙帶和指令序列呈現，操作人員必須把計算步驟與記憶體位置安排好。這種格式適合固定任務，卻讓程式本身與硬體佈局緊密耦合。當一個欄位搬到另一個位置，相關指令、計時和紙帶段落都可能要重新檢查。Hopper 在這裡看到的不是「人不夠聰明」，而是表示層次太靠近機器細節。

A-0 的核心觀念是把一串較可讀的算術敘述轉成機器可以執行的操作。編譯器先讀取符號和運算關係，再建立中間的指令結構，最後輸出適合目標機器的碼。當資料名稱、運算子和儲存位置由表格管理時，程式設計師可以重用轉換規則，而不必為每個新算式手動計算所有地址。

早期編譯器的「符號表」是不可缺的基礎。它把一個名稱對應到儲存區域、資料型別或常數，並在後續指令生成時查回位置。若同一名稱被重複宣告、拼字不一致或超出機器容量，編譯器可以在執行前報錯。這種把錯誤提早發現的能力，後來成為所有語言工具鏈中最有價值的生產力來源之一。

B-0 與 FLOW-MATIC 延續了這種分層思路，但把焦點移到商業資料處理。程式可以用接近英文的動詞描述讀取檔案、尋找記錄、比較欄位、列印報表和搬移資料。接近英文並不等於模糊；真正關鍵是每個句型都有明確的語法與對應操作，讓編譯器能判斷順序、欄位和輸出格式。

商業程式的主要困難不是單一加法，而是檔案布局和資料品質。FLOW-MATIC 讓設計者以記錄、欄位和檔案名稱思考，編譯器再把這些概念連到磁帶或記憶體操作。若輸入記錄缺少欄位、資料型別不符或排序條件不完整，工具必須給出可定位的診斷；否則自然語言式語句只會把錯誤藏得更深。

把 A-0 想成今日的完整最佳化編譯器也不準確。早期系統的語法範圍、記憶體容量和執行速度都很有限，編譯器可能以單趟方式處理輸入，再把結果交給載入或連結階段。它的歷史意義在於建立了「程式是可翻譯的資料」這個工作模型，而不是已經具備現代編譯器的所有最佳化技術。

原始論文、程式、標準與專案脈絡

海軍史料記錄 Hopper 在 Mark 機器上的工作，也記錄她發表早期編譯器論文並持續研究程式語言。論文的價值不只在提出名稱，而在把編譯過程拆成可以討論的階段：讀入符號、分析算式、配置儲存、產生指令和處理錯誤。對後來的工程師而言，這種分解提供了實作和測試的邊界。

Computer History Museum 保存的口述史能補足程式名詞背後的工作流程。A-0 被描述為早期單趟編譯器，代表它在有限資源下以一次掃描完成主要轉換。這種限制迫使設計者先決定符號如何宣告、資料如何向前傳遞，以及遇到尚未知道的地址時如何留下可回填的記錄，與今日多趟編譯器的中間表示有清楚的歷史連續性。

FLOW-MATIC 的重要處不在「英文看起來漂亮」，而在把商業作業的語義固定成可執行句型。當語句描述某個檔案、某個欄位和某個條件時，團隊可以共同檢查規格與程式是否一致。這讓非專職程式員能參與需求討論，也讓編譯器成為組織流程的一部分，而不只是個人使用的翻譯器。

COBOL 的形成則是委員會與標準化的故事。Hopper 參與 CODASYL，對語言方向、可讀性和資料處理需求有重要影響，但規格由多位專家協商，後來還經過政府、供應商和使用者的採用與修訂。把她寫成唯一作者會忽略標準必須在不同硬體、編譯器和機構間取得共同承諾的工程現實。

從專案管理角度看，A-0、B-0、FLOW-MATIC 和 COBOL 是演進與影響關係，不是一條由單人一次完成的直線。前一個工具提供經驗，下一個語言調整語法和資料模型，標準組織再把可行的部分整理成跨公司規格。研究一項技術時，應分別標示原型、部署版本、標準文件和後續實作，避免把名稱相近的階段混成同一件事。

現代開發與今日影響

現代編譯器仍沿用 Hopper 時代確立的分層：詞法分析把文字切成符號，語法分析建立結構，語義分析檢查型別與名稱，接著生成中間表示，再做最佳化與目標碼輸出。差別在於今日工具能處理更複雜的模組、泛型、並行和硬體。理解早期編譯器，能讓開發者知道每一層為何存在，而不是把錯誤訊息當成黑箱。

FLOW-MATIC 的資料處理取向也出現在今日的 SQL、ETL 管線和領域專用語言。使用者以表格、欄位、篩選和聚合描述目的，執行引擎再決定掃描、索引或分散式計算的細節。這種高階語言仍需要精確的型別、空值規則和交易語義；若只追求像英文，卻沒有可驗證的操作定義，系統就會在邊界案例出現難以追蹤的差異。

錯誤診斷是「接近人類語言」真正能否落地的試金石。好的編譯器指出檔名、行號、預期的資料型別和修正方向，讓使用者能在一次回饋中定位問題。團隊還可以把編譯警告當成品質閘門，在持續整合中阻止未處理欄位、未初始化值和格式不相容進入生產。這是 Hopper 追求可用工具而不只追求理論的現代延伸。

大型企業仍維護 COBOL 系統，並不代表語言沒有演進，而是資料格式、批次流程和監管紀錄具有長期價值。現代化工作通常先用編譯器和測試建立行為基準，再以 API、訊息佇列或新的服務逐步包裝既有程式。若沒有清楚區分原始規格、實際執行結果和新介面承諾，搬遷只會把隱含規則帶到另一個平台。

Hopper 倡議標準化的另一個影響是可攜性思維。當語言規格、資料交換格式和編譯器行為有共同基準，組織可以替換硬體或供應商而不必重寫全部業務邏輯。今日的開放標準、測試相容性套件和語言版本規範，都延續了「先寫清楚共同契約，再讓多個實作者競爭」的治理方法。

爭議、限制與常見誤讀

稱 Hopper 為「編譯器之母」是易懂的公共敘事，卻不應被當成完整技術史。編譯器概念在她之前已有研究，許多同事負責實作、測試與維護，其他團隊也提出不同的翻譯方法。精確的寫法應指出她推動早期工具、論述編譯器和倡議語言標準化的角色，並把具體專案與合作人員放回來源。

把 COBOL 說成 Hopper 單人發明同樣有問題。COBOL 是為了跨機構的商業資料處理而協調的語言，設計者、政府使用者、供應商和標準委員會都影響了最後規格。Hopper 的影響很深，但影響力與唯一作者身分不是同義詞；在技術寫作裡，這個區分直接關係到誰的工作被看見。

「自然語言程式」也不是完全不需要程式員。FLOW-MATIC 的詞句仍有嚴格語法，檔案、欄位、排序和例外條件必須明確指定。自然語言中的上下文、省略和多義詞不能直接交給早期編譯器處理。它降低的是符號記憶和機器地址的負擔，不是消除規格、驗證和除錯。

早期硬體的限制會影響我們對速度和規模的判斷。Mark 機器的輸入輸出、記憶體和操作時間都遠非今日伺服器可比，編譯器設計常以單趟處理和簡化資料結構換取可行性。不能拿現代最佳化器的功能清單倒推 A-0，也不能因為早期程式短就推論問題簡單；真正的難題是讓每一個低階狀態都可靠。

最後，Hopper 的軍方身分和個人故事常被用來製造傳奇，但史料應優先回答技術主張。本文使用原始機構與口述史資料來界定 Mark 工作、A-0、FLOW-MATIC 和 CODASYL 的範圍；未有來源的趣聞不應被當成編譯器機制的證據。把可查證的規格、程式流程和合作脈絡放在中心，才是對她工程遺產的尊重。

編譯器還改變了團隊的審查方式。當高階句子先被轉成一份可讀的中間清單，審查者可以在硬體執行前檢查欄位、分支和輸出；若要追蹤生產事故，也能從原始句子回到生成指令。這個可追溯鏈條讓程式不再只是一卷無法解釋的紙帶，而成為可以交接、版本化和回歸測試的工程資產。

在今日的編譯器實作中，單趟與多趟不是只有速度差異，還關係到錯誤回饋和語義完整性。單趟處理適合受限輸入，遇到後置宣告或需要全域資訊時便必須留下暫存；多趟處理可以先建完整符號表，再在後續階段解析依賴。把這些選擇講清楚，能讓讀者理解 A-0 的限制是資源與設計取捨，而不是落後的粗糙版本。

標準化也要求測試資料不能只來自一家公司。不同機器、字元集和檔案長度都可能改變一段商業程式的結果，因此委員會需要共同範例、相容性檢查和版本記錄。Hopper 所推動的語言觀把這些跨組織協議視為技術本體的一部分，提醒現代開發者：可攜性不是宣稱出來的，必須以明確規格與可重現測試證明。

若想延伸理解程式語言與工具如何形成可讀、可驗證的工程方法，可參考Donald Knuth 對演算法、編譯器與可讀程式的整理。

官方資料與延伸查證

• https://president.yale.edu/biography-grace-murray-hopper
• https://www.computerhistory.org/revolution/early-computer-companies/5/117
• https://computerhistory.org/collections/catalog/102702026

若要從 Grace Hopper 讓程式語言靠近人類語句的 FLOW-MATIC、A-0 與 COBOL 路線，延伸到 Jean E. Sammet 如何以 FORMAC 與 COBOL 把公式、編譯器與商業程式接起來，可延伸閱讀 Jean E. Sammet 如何讓公式成為程式？FORMAC、COBOL 與語言史，補上同一實體脈絡的延伸閱讀。

資料來源與延伸閱讀

• Yale University: Grace Murray Hopper biography
• Computer History Museum: early computer companies and Grace Hopper
• Computer History Museum oral history: Grace Hopper interview (PDF)

以下圖片取自 Computer History Museum 官方 Grace Murray Hopper 人物頁，補充本文對 Mark I、A-0、FLOW-MATIC 與 COBOL 的分析；照片是博物館人物資料，不把它當成早期電腦硬體的示意圖。

增量：讓程式接近人類語言，也要讓編譯與責任可追蹤

Grace Hopper 的路線可以再用「表達—翻譯—治理」三個介面來讀。高階語言降低人類表達計算的門檻，編譯器把語句轉成機器能執行的形式，而標準與文件則讓不同團隊知道同一段程式在什麼條件下成立。語言越接近自然語言，越需要明確定義型別、資料格式、錯誤處理與可追溯性。

• 表達：問題能否用領域使用者理解的概念描述。
• 翻譯：編譯器如何檢查、最佳化並產生可執行結果。
• 相容：不同實作、版本與平台是否保有可預期行為。
• 責任：錯誤、資料品質與運算結果能否回溯到流程。

因此，FLOW-MATIC 與 COBOL 的歷史不只是在追求「更像英文」，而是在建立讓商業與行政程式可以被更多人維護、交接與審查的組織介面。