一个发誓不用Java的程序员，不得不在太空中调试Lisp

Posted 2022-09-16 程序员的店小二

1998年10月24日，伴随着火箭的轰鸣，美国宇航局的深空一号成功升空。

深空一号肩负着NASA的重要使命，旨在验证未来行星际探测所需的十几项新技术。

在深空一号飞行了2.4亿公里以后，突然发生了一个故障，有个进程不工作了。

地面人员非常紧张，赶紧召来软件团队商量对策。

软件团队在会议绞尽脑汁，激烈争论，最后决定对深空一号的软件进行调试。

调试？到底该怎么调试？

软件可不是部署在某个机房里，而是位于距离地球2.4亿公里的航天器中，距离之远即使是光也需要半个小时才能跑个来回。

但是NASA的工程师们却成功地解决了这个问题，原因就是深空一号上的控制软件是用Lisp写的！

1

要想了解整个事情的来龙去脉，必须把时间拉得长一些。

1988年，罗恩来到NASA的JPL（喷气推进实验室，钱学森是创始人之一），在自主机器人的人工智能组工作。

JPL当时制定了一个火星探测的计划，希望能到达火星，并且采样返回。

任务庞大而艰巨，预算有数十亿美元，罗恩他们要做的是火星车原型的研制。

这些原型有大有小，有重达一吨，像SUV的Robby ：

也有小巧玲珑，像个玩具车的Tooth：

为了让火星车能自主避障，在火星漫游，必须要给它配套一个强大的软件，让它具备一个强大的大脑。

用什么编程语言呢？

在80年代，没有Java， 没有Python，没有javascript，航天器主要是用汇编编写的。

而罗恩他们决定尝试一个新语言：Lisp。

Lisp在当时是人工智能的编程语言，正好和火星车的任务匹配，并且也不用管理C语言的指针，还支持垃圾回收。

不过当时的NASA对Lisp持怀疑的态度，很多人觉得Lisp很奇怪，担心Lisp那奇怪的垃圾回收技术会突然让应用进程死掉。

但是罗恩认为：“当你使用的语言提供一种高级的抽象时，完成工作会变得更快更容易。” 

罗恩他们先使用Lisp针对手头的问题定义一个自定义语言，相当于DSL，然后为火星车的硬件进行编译，这种方式对于内存受限的硬件非常有用。

在把代码安装到火星车上进行测试之前，罗恩的小组还在Macintosh 电脑上写了一个模拟器，把代码做了非常充分的测试。

罗恩的小组不但能写火星车的漫游和避障程序，还能写底层的编译器和模拟器，可见技术能力还是非常强的。

虽然Lisp火星车进展顺利，可以使用立体视觉传感器在户外自主导航，在崎岖地形环境下漫游，但是罗恩他们并不是唯一一组火星车原型制造者，他们还有竞争对手。

罗恩回忆说：NASA内部也存在山头，也有政治斗争，Lisp火星车不幸成为牺牲品，最后团队解散，很多成员离开了。

1997年，第一个火星车Sojourner到达火星，这时候，驱动它的是C语言。

2

幸运的是，NASA换了一个领导，发起了一个叫做新千年的计划，其中一个任务就是深空探测。

深空一号计划飞过一个小行星和彗星。

它需要一个自主航天器控制系统，叫做远程代理（Remote Agent）。

C++派和Lisp派展开了一场斗争，这一次最终Lisp获胜。

罗恩他们故伎重演，再次使用Lisp 定制了一个领域专有语言，这个语言的结构会阻止你编写某些有问题的代码，例如竞争条件。

代码在深空一号的备份上做了一遍又一遍的测试，罗恩他们对软件非常有信心，认为绝对不会出错。

但是世界上哪有绝对的事情？

越是你觉得不会出错的地方，偏偏就在那里出错。

Lisp代码被部署到了生产环境：深空一号航天器

深空一号向一颗小行星飞去，这一去就是2.4亿公里。

就在这时，深空一号发生了故障，它并没有完成一件应该做的事情。

罗恩他们必须对深空一号上的Lisp软件进行调试，这个调试并不是在一个机房的服务器上，代码运行的地方在2.4亿公里以外，即使是光也需要半个小时才能跑一个来回！

幸亏深空一号运行的是Lisp，它支持REPL（read–eval–print loop）这样功能，可以输入一个命令，然后查看结果。

一群人坐在会议中，绞尽脑汁，讨论发送什么命令来调试。

当然，每一条调试命令都需要层层审批，让所有人签字，然后由接受过培训的操作员在深空网络控制台前输入命令，按下红色按钮，信号会通过一个巨大的70米的天线发送出去，以光速奔向深空一号。

罗恩他们要做的第一件事是看看系统的转储信息，看看当前活动进程的列表，他们向深空一号发了一个S表达式。

数据传输回来以后，大家立刻就发现了问题：有个进程在等待一个已经发生了的事件。

这本来是不可能发生的，主要是因为有个程序调用了底层的Lisp函数导致的。

团队决定手工触发这个事件，这就可以让那个进程继续执行了。

感谢 LISP 的魔力，感谢在深空一号飞船上安装实时 REPL 的惊人想法，他们成功地挽救了这项任务。

3

在2.4亿公里以外调试代码，修复问题确实让人印象深刻，但是NASA并没有拥抱Lisp。

NASA当时有个响亮的口号“更好，更快，更省”，其实这更像一个不可能三角形。

在这样的思想指引下，深空探测项目经费很少，时间又很紧张。所以当出现进度延期和预算超支时，Lisp成了替罪羊。 

关键的转折点是一个有着200人参加的重大审查，包括很多JPL的高级管理人员，当软件集成工程师在做演示时，

有人问他：如果可以改变一件事情，可以让事情变得更好，这件事情是什么？

这个工程师回答：去掉Lisp。

这几乎就宣布了Lisp在JPL的死刑。

罗恩非常沮丧，他在JPL被边缘化，希望和他合作的人越来越少。

这时候，他发现一家叫做Google的网站，这个网站的搜索结果好得不可思议，速度快得吓人，罗恩很快找到了招聘链接，投递了简历。

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

4

罗恩一直觉得在软件业，管理层一直在寻找一种开发流程，让程序员变成可以插拔的、可以替换的组件，这实在是太吓人了。

而Java恰好匹配了管理层的这种需求，所以他发誓永远不会成为一名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

https://www.youtube.com/watch?v=_gZK0tW8EhQ

本文来自微信公众号“码农翻身”