[HN Gopher] Lisp in Space
___________________________________________________________________
Lisp in Space
Author : todsacerdoti
Score : 83 points
Date : 2022-05-02 12:37 UTC (1 days ago)
(HTM) web link (corecursive.com)
(TXT) w3m dump (corecursive.com)
| adamgordonbell wrote:
| Does anyone know how they now debug things in Space?
|
| If they are using compiled C programs it seems like it would be
| very hard to make changes. Is the key just to not need to make
| any changes?
|
| Or is this a case of Greenspun's tenth rule, where they've built
| REPL like functionality on-top of C?
| monocasa wrote:
| The cases I've seen deploy relatively full binaries, not
| patches.
|
| And they don't typically even have a REPL, as doing brain
| surgery on a satellite (that's already in a bad way if you're
| debugging something) is rarely the best option. So lots of
| telemetry logging, with 'feature flags' to turn on different
| logs. Then a change and code push once root cause is found, or
| a new build with new telemetry gathering if it's still not
| clear.
|
| I'm sure just about every model for code structure has someone
| doing it though.
| lisper wrote:
| Ron Garret here. AMA.
| outworlder wrote:
| I've been fascinated with the 'Lisping in the JPL' piece (even
| though I tend to prefer Scheme). However, I've been trying to
| find something substantial about the 'remote agent' and I can't
| really find much. Sure, there are some articles describing at a
| very high level how it worked, but not much more than that. At
| least, I couldn't find.
|
| Do you think anything survived that would shed more light in
| its workings? Not even talking about the code (although that
| would have been wonderful, and maybe it should be provided -
| taxpayer funded and whatnot).
| lisper wrote:
| I have no idea what documentation for the RA was preserved,
| but I'd be surprised if the complete source isn't archived
| somewhere. I would contact the JPL PIO (public information
| office) and ask them.
| jrumbut wrote:
| I'm sorry to say I know little about you or the subject (so I
| apologize if either answer is obvious or addressed elsewhere)
| however since you're here:
|
| What would you like to see NASA do differently?
|
| What do you think of Racket (the programming language)?
| lisper wrote:
| Good questions. I have been away from NASA for almost 20
| years now so I can't really say what I think they should do
| differently because I don't really know what they are
| currently doing. A lot can change in 20 years, and I'm sure a
| lot has, but I'm no longer in the loop so I can't really say
| anything constructive about this.
|
| I've never used Racket but from what I can tell it's a fine
| system. I'm partial to Common Lisp myself, never really
| resonated as much with Scheme, though I do admire the
| elegance of the language. But if it works for you, go for it.
| costigan wrote:
| I think lisp is still used in various nooks and crannies of
| NASA. As a small example, I was the payload software
| engineer for the LCROSS mission (a robotic mission in 2009
| that demonstrated there was water ice near the moon's south
| pole). The software that ran on the payload computer was in
| C, but there was a very simple, ad hoc scripting language
| provided by the company that provided that payload
| computer. Because this language was very simple, I wrote a
| higher-level DSL and a simulator of the computer in common
| lisp and then wrote all of the instrument command sequences
| in that DSL. Lisp's simple, flexible syntax and macros made
| it easy to express patterns of commanding and timing for
| this. What the commands did is described in the last
| (topmost) blog entry here:
| https://blogs.nasa.gov/lcrossfdblog/ . These days, I'm
| working on the VIPER rover, and the commanding approach for
| it is very manual, as Ron described. VIPER will be a moon
| rover, so the turn-a-round time for commanding is much
| shorter than it would be for a MARS rover, and
| teleoperation from Earth is a very reasonable and lower-
| risk solution than autonomy. Still, some of the systems
| used in self-driving vehicles today to evaluate the
| environment around the vehicle will be used by VIPER, but
| to provide advice and situational awareness for the
| drivers. No lisp involved.
| leobg wrote:
| Great to have you here!
|
| Did you ever try Smalltalk? Is there any area where you would
| prefer Smalltalk over LISP?
|
| If you had to start from scratch, which of the two would you
| learn today, and why? (Let's assume that getting hired is not
| your concern, but only the ability to build powerful systems
| and the ability to reason about difficult problems.)
|
| Thanks!
| lisper wrote:
| I've never tried Smalltalk so I can't really speak to that.
| But I have done some coding in ObjectiveC which is a direct
| descendant so I can tell you that I _strongly_ prefer Lisp,
| and Common Lisp specifically because I prefer generic
| functions to message-passing. Message passing privileges the
| receiver object and thus introduces an asymmetry which is
| totally unnecessary. It does nothing but cause confusion. The
| whole point of having a high-level language is to reduce the
| cognitive load on the programmer, and message passing does
| the exact opposite. Message passing forces me to think, every
| single time I call a function, about whether to write a.f(b,
| c, ...) or f(a, b, c, ...) or that absolutely horrific syntax
| that ObjC has, [f a:b] or something like that. There is no
| reason why _I_ should have to think about any of that. That
| 's the compiler's job. All function calls should use the same
| syntax -- and that syntax should be (f a b c ...) because all
| those commas are unnecessary too.
| d-mason wrote:
| I would say the same thing (or more exactly, the dual) from
| a Smalltalk perspective: I just want to send a message to
| an object, I shouldn't have to figure out what function to
| call or what to parenthesize. The problem people get into
| with OO (particularly Java, C#, C++) is thinking in terms
| of method-function calls rather than message sends.
|
| Although I _do_ like Lisp generics - I did a bunch of
| programming in rscheme many years ago, and really liked it.
| lisper wrote:
| > I just want to send a message to an object
|
| Why? Seriously, why is that something you want? Why do
| you want sending a message to be syntactically and
| semantically distinct from calling a function?
|
| > The problem people get into with OO (particularly Java,
| C#, C++) is thinking in terms of method-function calls
| rather than message sends.
|
| Well, IMHO the problem people get into with OO is
| thinking that there is something special about sending a
| message that is different from calling a function.
| Sending a message is an _implementation technique_ , not
| a semantically distinct action that should be exposed in
| the language semantics, and _certainly_ not in the
| syntax.
| xkriva11 wrote:
| ...or a b c f because all the parentheses are unnecessary
| too (Forth nudge ;-) )
|
| I think that Smalltalk deserves a little bit of opened mind
| here. In many respects, it is the closest thing to Lisp
| machines experience you can get today.
| lisper wrote:
| > all the parentheses are unnecessary too
|
| That's not quite true. In Forth it is impossible to tell
| syntactically where the function calls are.
|
| > it is the closest thing to Lisp machines experience you
| can get today.
|
| I think Clozure Common Lisp running on a Mac (i.e. with
| the IDE) is pretty close as well.
|
| But I don't begrudge anyone their Smalltalk. It's just
| not a good impedance match to my brain.
| AnimalMuppet wrote:
| > It's just not a good impedance match to my brain.
|
| I think that's the answer to every language war ever. "To
| my brain." If you claim "X is easier to understand", you
| get a war. But if you claim " _for my brain_ , X is
| easier to understand", that's a lot harder to have a war
| about. All someone can reply is "well, my brain is
| different", which... OK, your brain is different. Fine.
| (Or someone could claim that nobody could actually have a
| brain such that X is easy to understand, at which point
| it's pretty clear who the unreasonable zealot is.)
|
| In fact, I think this is also the answer to the editor
| wars. It may even be the answer to the political wars.
| lisper wrote:
| Well, not quite. Some languages are _by design_ good
| impedance matches to brains that don 't know very much.
| BASIC is the canonical example. It's really easy to
| learn, which makes it attractive to beginners, but it has
| some pretty serious limitations that you only become
| aware of after discharging a certain amount of ignorance.
| IMHO this makes BASIC objectively worse than other
| languages.
|
| To me, Lisp makes every other language I know feel like
| BASIC in the sense that the distinguishing features of
| the language feel to me like they are designed to appeal
| to ignorance rather than to empower.
| samatman wrote:
| > _In Forth it is impossible to tell syntactically where
| the function calls are._
|
| To be fair, this is true of Common Lisp as well, macros
| aren't functions.
|
| Forth doesn't really have functions, it has words,
| they're broadly useful like functions but are a
| differently-literal sort of memory object from a lisp
| function defined with cons cells.
|
| So you can't know where the function calls are, there is
| no such animal, but you do know where the word boundaries
| are, it's the whitespace, and in Forth that's what you
| care about.
| lisper wrote:
| > macros aren't functions
|
| That's true, and it is arguable that Lisp could be
| improved by making macro invocations have a distinguished
| syntax.
|
| But in practice it's usually pretty clear what is a macro
| and what is a function because of naming conventions, and
| because macros commonly admit syntax that would be
| illegal in a function call e.g. (let ((x 1)) ...) But
| however bad this problem is in Lisp, it's much worse in
| Forth.
|
| > Forth doesn't really have functions
|
| That is debatable. If I write 1 2 + 3 * then I think of
| the + and the * as function invocations that take their
| arguments off the stack and leave their results on the
| stack. It's true that this is not exactly the same as a
| function call in Lisp, but it's similar. In any case, if
| I write:
|
| a b c d e f g h i j
|
| there is absolutely no way to tell what that is going to
| do without knowing what every letter means. By way of
| contrast, if I write:
|
| (a (b c d) (e f) (g h (i j)))
|
| then it's a pretty good bet that a is a function that
| takes three arguments, b and g are functions that takes
| two arguments, e and i are functions that take one
| argument, and c d f h and j are variables.
| zozbot234 wrote:
| What you don't get in FORTH is _arity_ information from
| the syntax, because everything is simply treated as a
| function from stack to stack. Unfortunately it 's not
| feasible to keep the cleanliness of the FORTH syntax
| while providing that info (one would need a 2D view for
| that, where multiple arguments to the same function can
| be seen in parallel) so a parens-based syntax is arguably
| the next best choice.
| leobg wrote:
| Makes sense. Thank you!
| lisper wrote:
| You bet.
| kagevf wrote:
| These days we would use SLIME and SWANK to connect to a remote
| image. What was the setup used back then?
| lisper wrote:
| Personally I did all my development in Macintosh Common Lisp
| (now Clozure Common Lisp). I'm sure some people used Swank
| and Slime. There was no reason for everyone to be on the same
| page about that so we didn't discuss it much.
| kagevf wrote:
| Interesting ... I just assumed that SLIME hadn't existed
| yet. Now I'm curious about CCL on the mac ... I think I'll
| install CCL on my lone mac device just to see a different
| take on connecting to a remote image. As well as checking
| out a non-emacs IDE for CL ...
| vivab0rg wrote:
| Thanks for sharing your very inspiring story!
|
| Now, how do you see the current Lisp landscape compared to your
| experience back in the 80s? Where are the good opportunities
| for Lisp nowadays?
| lisper wrote:
| That is a very difficult question to answer succinctly. From
| a technical point of view, Common Lisp has never been in
| better shape, particularly since the advent of Quicklisp.
| Just about any functionality you would want is available as a
| CL library through QL. Programming in CL today is easier than
| it ever was. But on the other hand, it does not seem to be
| attracting a lot of young blood. The cool kids all seem to be
| using Clojure or Haskell or Rust or, heaven help us,
| Javascript.
|
| So I hope Lisp has a bright future, but I wouldn't be my life
| savings on it right now.
| nonrandomstring wrote:
| > it does not seem to be attracting a lot of young blood.
|
| In my experience "space" sells to the kids more than money,
| fast cars and fame. So thanks for your inspiring writing
| about your work - I'm looking for ways to convince the dean
| to let me switch some courses from Python (which has jobs)
| to Lisp (which has excitement, space adventures and really
| wild things).
| lisper wrote:
| LMK if there's anything I can do to help with that.
| GenericJam wrote:
| Is Lisp + message passing a bridge too far? ie https://lfe.io/
| Does Lisp on the BEAM hold any appeal for you?
| lisper wrote:
| I don't know what Lisp on the BEAM is (and neither does DDG).
|
| With regards to LFE, I don't really see the point. But that
| might just be because of the kinds of coding I do. I've never
| written high performance massively parallel code. Message
| passing might have a benefit there (that is what the big win
| with Erlang is supposed to be) but I'm generally skeptical of
| designing the language semantics around the needs of the
| compiler rather than the programmer.
|
| In particular, I don't see what Erlang could possibly do that
| could not be done by a CL compiler that noticed when a method
| was dispatching only on the first argument. The semantics of
| that are equivalent to the semantics of message passing, and
| so the code that such a compiler emits could be identical in
| both cases. But I don't actually know Erlang so it's possible
| I'm missing something.
| GenericJam wrote:
| With Erlang it's necessary to separate the compiler from
| the VM. You are working around what the VM wants but the
| compiler is not a problem. The VM acts a bit like an
| operating system that can schedule its own processes and
| processes can send each other messages. In order to receive
| a message a process has to have a receive block and be
| capable of receiving the message (with an applicable
| pattern match). When a process is waiting for a message, it
| is set aside by the VM so it consumes very few resources
| (just a bit of memory). It is woken up when it receives a
| message. This way a single 'program' can have many things
| going on at once and it is never blocking. From the
| programmer's perspective it feels like you are writing
| synchronous code but you are getting async behaviour 'for
| free'.
|
| wrt LFE specifically, Robert Virding, one of the founders
| of Erlang, really likes languages and Lisp in particular so
| he wrote one for the BEAM. It just has some special
| accommodations to be able to send/receive (and I think
| pattern recognition too).
| lisper wrote:
| That actually sounds pretty cool as a runtime
| environment. Is the VM programmed in byte code, or is it
| native code? What back ends are available? What is the
| runtime written in?
| samatman wrote:
| BEAM is the Erlang VM so you covered the question nicely.
| tosh wrote:
| Thank you for sharing your stories. I have (re-)read "Lisping
| at JPL" [0] dozens of times! What are you up to nowadays?
|
| [0] https://flownet.com/gat/jpl-lisp.html
| lisper wrote:
| Mostly retired. I tried to do some startups but they all
| failed. Now I have a part-time gig at a chip manufacturer who
| uses Common Lisp for one of their internal design tools, so
| I'm helping them maintain that. Besides that I'm doing a
| little writing, a little hacking, a lot of traveling, and the
| odd podcast interview :-)
| tosh wrote:
| love it!
| mananaysiempre wrote:
| You mention debugging the live Deep Space probe using a LISP
| REPL, and I remember reading somewhere else how people
| troubleshooted an earlier Voyager (?) probe via a FORTH REPL.
| Were those schools of thought in contact at all?
|
| What do you think about the efforts of some Haskell folks to
| make embedded languages that would generate code for a more
| limited system but at the same time leverage the beefy Haskell
| stage as both an extensible static analyzer and an overgrown
| macro processor? There were a number of those (I think shaders
| for earlier-generation GPUs, real-time control code, and even
| hardware synthesis were all among the attempted targets) and I
| don't know that they got any adoption at all, but this sounds
| similar to what you've described doing on less capable machines
| with LISP.
| mek6800d2 wrote:
| A little late to the discussion! The John Hopkins University
| Applied Physics Lab (JHU/APL) uses or used to use FORTH for
| non-critical satellite flight software (and Ada for mission-
| critical software). Back in 2009, I came across this 2006
| JHU/APL paper about compiling a subset of Haskell down to
| FORTH for execution on a special-purpose processor: Andrew J.
| Harris and John R. Hayes, "Functional Programming on a Stack-
| Based Embedded Processor". (
| http://home.iae.nl/users/mhx/Forth_functional.pdf )
|
| I don't know if they pursued the use of Haskell any further
| or even if they still use FORTH. In 2009, when I read this
| paper and others from them, I discovered that the Lab had
| hosted a by-then-defunct FORTH Users Group, not exactly an
| auspicious sign.
| lisper wrote:
| A Forth REPL on Voyager would be news to me. It's possible,
| because I do know that Forth was used to program some flight
| instruments on later missions [1] but even then it didn't
| include a REPL.
|
| I don't know anything about what is happening in Haskell-
| land, but from your description it sounds like what they are
| doing is very similar. Haskell shares a lot of intellectual
| DNA with Lisp so it's not surprising that it would end up
| being used this way.
|
| [1] https://flownet.com/gat/jpl-lisp.html, see the
| "Miscellaneous stories" section.
| adamgordonbell wrote:
| Ron's story about working on the Mars Rover prototypes is mind-
| blowing to me.
|
| He used DSL's written in LISP and compiled to run on embedded
| devices and did self-driving tech all back in the 80s. Also,
| debugging software running 150 million miles away is something
| I'm sad yet relieved I'll never get to do.
|
| Also the photos he dug up and scanned are neat to see.
| tabtab wrote:
| Dave Bowman: "My God, it's full of parentheses!"
| a9h74j wrote:
| Need a photoshop where the apes in the movie 2001 are freaking
| out at a parenthesis-shaped monolith.
| lisper wrote:
| There's this:
|
| https://archive.org/details/byte-magazine-1979-08
| spzb wrote:
| Can't help but read the title as "Lisp in spaaaace". Too much
| muppets show in my youth obviously.
| AnimalMuppet wrote:
| Too much Muppets Show? There is no such thing!
| lisper wrote:
| That's how I read it too! :-)
| fithisux wrote:
| There should be a lisp only curated list like lobste.rs
| jjtheblunt wrote:
| reddit /r/lisp or similar?
___________________________________________________________________
(page generated 2022-05-03 23:00 UTC)