Here'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:

http://ase.jpl.nasa.gov/

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.

"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'.

"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

From the article: "The management world has tried to develop software engineering processes that allow people to be plugged into them like interchangeable components. < . . . > To my mind, the hallmark of the interchangeable component model of software engineers is Java."

I hate that attitude in management. I've been surprised to find that at higher levels (think C-level) of management leaders who completely don't think of engineers as plug-and-play. I wonder if it is an attitude or viewpoint more common in lower level management in large organizations.

Regardless, I kind of gave up on Java simply because I felt it seemed to get me into environments where people were treated as cogs.

"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."

I would love to see a transcript of this debugging session.

As 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?

I think the article lacks a lot of meat. It talks about what the author used Lisp for, but it doesn't really dicsuss why he thinks Lisp should be used, or why others thought it should not be used.

For example,

"Someone (I don't know who) interrupted him [the software integration engineer] and asked if he could change only one thing to make things better what would it be. His answer was: get rid of Lisp. That one event was pretty much the end of Lisp at JPL."

Why did the integration engineer say that? This should be the cornerstone of the article. Same thing goes for the Google discussion he quotes.

Also, the author doesn't seem to take market forces into effect, eg. given that C++/Java became the dominant languages, I'm almost certain there were (are) not enough Lisp programmers on the market for Lisp to be a feasible technology at a large organization.

Nice article, but I really didn't like the ending. It seemed a lot like Republican "everything the government does is wrong and costs taxpayer dollars" propaganda.