代码在深空一号的备份上做了一遍又一遍的测试，罗恩他们对软件非常有信心，认为绝对不会出错。
但是世界上哪有绝对的事情？
越是你觉得不会出错的地方，偏偏就在那里出错。
Lisp代码被部署到了生产环境：深空一号航天器
深空一号向一颗小行星飞去，这一去就是2.4亿公里。
就在这时，深空一号发生了故障，它并没有完成一件应该做的事情。
罗恩他们必须对深空一号上的Lisp软件进行调试，这个调试并不是在一个机房的服务器上，代码运行的地方在2.4亿公里以外，即使是光也需要半个小时才能跑一个来回！
幸亏深空一号运行的是Lisp，它支持REPL（read–eval–print loop）这样功能，可以输入一个命令，然后查看结果。
一群人坐在会议中，绞尽脑汁，讨论发送什么命令来调试。
当然，每一条调试命令都需要层层审批，让所有人签字，然后由接受过培训的操作员在深空网络控制台前输入命令，按下红色按钮，信号会通过一个巨大的70米的天北海交友吧线发送出去，以光速奔向深空一号。
罗恩他们要做的第一件事是看看系统的转储信息，看看当前活动进程的列表，他们向深空一号发了一个S表达式。
数据传输回来以后，大家立刻就发现了问题：有个进程在等待一个已经发生了的事件。
这本来是不可能发生的，主要是因为有个程序调用了底层的Lisp函数导致的。
团队决定手工触发这个事件，这就可以让那个进程继续执行了。
感谢 LISP 的魔力，感谢在深空一号飞船上安装实时 REPL 的惊人想法，他们成功地挽救了这项任务。
3
在2.4亿公里以外调试代码，修复问题确实让人印象深刻，但是NASA并没有拥抱Lisp。
NASA当时有个响亮的口号“更好，更快，更省”，其实这更像一个不可能三角形。
在这样的思想指引下，深空探测项目经费很少，时间又很紧张。所以当出现进度延期和预算超支时，Lisp成了替罪羊。
