> Writing non-consing code is also not hard, certainly no harder than writing non-consing code in C.
I call BS on this claim. To write non-consing code in C, what functions do I need to avoid? malloc, calloc, and realloc. To avoid writing consing code in Lisp, what functions do I have to avoid? Can you list all of them for me?
> Not only is Common Lisp suitable for writing safety-critical code, it completely dominates C in every possible way.
BULLSHIT. Your extreme departure from reality makes it hard for me to respond any more politely than that.
Earlier, you cited a safety-critical system that had been written in Lisp. (I believe that you've cited it before.) They tried to re-write it in C++, and failed. You know what else I read on HN today? Banks have COBOL code that can't be re-written in something better and/or more modern. But it's not the wonderfulness of the language that's preventing it; it's that nobody understands what the code does well enough to be able to write a true functional equivalent. So, you've got a nice example, and a nice story, but it may not prove the point that you're trying to prove.
Now, what else have you got? How many safety critical systems are written in Lisp? How many of those are hard real-time systems? What are their defect rates compared to people writing MISRA C? And, if Lisp is so wonderful compared to C, how come so many more safety-critical systems are written in C? Is it because the entire profession is blind, and only you and a few enlightened ones realize how wonderful Lisp is? Or is it because people that have done this for decades see more problems with Lisp than you are aware of?
> It does say it's because of the unpredictable behavior, but the "time" part is your own extrapolation.
True. Now, in what ways do allocations behave unpredictably? Well, any particular allocation can fail due to being out of memory, and the location allocated is unpredictable. But the primary way that allocations are unpredictable is in the amount of time they take.
If you want to argue with that statement, along with your argument, tell me how many years of your career you have spent in embedded systems. And don't try to argue that embedded systems isn't what we're talking about here, just because the title says "safety critical" rather than "embedded".
> how many years of your career you have spent in embedded systems
Depends on how you count, but probably about 20. 15 of those were at NASA. Gerard Holzman (the author of the paper we're discussing) was in the office next to mine for about 3 years. Oh, and Common Lisp code that I wrote actually controlled a spacecraft back in 1999.
> Does that qualify me to talk about these things?
Yes, certainly. (Though I have been in embedded longer - 25 years. But you've been in safety-critical longer than me.) I must admit that I under-rated your experience.
What part of the stuff from that link was written in Lisp? Was it just the planner, or also the exec? That is, did it have to be real time?
And, in my previous reply, I asked a bunch of questions (besides the ones about whether you knew what you were talking about). Would you answer them?
> Politics mainly. And inertia. And the sunk cost fallacy.
I would say no, sort of, and maybe. I don't think I've ever seen a language chosen because of politics. For "inertia", I would say "conservatism" - people know that they can build systems (even safety critical ones) using C, and they know where the problems are. They don't know where the problems are using Lisp. And they don't want to take the time to learn Lisp - that's sunk cost, but whether it's a fallacy or not depends on whether Lisp really is more suited for such work than C. You assert that it is; many of us would like to see considerably more evidence before we agree.
What evidence? Maybe a few hundred hard real time systems successfully written in Lisp. (But how are we going to get them, if everybody defaults to C? I will grant you that there's a chicken-and-egg problem here...)
> > Is it because the entire profession is blind, and only you and a few enlightened ones realize how wonderful Lisp is?
> Yes. Pretty much.
Yeah... um... I think I'll just let your words speak for themselves.
I want to follow up that whole discussion by stating I really appreciate someone with actual experience in this area chiming in. NASA code attracts a huge amount of bikeshedding here.
I call BS on this claim. To write non-consing code in C, what functions do I need to avoid? malloc, calloc, and realloc. To avoid writing consing code in Lisp, what functions do I have to avoid? Can you list all of them for me?
> Not only is Common Lisp suitable for writing safety-critical code, it completely dominates C in every possible way.
BULLSHIT. Your extreme departure from reality makes it hard for me to respond any more politely than that.
Earlier, you cited a safety-critical system that had been written in Lisp. (I believe that you've cited it before.) They tried to re-write it in C++, and failed. You know what else I read on HN today? Banks have COBOL code that can't be re-written in something better and/or more modern. But it's not the wonderfulness of the language that's preventing it; it's that nobody understands what the code does well enough to be able to write a true functional equivalent. So, you've got a nice example, and a nice story, but it may not prove the point that you're trying to prove.
Now, what else have you got? How many safety critical systems are written in Lisp? How many of those are hard real-time systems? What are their defect rates compared to people writing MISRA C? And, if Lisp is so wonderful compared to C, how come so many more safety-critical systems are written in C? Is it because the entire profession is blind, and only you and a few enlightened ones realize how wonderful Lisp is? Or is it because people that have done this for decades see more problems with Lisp than you are aware of?
> It does say it's because of the unpredictable behavior, but the "time" part is your own extrapolation.
True. Now, in what ways do allocations behave unpredictably? Well, any particular allocation can fail due to being out of memory, and the location allocated is unpredictable. But the primary way that allocations are unpredictable is in the amount of time they take.
If you want to argue with that statement, along with your argument, tell me how many years of your career you have spent in embedded systems. And don't try to argue that embedded systems isn't what we're talking about here, just because the title says "safety critical" rather than "embedded".