Lisping at JPL (2002)
20 comments
·May 22, 2025adityaathalye
Tells one of my all-time favourite stories.
> 1994-1999 - Remote Agent
> Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem. The story of the Remote Agent bug is an interesting one in and of itself.
tonyarkles
Not quite the same scale but one of my personal favourite stories involved hardware buried under a highway. The Ethernet stopped working, but the PoE was still ok. We had the foresight to install a serial line to the console on the equipment too. This meant that I could power cycle the hardware at will (through the managed PoE switch) and talk to the boot loader (U-boot) over serial. While not exactly a REPL in the conventional sense, it had enough functionality to be able to talk directly to the MAC and PHY to determine what was going on.
Sadly we couldn’t convince it to work, even at 10 Mbit. My suspicion is salt water ingress into the vault. What we did manage to do, though… There were just enough tools installed on it that I could cross-compile zmodem at home, convert it to a hex file, upload the hex file by essentially just running cat > on the target, convert it back into a binary using… Perl I think? Or xxd? And then doing the daily data offload over zmodem every night instead of over TCP as was originally planned. It was a crazy weekend…
jazzyjackson
Neat. I’m curious about long run serial as someone who’s only done arduino stuff at 5V, what does industrial serial talking over a miles long connection look like? Higher voltage? Repeaters?
potholereseller
Unfortunately, the relevant link in the TFA is dead, but IA has it: <https://web.archive.org/web/20111019054900/http://ti.arc.nas...>.
Here's some interesting quotes:
> during a task’s release of a lock, but before its actual release, the task may get interrupted by the daemon if the property gets broken. This means that the task terminates without releasing the lock. The error is particularly nasty in the sense that all code, except the lock releasing itself, had been protected against this situation: in case of an interrupt the lock releasing would be executed.
> The modeling effort, i.e. obtaining a PROMELA model from the LISP program, took about 12 man weeks during 6 calendar weeks, while the verification effort took about one week. ... The translation phase was non-trivial and time consuming due to the relative expressive power of LISP when compared with PROMELA.
> Java PathFinder (JPF) is a translator from a non-trivial subset of Java to PROMELA.
> The translator is written in 6000 lines of LISP, and was developed over a period of 8 months. JPF has been applied to a number of case studies, amongst them a 1500 line game server, a NASA file transfer protocol for satellites, and a NASA data transmission protocol for the space shuttle ground control.
adamgordonbell
Version with some pictures here:
https://corecursive.com/lisp-in-space-with-ron-garret/
It's an interview I did with Ron Garrett about the history of Lisp at the JPL.
hatmatrix
> At the time it was more or less taken for granted that AI work was done in Lisp. C++ barely existed. Perl was brand new. Java was years away. Spacecraft were mostly programmed in assembler, or, if you were really being radical, Ada.
Given the choices, Lisp made a lot of sense when they started. After 2001-2004, there were other options - not to say they were necessarily better, but a mainstream language that enables a large number of people working together (interchangeably) has its value. Lisp is indeed "one-of-a-kind, highly dynamic applications that must be developed on extremely tight budgets and schedules" - but has a reputation for fostering lone geniuses and bad for large teams working together and maintaining legacy codebases.
(I write this as a big fan of Lisp.)
anthk
Also, as a very tiny and minimal Lisp:
Easier than SICP for Scheme and Intro to Symbolic Computation for Common Lisp.
anthk
>enginner >can't do anything with 128MB. In 2002.
In my country an Engineer with a Bachelor would implement a Forth in KB's in days by just reading the specs or books related to building one.
A Microlisp maybe in weeks.
anthk
Forth would be a good choice too. No GC, use 'forget'.
lisper
We used Forth back in the day as well, running on 6811 microcontrollers. Forth was also used on the Galileo Magnetometer, and we used Lisp to develop a patch for it in flight.
adityaathalye
Forth, in fact, is. https://www.forth.com/resources/space-applications/
ssrc
'Was' is more likely. The list is from 2003, and if FORTH Inc, the (only? biggest?) remaining forth company hasn't updated it...
anthk
Forth is used in firmware and tons of places. There's ANS Forth and no need to 'update' anything, as there are tons of implementations.
As with Lisp, you can bootstrap themselves with very few primitives.
jmclnx
> The demise of Lisp at JPL is a tragedy. The language is particularly well suited for the kind of software development that is often done here
That is a shame, but this can be said about many languages of time past. Do schools even teach lisp these days ?
IMO, another casualty of our WEB only environment :(
Lyngbakr
> Do schools even teach lisp these days ?
anthk
Very tiny Lisp, Forths and some Pascal like at http://t3x.org
One of them whole numbers as lists. I saw no floats, but there are fractional numbers.
(- '#2 '#3)
=> '#-1
Easy mode:
You are Alonzo Church reincarnated:
null
Author here. This pops up on HN regularly, which I'm happy to see, but it's pretty dated at this point. Here is a more recent update:
https://blog.rongarret.info/2023/01/lisping-at-jpl-revisited...
And, as always, AMA.