太空中的 Lisp：自主太空船控制的高低起伏

太空探索的歷史常常以硬體為視角來敘述——火箭、登陸器與探測車。然而，掌控這些機器的軟體才是最激烈的技術與政治戰場之一。其中一個故事是嘗試將 Lisp（以彈性與高階抽象聞名的語言）整合到 NASA 噴射推進實驗室（JPL）的關鍵任務系統中。

這是關於機器人與 AI 研究員 Ron Garrett 的故事，他致力於推動太空自主性的界限，並奮鬥於實作一種與當時制度文化根本對立的程式設計範式。

火星自主探索的追求

1988 年，操作火星探測車的挑戰被一個殘酷的限制所定義：40 分鐘的往返光訊延遲。這種延遲意味著即時遠端操作不可能；當操作員看到探測車路徑上的岩石並發送轉向指令時，探測車可能已經撞上去。

為了解決這個問題，Garrett 與他的團隊專注於提升自主等級。目標是讓探測車只需給予目的地，便能自行規劃前往的路徑。此工作在一系列原型機上進行，包括：

雖然 NASA 大多數軟體是以 C、Pascal 或 Basic 撰寫，Garrett 的團隊卻利用 Lisp。於 1980 年代末、Python 或 Java 尚未出現之時，Lisp 提供了高階抽象，使研究人員能快速迭代。

Garrett 將此方法描述為將每個問題都轉化為編譯器問題。對於記憶體受限的小型機器人，團隊會使用 Lisp 設計專屬於機器人的自訂語言，然後編譯成嵌入式程式碼。對於較大型的機器人，Lisp 直接在硬體上執行。

然而，此選擇遭遇了巨大的阻力。NASA 當時的普遍觀念對 Lisp 持懷疑態度，因為其垃圾回收機制可能會意外暫停程序，且記憶體消耗高。在即時回應至關重要的嵌入式環境中，這些被視為災難性的風險。

技術分歧常常掩蓋更深層的政治衝突。在 JPL，Garrett 的研究導向小組與較傳統的作業小組之間爆發了領域之爭。

傳統方法依賴「低自主」——操作員描述探測車必須遵循的精確路徑。雖然此方式降低了機器人「失控」的風險，卻給人員帶來巨大的作業負擔。相對地，Garrett 的方法則是徹底將人類從迴路中移除。

Garrett 指出，這不僅是技術辯論，更是生計的衝突。那些職責依賴手動操作太空船的人員，天然不願支持一項旨在將他們工作自動化、甚至消除的技術。

雖然高自主性的 Lisp 方法未能應用於 Sojourner 探測車，但它在 NASA 的新千年計畫（New Millennium Program）中獲得了第二次機會。該計畫旨在展示可透過規模經濟降低任務成本的技術。

於是誕生了 Remote Agent，一個為 Deep Space 1（DS1）任務設計的自主飛行控制器。系統由多個元件組成，其中三個是以 Lisp 撰寫。Garrett 的具體貢獻是「執行層」（the executive），負責根據輸入資料與應變情況決定太空船每一瞬間的行動。

為確保可靠性，執行層使用一種自訂語言編寫，旨在防止常見的多執行緒問題，如競爭條件與死結。此語言的安全性得到形式正確性證明與在與飛行硬體相同的地面測試的廣泛驗證。

儘管有形式化的證明，Remote Agent 在為期三天的飛行實驗中失敗。當時太空船距離地球 150 百萬英里，停止了決策。

由於系統在太空船上搭載了 Lisp REPL（Read-Eval-Print Loop），團隊具備了獨特的能力：他們可以透過深空網路直接向機器傳送 S 表達式（Lisp 程式碼）。經過一連串艱苦的管理層批准與 70 公尺天線傳輸後，團隊請求系統狀態轉儲。

回溯顯示出競爭條件——正是該語言設計要防止的問題。失敗的原因是有開發者因無法使用語言的安全構造實作特定功能，於是呼叫了較低層的 Lisp 構造，繞過了安全保證。這個「不安全」的逃生口導致了死結。

透過 REPL，團隊成功手動注入事件以「解除卡住」系統，使任務得以完成目標。然而，此經驗留下了深遠的影響。自主性計畫隨即被取消，高階 Lisp 方法也被邊緣化。

回顧這段經驗，Garrett 認為 Lisp 之類工具的價值不在於其普遍的優越性，而在於它與使用者思維的「阻抗匹配」。對 Garrett 來說，Lisp 把程式碼視為資料的方式以及其強大的抽象正好契合他的需求，即使在 NASA 內部卻是格格不入。

最終，太空中的 Lisp 故事提醒我們，形式化證明的強度僅取決於其假設，而最先進的技術解決方案也可能因人為錯誤與組織政治的結合而偏離軌道。