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.
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.
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.)
Regarding risks, I think you're understating the sophistication and importance of risks on flight projects. (I work at JPL, but not on flight projects; once upon a time, the OP's office was right down the hall from mine.) A modest sized flight project will have a risk list which is itemized down to great detail, covering many pages, and this list will be one of the main things the mission managers work on reducing.
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.
> Both flight and ground s/w is almost certainly in (...) Java.
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.
"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'.
This nails my dislike of the phrase "never means." It never means that "it doesn't ever mean" and always means "nobody ever told me what it can mean" or worse "i've never looked for any other meanings."
"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.
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).
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?
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:
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).
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).
But there is nothing stopping non homoiconic languages from adding first-class macros (macros that are written in the language itself).
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.
Zak mentioned Nemerle, which appears to have a very simple macro syntax. It actually reminds me of Lisp, although I'm sure Lispers will happily explain how its completely different. :-)
Have you taken a look at Nemerle? What there is broken compared to Lisp?
But there is nothing stopping non homoiconic languages from adding first-class macros
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.
PS - I mentioned that for loops are implemented as a macro in Clojure. I should have said list comprehensions. Have a look at the clojure source here and search for "(defmacro for" to see what I mean. It's awesome to think that, if this hadn't already been in the language, you could have written it yourself.
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.
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.
The advantages of Lisp are fairly well-known among its users. Assuming that Lispers are the intended audience, it requires no explanation. It would be helpful to discuss for a broader audience though.
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.
You're right, it should be the cornerstone of the article. Unfortunately it's relegated to note [3] and the postscript, where we learn that buggy C code was the cause of the integration engineer's Lisp headaches.
notes at the end :
"""
[3] This begs the question of why he said this. The reason he gave at the time was that most of his time was being taken up dealing with multi-language integration issues. However, this was belied by the following fact: shortly before the review, I met with the integration engineer and offered to help him with any Lisp-related issues he was encountering. He replied that there weren't any that I could help with. So while there were issues that arose from the fact that Lisp had to interoperate with C, I do not believe that a good-faith effort was made to address those issues.
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.
"""
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.
Nice comment, but I really didn't like the presumption. It seemed a lot like the internet commentator "let's discard the actual content of the article and niggle around about our misinterpretation of an irrelevant tidbit" archetype.
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.