8 ms·

Ron Garret here. AMA.

by lisper 5y ago

jrumbut 5y ago
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 5y ago
  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 5y ago
    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/ 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.
GenericJam 5y ago
Is Lisp + message passing a bridge too far? ie https://lfe.io/ https://lfe.io/ Does Lisp on the BEAM hold any appeal for you?
- lisper 5y ago
  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.
  - samatman 5y ago
    BEAM is the Erlang VM so you covered the question nicely.
  - GenericJam 5y ago
    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).
mananaysiempre 5y ago
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.
- lisper 5y ago
  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 https://flownet.com/gat/jpl-lisp.html, see the "Miscellaneous stories" section.
- mek6800d2 5y ago
  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 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.
  - 5y ago
tosh 5y ago
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 https://flownet.com/gat/jpl-lisp.html
- lisper 5y ago
  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 5y ago
    love it!
  - oumua_don17 5y ago
    >> have a part-time gig at a chip manufacturer who uses Common Lisp Is this design tool being actively developed or does the company want to phase it out eventually? Also sorry to ask as it may not be in this spirit of this thread but are there any open roles for a CL developer on this project?
    - lisper 5y ago
      > Is this design tool being actively developed or does the company want to phase it out eventually? The tool is called Meta [1] and it was originally developed at a startup called Barefoot Networks which was recently acquired by Intel [2]. Whether Intel keeps it or not is still TBD. > Also sorry to ask as it may not be in this spirit of this thread but are there any open roles for a CL developer on this project? Possibly. Drop me a line if you're interested. --- [1] https://www.youtube.com/watch?v=oGQd-suLvzQ https://www.youtube.com/watch?v=oGQd-suLvzQ [2] https://newsroom.intel.com/editorials/intel-acquire-barefoot-networks/ https://newsroom.intel.com/editorials/intel-acquire-barefoot...
vivab0rg 5y ago
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 5y ago
  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 5y ago
    > 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 5y ago
      LMK if there's anything I can do to help with that.
    - trenchgun 5y ago
      At least it's not Java.
    - dunefox 5y ago
      Racket might be an easier sell, especially when it comes to tooling since it's much easier to pick up for one course.
leobg 5y ago
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 5y ago
  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.
  - leobg 5y ago
    Makes sense. Thank you!
    - lisper 5y ago
      You bet.
  - xkriva11 5y ago
    ...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.
kagevf 5y ago
These days we would use SLIME and SWANK to connect to a remote image. What was the setup used back then?
- lisper 5y ago
  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 5y ago
    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 ...
    - abecedarius 5y ago
      Right, it didn't exist yet. (The future author of SLIME was a friend when I was hired at JPL, so the timeline's very clear in my memory.)
outworlder 5y ago
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).
- abecedarius 5y ago
  Sorry to disappoint you more, but there was even a Scheme dialect that another JPL researcher had invented, which never came out as far as I know. (I contributed a bit to it, but left for silicon valley, and I think at that point it got mothballed. Wish I had a copy.)
- lisper 5y ago
  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.
  - outworlder 5y ago
    Thank you!
    - lisper 5y ago
      You bet!
- costigan 5y ago
  The canonical references (e.g., http://www.ai.mit.edu/courses/6.834J-f01/Williams-remote-agent-aij98.pdf http://www.ai.mit.edu/courses/6.834J-f01/Williams-remote-age...) are pretty good. If you are interested in diving very deeply into the topic, I think you'd be better off going through the work that Brian Williams has been doing since he worked on Remote Agent (https://people.csail.mit.edu/williams/Web%20site/papers.shtml https://people.csail.mit.edu/williams/Web%20site/papers.shtm...). While this more recent work reflects his individual perspective and not the ideas of his remote agent collaborators, it is a rich and detailed body of work that can be studied. Brian's collaborators at NASA Ames mostly left Ames and went on to work on a wide variety of other interesting projects. At JPL, some of the ideas in Remote Agent went into a large project called the Mission Data System. I only know about this from a distance, but my impression is that this was a rethinking of how to build spacecraft flight software from the ground up to have the flexibility that Remote Agent sought while also sticking close to JPL's software development and testing methodology. It's described here: https://mds.jpl.nasa.gov/public/ https://mds.jpl.nasa.gov/public/

Ron Garret here. AMA.

by lisper 5y ago

Ron Garret here. AMA.

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 5y ago
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 5y ago
  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/ 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.

GenericJam 5y ago

Is Lisp + message passing a bridge too far? ie https://lfe.io/ https://lfe.io/ Does Lisp on the BEAM hold any appeal for you?

lisper 5y ago
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.
- samatman 5y ago
  BEAM is the Erlang VM so you covered the question nicely.
- GenericJam 5y ago
  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).

mananaysiempre 5y ago

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.

lisper 5y ago
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 https://flownet.com/gat/jpl-lisp.html, see the "Miscellaneous stories" section.
mek6800d2 5y ago
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 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.
- 5y ago

tosh 5y ago

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 https://flownet.com/gat/jpl-lisp.html

lisper 5y ago
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 5y ago
  love it!
- oumua_don17 5y ago
  >> have a part-time gig at a chip manufacturer who uses Common Lisp Is this design tool being actively developed or does the company want to phase it out eventually? Also sorry to ask as it may not be in this spirit of this thread but are there any open roles for a CL developer on this project?
  - lisper 5y ago
    > Is this design tool being actively developed or does the company want to phase it out eventually? The tool is called Meta [1] and it was originally developed at a startup called Barefoot Networks which was recently acquired by Intel [2]. Whether Intel keeps it or not is still TBD. > Also sorry to ask as it may not be in this spirit of this thread but are there any open roles for a CL developer on this project? Possibly. Drop me a line if you're interested. --- [1] https://www.youtube.com/watch?v=oGQd-suLvzQ https://www.youtube.com/watch?v=oGQd-suLvzQ [2] https://newsroom.intel.com/editorials/intel-acquire-barefoot-networks/ https://newsroom.intel.com/editorials/intel-acquire-barefoot...

vivab0rg 5y ago

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 5y ago
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 5y ago
  > 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 5y ago
    LMK if there's anything I can do to help with that.
  - trenchgun 5y ago
    At least it's not Java.
  - dunefox 5y ago
    Racket might be an easier sell, especially when it comes to tooling since it's much easier to pick up for one course.

leobg 5y ago

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 5y ago
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.
- leobg 5y ago
  Makes sense. Thank you!
  - lisper 5y ago
    You bet.
- xkriva11 5y ago
  ...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.

kagevf 5y ago

These days we would use SLIME and SWANK to connect to a remote image. What was the setup used back then?

lisper 5y ago
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 5y ago
  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 ...
  - abecedarius 5y ago
    Right, it didn't exist yet. (The future author of SLIME was a friend when I was hired at JPL, so the timeline's very clear in my memory.)

outworlder 5y ago

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

abecedarius 5y ago
Sorry to disappoint you more, but there was even a Scheme dialect that another JPL researcher had invented, which never came out as far as I know. (I contributed a bit to it, but left for silicon valley, and I think at that point it got mothballed. Wish I had a copy.)
lisper 5y ago
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.
- outworlder 5y ago
  Thank you!
  - lisper 5y ago
    You bet!
costigan 5y ago
The canonical references (e.g., http://www.ai.mit.edu/courses/6.834J-f01/Williams-remote-agent-aij98.pdf http://www.ai.mit.edu/courses/6.834J-f01/Williams-remote-age...) are pretty good. If you are interested in diving very deeply into the topic, I think you'd be better off going through the work that Brian Williams has been doing since he worked on Remote Agent (https://people.csail.mit.edu/williams/Web%20site/papers.shtml https://people.csail.mit.edu/williams/Web%20site/papers.shtm...). While this more recent work reflects his individual perspective and not the ideas of his remote agent collaborators, it is a rich and detailed body of work that can be studied. Brian's collaborators at NASA Ames mostly left Ames and went on to work on a wide variety of other interesting projects. At JPL, some of the ideas in Remote Agent went into a large project called the Mission Data System. I only know about this from a distance, but my impression is that this was a rethinking of how to build spacecraft flight software from the ground up to have the flexibility that Remote Agent sought while also sticking close to JPL's software development and testing methodology. It's described here: https://mds.jpl.nasa.gov/public/ https://mds.jpl.nasa.gov/public/