Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The rise and fall of Lisp at the Jet Propulsion Lab (2002)

flownet.com

Post reply on HN
Print view View original

31–40 of 41 posts

Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)

#31

Post by papaf »

kenjackson wrote: post #25
chris_j wrote: post #10

Earlier quoted context omitted.

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 bein…

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…

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

Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)

#32

Post by kenjackson »

papaf wrote: post #31
kenjackson wrote: post #25

Earlier quoted context omitted.

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…

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…

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?

Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)

#33

Post by thirsteh »

thirsteh wrote: post #20
lisper wrote: post #17

Earlier quoted context omitted.

FWIW, the author is a Democrat.

And? That doesn't change what was written.

PS: Sorry for the arrogant comment -- hadn't seen the acronym "FWIW" before. Thought it was a correction :)

Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)

#35

Post by dedward »

rbanffy wrote: post #18
mturmon wrote: post #2

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 surpris…

> 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 so…

Pretty sure most ground software UI stuff is in Java, and on-board spacecraft stuff is compiled down to the smallest package possible.

Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)

#36

Post by thirsteh »

sfk wrote: post #34
thirsteh wrote: post #20

Earlier quoted context omitted.

And? That doesn't change what was written.

An interesting piece of information nonetheless. It is almost as if lisper knew the author personally...

;) Is there a light bulb emoticon?

Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)

#37

Post by gnosis »

sigil wrote: post #26

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

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

Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)

#38

Post by kaffiene »

gnosis wrote: post #37
sigil wrote: post #26

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

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

Hotswap of running Java code has been available since Java 1.4. You can use it through a Java debugger and you can attach a debugger to any running process in the JVM.

Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)

#39

Post by mturmon »

stcredzero wrote: post #8
mturmon wrote: post #2

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 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 mathema…

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

Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)

#40

Post by flavoie »

Maro wrote: post #14

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 even…

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

Post reply on HN