Hacker News Reader

Comment by zerr | Hacker News Reader

I'm glad that Lisp is not used in spacecraft control system.

Yes, they only mentioned several wild successes, why would they want to continue having them?

zerr's post reads like Lisp is some kind of terminal disease that will cause spacecraft to slowly get cancer or something. It sounds like completely irrational hostility.

But the article reads like blatant fanboy-ism, as if Lisp turned spacecraft into unicorns that magically distributed rainbows around the solar system or something. It's completely oblivious to the organizational cost (except, oddly, at Google).

What's the organizational cost of Lisp at JPL? Somebody's got to maintain these tools for decades. Over the lifetime of a spacecraft mission, people leave. People even die. If nobody understands the software (or the tools the software depends on, including the build chain), then when someone other than the original magician has to fix something, you're stuck. JPL really doesn't want to be stuck when a probe is approaching a planet and a fix is needed to make the mission work. The article has zero recognition that such issues could even exist.

> If nobody understands the software (or the tools the software depends on, including the build chain), then when someone other than the original magician has to fix something, you're stuck.

Well the great news is that its Lisp, the language is simple. You have the same problem with other languages, except if you used C++, everything just got a magnitude more complicated, both because the whole thing is more complex and the ecosystem is changing and developing more rapidly.

With Lisp, the language is simple. But everyone writes their own DSL on top of the language because the language is simple. It's easy to do in Lisp, but it's also easy to make it incomprehensible to anyone else. I've heard this called "the curse of Lisp".

I've seen lots of programs written in lower-level languages that are incomprehensible because the patterns were macro-expanded by hand 1000 times and it's impossible to get the big picture.

I can't say I've ever seen a Lisp program where abstraction made it incomprehensible. That seems to be a common meme, though. I'd love to see an example.

>But everyone writes their own DSL on top of the language because the language is simple

This is a myth perpetuated by people with zero lisp experience.

I've navigated plenty of lisp libraries' codebases and haven't found not a single case of that.

>I've heard this called "the curse of Lisp

An essay written by... a graphic designer with zero Lisp experience.

I don' know how bad it is for Lisp, but I get the argument and I think its valid. I've seen to much bad non-idiomatic and homegrown code to know this is a big poblem. A big part of the value of using e.g. Spring Framework is that it is standardized, easy to understand and devoid of a lone hacker's "brilliant" ideas.

I think the part about the toolchain/dependencies still stands.

> If nobody understands the software (or the tools the software depends on, including the build chain), then when someone other than the original magician has to fix something, you're stuck.

Speaking from experience, this is independent of the language chosen. I've seen several pieces of software over a variety of languages that are a nightmare to maintain.

What really ends up happening is a kind of oral lore. People learn how to use the parts of the software that is known to work, and the business processes ossify around those known behaviors. The current developers and maintainers walk around on eggshells to avoid changing that behavior because of the risk involved in changing those processes. And then nobody remembers why the processes are as convoluted as they are, and it just becomes the way things have always been done. When there's a series of successful missions backing that assertion, it's hard to argue the point.

But because this idea -- that perfectly reasonable yet "not mainstream" languages produce software thats's hard to understand and maintain -- is so pervasive, we get pressure coming back from the other side. Perfectly reasonable choices of language are blocked, and everything starts regressing to the mean. The old adage goes something like, nobody ever got fired for choosing IBM. Well, nobody ever got fired for choosing Java, either. Even Clojure or Scala, which are perfectly productive, excellent languages that also run on the JVM, are a nervous choice.

(Also, Makefiles are absolutely a dark art, and many modern languages have thankfully produced better abstractions for their purposes, but C and C++ are still seen as totally reasonable first choice languages for a program. =/ )

> JPL really doesn't want to be stuck when a probe is approaching a planet and a fix is needed to make the mission work. The article has zero recognition that such issues could even exist.

Spacecraft often receive code updates while they're in cruise to their destination -- it doesn't matter whether it's Lisp or not. See for instance Juno: http://www.deepstuff.org/nasas-juno-spacecraft-mission-overv...

>> Spacecraft activities during the Jupiter Approach phase include spacecraft subsystem calibrations and maintenance activities, as well as flight software updates and hardware checks in preparation for Jupiter Orbit Insertion.

If I'm at JPL, doing C++, they probably have several more C++ programmers. I probably work with some of them. If I'm gone, they probably have someone who can take over, people who maybe use the same coding standard I use (they almost certainly have one for C++). But if I'm the first person there using Lisp, there probably isn't a standard (unless I wrote it, and if so, it's a standard nobody else there uses). There may not be anyone else there who knows the language. So while Lisp may be a perfectly reasonable language in terms of functionality, it's not a perfectly reasonable language in terms of the organizational issues. I, the programmer who wants to use Lisp, may not have to think about those issues, but managers do.

Yes, I agree! I merely think you overvalue C++ in this case. There's lots of C/C++ code that most people can't understand either -- and not for lack of knowing the language.

Apropos of nothing, I found Peter Naur's "Programming as Theory Building" [1] an enjoyable read on the topic of maintaining software after the original developers depart.

[1] http://pages.cs.wisc.edu/~remzi/Naur.pdf

Note that JPL had many people using Lisp - in fact, it was C++ that was relative newcomer.

> JPL really doesn't want to be stuck when a probe is approaching a planet and a fix is needed

Ironically, the point of this JPL Lisp project was spacecraft autonomy. When you're coming up on a flyby, light-hours from Earth, the standard fault-tolerance strategy (go into safe mode, wait for instructions) makes it physically impossible to satisfy mission goals. You need something smarter and more adaptable, and that's pretty hard to accomplish in the standard style of software in C they were used to.

(I was there and read internal docs about the Remote Agent project this post was about.)

Years later in the Pluto mission this nightmare almost happened: the probe went into safe mode ten days before the flyby, and they heroically fixed it over a few days of crunch time.

I think it is obvious that such extremely dynamic language with a non-deterministic GC is not suitable for particular tasks. Unless they were using some dialect with static guarantees and correctness provable constructs.

Why?

Leave out one parenthesis and...you miss Venus?

I've read that they use Matlab which suffers from the same issues

Mentioning MATLAB in the same context as lisp is almost blasphemy

Leave out one parenthesis and your program doesn’t compile, i.e., exactly the same failure mode as almost any other language.

This isn't even worthy of Reddit

reddit was originally written in Lisp.

I mean the parent comment, not TFA

>Leave out one parenthesis and...you miss Venus?

You won't, since Lisp editors automatically keep parentheses balanced.

Why? (Legitimately asking)

I think C and C++ are the most popular languages for hard real time development, so you'll have better OS support, better best practices, more experience if you choose one of those.

But I don't do things in hard real time, so please correct me if I'm wrong.

You're not wrong. But "most popular" != "best". The Lisp we used on DS1 was hard-real-time.

did you ever work with Ed Gamble perchance? such a cool community we have here.

Yes, we worked together on the Remote Agent project.

You're doing God's work, Ron.

:-)

A lot of aerospace real-time environments are still geared for Ada, and while C/C++ are available they are not the same as "vanilla" C/C++. Also, is there really C-specific support in a good RTOS? Probably doubtful, except for inertia or presence of header files if they expose them.

Reply on news.ycombinator.com