The rise and fall of Lisp at the Jet Propulsion Lab (2002)
1–10 of 41 posts
Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)
#2Here's the paper that summarizes the results of the Remote Agent flight experiment ("RAX"), which is the project Erann was working on at the time:
www-aig.jpl.nasa.gov/public/papers/rax-results-isairas99.ps
The stuff about integrating a Lisp executive/planner and the rest of the C flight software is in section 4.1.
It's for sure none of this flight software is in Lisp any more. Additionally, I would be highly surprised if any shred of the ground software that supports it is in Lisp. Both flight and ground s/w is almost certainly in C/C++ and Java.
One of the successors to RAX is:
in which an Earth-orbiting spacecraft can recognize events like volcano eruptions) and autonomously (without ground control) take extra data from it.
*
It's hard to appreciate just how unwilling a flight mission is to take on any unnecessary technical risk. Risk, along with cost, schedule, and mass, is one of the fundamental things mission designers must cope with. Lisp looks like risk, and risk will be eliminated ruthlessly (as in the meeting Erann describes in the OP).
Additionally, there are the software lifecycle considerations. That is, flight s/w, if it works, tends to be passed forward from mission to mission, and quirky choices tend to be weeded out.
Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)
#3"15. (Shea's Law) The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up."
From Akin's Laws of Spacecraft Design: http://spacecraft.ssl.umd.edu/akins_laws.html
Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)
#4Here's the paper that summarizes the results of the Remote Agent flight experiment ("RAX"), which is the project Erann was working on at the time: www-aig.jpl.nasa.gov/public/papers/rax-results-isairas99.ps The stuff about integrating a Lisp executive/planner and the rest of the C flight software is in section 4.1. It's for sure none of this flight software is in Lisp any more. Additionally, I would be highly surpris…
[deleted]
Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)
#5"we're confusing best practice with standard practice"
This nails my dislike of the phrase 'best practice'. It never means 'the best way to do it' and always means 'the way everyone else does it' or worse 'the way the person writing the phrase has just thought of doing it'.
Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)
#6"we're confusing best practice with standard practice" This nails my dislike of the phrase 'best practice'. It never means 'the best way to do it' and always means 'the way everyone else does it' or worse 'the way the person writing the phrase has just thought of doing it'.
Sometimes, when the difference between "best way" and "standard way of doing things" is not so great -- it is better to go with standard practice. Reduces time to learn for others, and avoids surprises when interacting with other systems (POLA).
Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)
#7As someone who's never used Lisp before, what's the difference between Lisp and Haskell? I keep hearing old stories about the virtues of Lisp, but it doesn't seem like anyone uses it anymore. Has it just been replaced by newer functional languages?
Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)
#8Here's the paper that summarizes the results of the Remote Agent flight experiment ("RAX"), which is the project Erann was working on at the time: www-aig.jpl.nasa.gov/public/papers/rax-results-isairas99.ps The stuff about integrating a Lisp executive/planner and the rest of the C flight software is in section 4.1. It's for sure none of this flight software is in Lisp any more. Additionally, I would be highly surpris…
It's hard to appreciate just how unwilling a flight mission is to take on any unnecessary technical risk. Risk, along with cost, schedule, and mass, is one of the fundamental things mission designers must cope with. Lisp looks like risk, and risk will be eliminated ruthlessly
I've spoken with programmers at NASA. There have been times when management thought source control was a risk. Discovering a bug in the mathematics of an algorithm and fixing it is a risk. (Seriously, management was like: the software worked last time with the math bug, so it should work this time with the math bug.)
...flight s/w, if it works, tends to be passed forward from mission to mission, and quirky choices tend to be weeded out.
Like most organizations, I'd bet most of these decisions are more "gut feeling" than based on anything approaching empirical. (Arguably, the continued existence of old-school companies using "Steak and Strippers, Baby!" sales tactics is a bet that such irrational decision mechanisms persist.)
Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)
#9As someone who's never used Lisp before, what's the difference between Lisp and Haskell? I keep hearing old stories about the virtues of Lisp, but it doesn't seem like anyone uses it anymore. Has it just been replaced by newer functional languages?
Lisp is strictly evaluated, homoiconic, dynamically typed, and dynamic? It's hard for two languages to be more different than Lisp and Haskell, the only thing they have in common is their distance from the origin.
Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)
#10As someone who's never used Lisp before, what's the difference between Lisp and Haskell? I keep hearing old stories about the virtues of Lisp, but it doesn't seem like anyone uses it anymore. Has it just been replaced by newer functional languages?
The main difference between Lisp and other languages (including Haskell) is that Lisp is homoiconic. That is, a Lisp program is represented as a list, a data structure that can itself be manipulated by a Lisp program. This means that a Lisp program can contain macros that can generate Lisp code at compile time (or even at runtime). This might sound dangerous, especially if you have seen C macros or C++ templates being abused, and it is. It also turns out to be rather powerful; you can use macros to implement at lot of things that in other languages can only be implemented by the compiler writer. One popular example is looping constructs: if your Lisp doesn't have a for-loop then you can implement it as a macro. This is how for is implemented in Clojure, my personal favourite Lisp.
What about functional languages? Well, Lisp has been around for so long that it pioneered a lot of programming concepts. One of these is functional programming. Later, many purer functional languages took functional programming a lot further, Haskell being a great example. There are many flavours of Lisp today and some, such as Clojure and Scheme, aim to be fairly pure functional languages (and Haskell is the purest functional language that I can think of), whereas others, such as Common Lisp, are less so. Functional programming is only one thing that Lisp has going for it, of course.
As I mentioned, Lisp pioneered a lot of concepts which we take for granted today. This essay by pg gives a summary of what made Lisp different and is well worth reading, along with other pg essays on the subject of Lisp: