1998年10月24日，伴隨著火箭的轟鳴，美國宇航局的深空一號成功升空。

深空一號肩負著NASA的重要使命，旨在驗證未來行星際探測所需的十幾項新技術。

在深空一號飛行了2.4億公里以后，突然發(fā)生了一個故障，有個進程不工作了。

地面人員非常緊張，趕緊召來軟件團隊商量對策。

軟件團隊在會議絞盡腦汁，激烈爭論，最后決定對深空一號的軟件進行調試。

調試？到底該怎么調試？

軟件可不是部署在某個機房里，而是位于距離地球2.4億公里的航天器中，距離之遠即使是光也需要半個小時才能跑個來回。

但是NASA的工程師們卻成功地解決了這個問題，原因就是深空一號上的控制軟件是用Lisp寫的！

1

要想了解整個事情的來龍去脈，必須把時間拉得長一些。

1988年，羅恩來到NASA的JPL（噴氣推進實驗室，錢學森是創(chuàng)始人之一），在自主機器人的人工智能組工作。

JPL當時制定了一個火星探測的計劃，希望能到達火星，并且采樣返回。

任務龐大而艱巨，預算有數十億美元，羅恩他們要做的是火星車原型的研制。

這些原型有大有小，有重達一噸，像SUV的Robby ：

也有小巧玲瓏，像個玩具車的Tooth：

為了讓火星車能自主避障，在火星漫游，必須要給它配套一個強大的軟件，讓它具備一個強大的大腦。

用什么編程語言呢？

在80年代，沒有Java， 沒有Python，沒有JavaScript，航天器主要是用匯編編寫的。

而羅恩他們決定嘗試一個新語言：Lisp。

Lisp在當時是人工智能的編程語言，正好和火星車的任務匹配，并且也不用管理C語言的指針，還支持垃圾回收。

不過當時的NASA對Lisp持懷疑的態(tài)度，很多人覺得Lisp很奇怪，擔心Lisp那奇怪的垃圾回收技術會突然讓應用進程死掉。

但是羅恩認為：“當你使用的語言提供一種高級的抽象時，完成工作會變得更快更容易?！?/p>

羅恩他們先使用Lisp針對手頭的問題定義一個自定義語言，相當于DSL，然后為火星車的硬件進行編譯，這種方式對于內存受限的硬件非常有用。

在把代碼安裝到火星車上進行測試之前，羅恩的小組還在Macintosh 電腦上寫了一個模擬器，把代碼做了非常充分的測試。

羅恩的小組不但能寫火星車的漫游和避障程序，還能寫底層的編譯器和模擬器，可見技術能力還是非常強的。

雖然Lisp火星車進展順利，可以使用立體視覺傳感器在戶外自主導航，在崎嶇地形環(huán)境下漫游，但是羅恩他們并不是唯一一組火星車原型制造者，他們還有競爭對手。

羅恩回憶說：NASA內部也存在山頭，也有政治斗爭，Lisp火星車不幸成為犧牲品，最后團隊解散，很多成員離開了。

1997年，第一個火星車Sojourner到達火星，這時候，驅動它的是C語言。

2

幸運的是，NASA換了一個領導，發(fā)起了一個叫做新千年的計劃，其中一個任務就是深空探測。

深空一號計劃飛過一個小行星和彗星。

它需要一個自主航天器控制系統，叫做遠程代理（Remote Agent）。

C++派和Lisp派展開了一場斗爭，這一次最終Lisp獲勝。

羅恩他們故伎重演，再次使用Lisp 定制了一個領域專有語言，這個語言的結構會阻止你編寫某些有問題的代碼，例如競爭條件。

代碼在深空一號的備份上做了一遍又一遍的測試，羅恩他們對軟件非常有信心，認為絕對不會出錯。

但是世界上哪有絕對的事情？

越是你覺得不會出錯的地方，偏偏就在那里出錯。

Lisp代碼被部署到了生產環(huán)境：深空一號航天器

深空一號向一顆小行星飛去，這一去就是2.4億公里。

就在這時，深空一號發(fā)生了故障，它并沒有完成一件應該做的事情。

羅恩他們必須對深空一號上的Lisp軟件進行調試，這個調試并不是在一個機房的服務器上，代碼運行的地方在2.4億公里以外，即使是光也需要半個小時才能跑一個來回！

幸虧深空一號運行的是Lisp，它支持REPL（read–eval–print loop）這樣功能，可以輸入一個命令，然后查看結果。

一群人坐在會議中，絞盡腦汁，討論發(fā)送什么命令來調試。

當然，每一條調試命令都需要層層審批，讓所有人簽字，然后由接受過培訓的操作員在深空網絡控制臺前輸入命令，按下紅色按鈕，信號會通過一個巨大的70米的天線發(fā)送出去，以光速奔向深空一號。

羅恩他們要做的第一件事是看看系統的轉儲信息，看看當前活動進程的列表，他們向深空一號發(fā)了一個S表達式。

數據傳輸回來以后，大家立刻就發(fā)現了問題：有個進程在等待一個已經發(fā)生了的事件。

這本來是不可能發(fā)生的，主要是因為有個程序調用了底層的Lisp函數導致的。

團隊決定手工觸發(fā)這個事件，這就可以讓那個進程繼續(xù)執(zhí)行了。

感謝 LISP 的魔力，感謝在深空一號飛船上安裝實時 REPL 的驚人想法，他們成功地挽救了這項任務。

3

在2.4億公里以外調試代碼，修復問題確實讓人印象深刻，但是NASA并沒有擁抱Lisp。

NASA當時有個響亮的口號“更好，更快，更省”，其實這更像一個不可能三角形。

在這樣的思想指引下，深空探測項目經費很少，時間又很緊張。所以當出現進度延期和預算超支時，Lisp成了替罪羊。

關鍵的轉折點是一個有著200人參加的重大審查，包括很多JPL的高級管理人員，當軟件集成工程師在做演示時，有人問他：如果可以改變一件事情，可以讓事情變得更好，這件事情是什么？

這個工程師回答：去掉Lisp。

這幾乎就宣布了Lisp在JPL的死刑。

羅恩非常沮喪，他在JPL被邊緣化，希望和他合作的人越來越少。

這時候，他發(fā)現一家叫做Google的網站，這個網站的搜索結果好得不可思議，速度快得嚇人，羅恩很快找到了招聘鏈接，投遞了簡歷。

2000年，羅恩在JPL工作了12年以后，加入了正在冉冉升起的明星公司Google。

4

羅恩一直覺得在軟件業(yè)，管理層一直在尋找一種開發(fā)流程，讓程序員變成可以插拔的、可以替換的組件，這實在是太嚇人了。

而Java恰好匹配了管理層的這種需求，所以他發(fā)誓永遠不會成為一名Java程序員，在90年代后期，這個決定讓90%以上的工作對他關閉了大門。

羅恩選擇Google的一個重要原因就是他們不使用Java，但是，他在Google的第一項工作就是：

領導公司的第一個Java項目！

這個項目最終變成了Google AdWords。

羅恩很懷念Lisp，他有過在JPL推銷Lisp的經驗，于是他故伎重演，先在團隊做了Lisp演示，成功地捕獲了程序員的芳心，大家一致認為使用Lisp是個好主意，接下來只需要說服工程副總即可。

羅恩信心滿滿地去找副總。

羅恩：有件事我想和你談談…

副總：讓我猜猜，你想用Smalltalk ?

羅恩：呃，不….

副總：Lisp?

羅恩：是的！

副總：不可能！

羅恩：…

參考資料：

https://corecursive.com/lisp-in-space-with-ron-garret/

https://flownet.com/gat/jpl-lisp.html