You are wrong. And you even admit that you are wrong in your own comment:
"You can... but it's not easy"
There's a big gap between "completely unsuitable" and "not easy."
But you are wrong for an even more fundamental reason: the matter at hand is not hard-real-time cade, it is safety-critical code (re-read the title). Those are not the same thing. Safety-critical code can be and has been written in Common Lisp. Moreover, an effort to port the Common Lisp code to C++ failed. So it is manifestly untrue that Common Lisp is "completely unsuitable" for writing safety critical code.
The title says "safety critical code". But the article says no allocations, because of the unpredictable (time) behavior. So the environment that the article describes is safety-critical, and part of that is predictable (guaranteed) timing.
> You are wrong. And you even admit that you are wrong in your own comment
Do you realize that you're agreeing with me? I put that part in parentheses in for a reason...
No. I am not agreeing with you. You are wrong about everything, even the real-time part. You are even wrong when you say it's not easy to write hard-real-time code in GC'd languages. It is no harder to do that in GC'd languages than in non-GCd languages. In fact, it's easier. You are correct that it is hard to write a hard-real-time GC. But that job only has to be done once, and it has already been done so at this point it's a sunk cost. Writing non-consing code is also not hard, certainly no harder than writing non-consing code in C.
Not only is Common Lisp suitable for writing safety-critical code, it completely dominates C in every possible way. And this is not just speculation, it has been actually demonstrated in the field.
Oh:
> But the article says no allocations, because of the unpredictable (time) behavior
You're wrong about this too. It does say it's because of the unpredictable behavior, but the "time" part is your own extrapolation. The article itself says nothing about hard-real-time. The word "time" does not even appear anywhere. (Not that this matters because it is no harder, and often easier, to write hard-real-time code in Lisp as it is in C.)
> 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.
You are wrong. And you even admit that you are wrong in your own comment:
"You can... but it's not easy"
There's a big gap between "completely unsuitable" and "not easy."
But you are wrong for an even more fundamental reason: the matter at hand is not hard-real-time cade, it is safety-critical code (re-read the title). Those are not the same thing. Safety-critical code can be and has been written in Common Lisp. Moreover, an effort to port the Common Lisp code to C++ failed. So it is manifestly untrue that Common Lisp is "completely unsuitable" for writing safety critical code.