3 ms·

NASA Programmer Remembers Debugging Lisp in Deep Space

33 points by kungfudoi 4y ago

dahart 4y ago
I wonder if this project had some bearing on NASA later publishing the infamous “Power of 10” rules https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev... > Lisp also has automatic memory management. “It’s just so much faster and easier to get things done when the language you’re using provides you with some of these high level abstractions While the story is rooting for Lisp, it concretely demonstrates why using a garbage collected high level scripting language is dangerous for embedded devices operating remotely. It’s true in my experience that Lisp and other languages like Python and JavaScript are faster to develop in, and I’d even go so far as to say more fun, but they hide too many things from the programmer (which is precisely why they’re fast & fun to use). The Power of Ten seems to be centered on the idea that the code should be so simple that you can understand the complete operation and effect on the system of every single line.
- bsaul 4y ago
  I would have agreed with you if the problem they faced was a memory allocation issue. However, in the case of deadlocks and race conditions, i don’t think low-level languages make the problem any easier to understand, quite the contrary i’d say…
  - dahart 4y ago
    Are you sure it wan’t memory allocation related? I don’t know the details and the story didn’t say what the library call was doing that caused the unexpected problem. Are you saying this incident wasn’t part of the motivation for Powers of Ten, which was published a few years after this happened?
    - michaelanckaert 4y ago
      If I recall correctly, Ron used Lisp to compile Lisp code to machine code that could run on the embedded systems. Listen to https://corecursive.com/lisp-in-space-with-ron-garret/ https://corecursive.com/lisp-in-space-with-ron-garret/ for the full story.
    - bsaul 4y ago
      No i'm not sure, that's just what i understood from reading the article, which only mentions race conditions and something looking like a deadlock. You think it could be a deadlock in the memory allocator ?
      - dahart 4y ago
        > You think it could be a deadlock in the the memory allocator? Absolutely it could be allocator related! I didn’t suggest it was “in the allocator” specifically, but regardless the answer is absolutely yes in the absence of any other information, it absolutely could be failing to make progress due to the memory allocator, in the allocator, or due to the garbage collector or interactions with the garbage collector (assuming they had gc), or it could be interactions between the user space code and the library/kernel memory management code. You can Google “memory allocation deadlock” and notice how many results you get. Add “lisp” to your query and you’ll even find modern examples of it. (But note that because library code was involved, and because they were transpiling lisp into machine code and not using the lisp run-time, the reason for deadlock could be related to non-lisp code.) The programs could have unknowingly used a non-thread-safe allocator, they could have been low on memory causing a free-alloc type of deadlock, or they could have caused deadlock in their own code managing which thread or process was trying to allocate memory. Any of these scenarios are reason enough to conclude, like they eventually did, that using dynamic memory is dangerous for safety critical systems. Even just the temptation to reach for a library function is something a higher level language encourages, right?
michaelanckaert 4y ago
This blog post is mostly a recap of the Corecursive podcast in which Ron Garret talks about his experience with Lisp at the JPL: https://corecursive.com/lisp-in-space-with-ron-garret/ https://corecursive.com/lisp-in-space-with-ron-garret/
rurban 4y ago
He also remembers somewhere else how he wrote Google AdSense. The thing that made Google rich.
- michaelanckaert 4y ago
  If you're interested in his stories regarding Google and AdWords (not AdSense), check out https://flownet.com/ron/xooglers.html https://flownet.com/ron/xooglers.html

33 points by kungfudoi 4y ago

I wonder if this project had some bearing on NASA later publishing the infamous “Power of 10” rules https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev... > Lisp also has automatic memory management. “It’s just so much faster and easier to get things done when the language you’re using provides you with some of these high level abstractions While the story is rooting for Lisp, it concretely demonstrates why using a garbage collected high level scripting language is dangerous for embedded devices operating remotely. It’s true in my experience that Lisp and other languages like Python and JavaScript are faster to develop in, and I’d even go so far as to say more fun, but they hide too many things from the programmer (which is precisely why they’re fast & fun to use). The Power of Ten seems to be centered on the idea that the code should be so simple that you can understand the complete operation and effect on the system of every single line.

bsaul 4y ago
I would have agreed with you if the problem they faced was a memory allocation issue. However, in the case of deadlocks and race conditions, i don’t think low-level languages make the problem any easier to understand, quite the contrary i’d say…
- dahart 4y ago
  Are you sure it wan’t memory allocation related? I don’t know the details and the story didn’t say what the library call was doing that caused the unexpected problem. Are you saying this incident wasn’t part of the motivation for Powers of Ten, which was published a few years after this happened?
  - michaelanckaert 4y ago
    If I recall correctly, Ron used Lisp to compile Lisp code to machine code that could run on the embedded systems. Listen to https://corecursive.com/lisp-in-space-with-ron-garret/ https://corecursive.com/lisp-in-space-with-ron-garret/ for the full story.
  - bsaul 4y ago
    No i'm not sure, that's just what i understood from reading the article, which only mentions race conditions and something looking like a deadlock. You think it could be a deadlock in the memory allocator ?
    - dahart 4y ago
      > You think it could be a deadlock in the the memory allocator? Absolutely it could be allocator related! I didn’t suggest it was “in the allocator” specifically, but regardless the answer is absolutely yes in the absence of any other information, it absolutely could be failing to make progress due to the memory allocator, in the allocator, or due to the garbage collector or interactions with the garbage collector (assuming they had gc), or it could be interactions between the user space code and the library/kernel memory management code. You can Google “memory allocation deadlock” and notice how many results you get. Add “lisp” to your query and you’ll even find modern examples of it. (But note that because library code was involved, and because they were transpiling lisp into machine code and not using the lisp run-time, the reason for deadlock could be related to non-lisp code.) The programs could have unknowingly used a non-thread-safe allocator, they could have been low on memory causing a free-alloc type of deadlock, or they could have caused deadlock in their own code managing which thread or process was trying to allocate memory. Any of these scenarios are reason enough to conclude, like they eventually did, that using dynamic memory is dangerous for safety critical systems. Even just the temptation to reach for a library function is something a higher level language encourages, right?

michaelanckaert 4y ago

This blog post is mostly a recap of the Corecursive podcast in which Ron Garret talks about his experience with Lisp at the JPL: https://corecursive.com/lisp-in-space-with-ron-garret/ https://corecursive.com/lisp-in-space-with-ron-garret/

rurban 4y ago

He also remembers somewhere else how he wrote Google AdSense. The thing that made Google rich.

michaelanckaert 4y ago
If you're interested in his stories regarding Google and AdWords (not AdSense), check out https://flownet.com/ron/xooglers.html https://flownet.com/ron/xooglers.html