Comment by dahart | Hacker News Reader

Comment by dahart | Hacker News Reader

Parent Full thread

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

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…

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?

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/ for the full story.

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 ?

> 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?

Reply on news.ycombinator.com