
The rise and fall of Lisp at the Jet Propulsion Lab (2002) - gsivil
http://flownet.com/gat/jpl-lisp.html
======
Maro
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.

~~~
brlewis
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.

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

~~~
stcredzero
_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.)

~~~
mturmon
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.

Here's someone at JPL who's in that area:

<http://www.usc.edu/dept/ise/directory/jairus_hihn.htm>

~~~
stcredzero
Sounds like JPL is a lot more sophisticated than NASA in this regard. This is
weird, since NASA flys a lot more _manned_ missions.

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

~~~
nimrody
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).

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

...and thus XML is born.

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

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

~~~
rhizome
Management by metaphor, I'd say that's a red flag.

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

~~~
gnosis
And I'd love to see them try the same thing with Java.

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

~~~
chris_j
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:

<http://www.paulgraham.com/diff.html>

~~~
kenjackson
_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).

~~~
papaf
_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.

[1] <http://martin.jambon.free.fr/extend-ocaml-syntax.html>

~~~
kenjackson
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?

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

~~~
SamReidHughes
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.

~~~
thirsteh
I would have ignored it if it was an irrelevant tidbit, but it wasn't. It
seemed to be quite a major point in the article.

