The rise and fall of Lisp at the Jet Propulsion Lab (2002)
flownet.com
flownet.com
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.
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.)
In general, there are two parameters, likelihood of the risk materializing, and cost if it does. Sometimes the cost is easier to bear (dollars and schedule), sometimes it's harder (lose the mission). For units like dollars and schedule, it does make sense to do a weighted average (sum over risks of probability * cost); for others it does not. People go farther and use various Monte Carlo methods to deal with risks that interact, so that the sum above does not work.
Here's someone at JPL who's in that area:
Which is why we have to use chemical rockets - Java's license would prohibit it from controlling a nuclear engine ;-)
Seriously, I have seen many projects jettison good, solid, time-tested and efficient code on the grounds that it was written in a language "nobody understands" (exotic and hard-to-master things like... Python). My last problem was with someone having the bright idea of re-implementing Amazon's S3 internally because they would need to handle huge amounts of data. It turns out their "huge amounts of data" is a couple terabytes of large files.
The other was when someone said a given system was written using J2EE "(what else?)".
Sometimes I wonder if this is the dumbest generation ever to operate the smartest tools ever.
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'.
...and thus XML is born.
"Best Practice" is a term of art within business and technology. It's a synonym for "conventional wisdom," and/or "common sense," which, as the man once said, is not necessarily common. That doesn't render it meaningless, though. Best Practices are not information handed down from God, so as best practices hold, it should not be relied upon as perfect.
From Akin's Laws of Spacecraft Design: http://spacecraft.ssl.umd.edu/akins_laws.html
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.
I would love to see a transcript of this debugging session.
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:
https://github.com/richhickey/clojure/blob/master/src/clj/cl...
The latter (about Lisp macros) is actually orthogonal to it be homoiconic. What it does mean is that parsing, manipulating, and generating Lisp code is just like generating any other Lisp data structure. But there is nothing stopping non homoiconic languages from adding first-class macros (macros that are written in the language itself).
This is true, and Nemerle is an example of a language with this feature. That said, it's harder to write macros in non-homoiconic languages. One can write Lisp macros by starting with the desired output and inserting quote and unquote where appropriate. Generating a syntax tree in other languages requires mentally translating them to something like Lisp.
That is true in theory. However, I struggled with camlp5 [1] for hours to achieve something that could be done trivially with a lisp macro. I'm certain its because the I was having to do much more than rewrite a datastructure. Interestingly, it was this very experience that moved me back to lisp.
Have you taken a look at Nemerle? What there is broken compared to Lisp?
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.
I think the market forces argument is overstated with languages like Lisp, Haskell and ML that have very devoted users. I believe, but cannot prove that hiring for a Lisp job in an area with a large programmer population would be at least as easy as hiring for a Java job. The mere fact of being a Lisp job would tend to attract the Lispers; there would be applicants. Certainly, they would be fewer than for a Java job, but that's not a bad thing; the hiring process often involves spending a massive amount of time weeding out people who are too inept to even consider. There are very few Lispers who are too inept to consider for most Lisp programming jobs.
Postscript: Many of the multi-language integration headaches were caused by the interprocess communication system that allowed Lisp and C to communicate. The IPC relied on a central server (written in C) which crashed regularly. Getting rid of Lisp did in fact alleviate those problems (because the unreliable IPC was no longer necessary). It is nonetheless supremely ironic that the demise of Lisp at JPL was ultimately due in no small measure to the unreliability of a C program. """