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

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

首页枪战射击代号深空游戏更新时间:2024-05-03

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

查看全文
大家还看了
也许喜欢
更多游戏

Copyright © 2024 妖气游戏网 www.17u1u.com All Rights Reserved