Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Power of Ten – Rules for Developing Safety Critical Code

spinroot.com

Post reply on HN
Print view View original

131–140 of 155 posts

Re: The Power of Ten – Rules for Developing Safety Critical Code

#131

Post by Bromskloss »

GregBuchholz wrote: post #114
Symmetry wrote: post #70

Regarding Rule 4 - No Large Function - I think John Carmack had a pretty good explanation on why that's not really a good thing: http://number-none.com/blow/john_carmack_on_inlined_code.htm...

>The fly-by-wire flight software for the Saab Gripen (a lightweight >fighter) went a step further. It disallowed both subroutine calls and >backward branches, except for the one at the bottom of the main loop. >Control flow went forward only. Sometimes one piece of code had to leave >a note for a later piece telling it what to do, but this worked out well >for testing: all data was allocated statically, and monitorin…

Does anyone know where this quotation comes from?

Re: The Power of Ten – Rules for Developing Safety Critical Code

#132

Post by lisper »

AnimalMuppet wrote: post #117
lisper wrote: post #110

Rule 0: don't write safety-critical code in C.

Nice snark, I guess, but... did you actually read the article? One of the reasons for C is that the tooling around it gives you much more support. For safety critical code, you need that, because programmers make mistakes, no matter what the language. So if you write safety critical code in Haskell, say, you won't have a large number of the holes that C gives you. But for safety critical systems, their rules say that…

> did you actually read the article?

Yes. I used to work with the person who wrote it.

> One of the reasons for C is that the tooling around it gives you much more support.

That's because C is an unsafe language, so to write safe code you need that tooling. If you start with a safe language the need for that tooling simply evaporates because many of the mistakes that the tooling is designed to catch are simply not possible.

> For safety critical code, you need that, because programmers make mistakes, no matter what the language.

That's certainly true, but many of those mistakes are mistakes in the rendering of the desired semantics into code. Neither rules nor tooling can catch those kinds of mistakes.

> But for safety critical systems, their rules say that you can't write code that has even the possibility of falling into those holes. That makes C much safer.

No, it doesn't. All of the rules that are not specific to C can be equally well applied to any other language.

> So, snark aside, what is your actual alternative that you recommend?

Good heavens, just about anything is better than C if what you care about is safety. Ada. Java. Scheme. Haskell. OCaml. Python. Go. Swift. Common Lisp.

Re: The Power of Ten – Rules for Developing Safety Critical Code

#133

Post by AnimalMuppet »

lisper wrote: post #132
AnimalMuppet wrote: post #117

Earlier quoted context omitted.

Nice snark, I guess, but... did you actually read the article? One of the reasons for C is that the tooling around it gives you much more support. For safety critical code, you need that, because programmers make mistakes, no matter what the language. So if you write safety critical code in Haskell, say, you won't have a large number of the holes that C gives you. But for safety critical systems, their rules say that…

> did you actually read the article? Yes. I used to work with the person who wrote it. > One of the reasons for C is that the tooling around it gives you much more support. That's because C is an unsafe language, so to write safe code you need that tooling. If you start with a safe language the need for that tooling simply evaporates because many of the mistakes that the tooling is designed to catch are simply not po…

Well, of those, Java, Haskell, and Lisp (at a minimum) are completely unsuitable due to allocation and, worse, garbage collection. In a hard real-time system those are a deal breaker. (Usually. You can have deterministic allocators and guaranteed-worst-response-time garbage collectors, and then you can still prove you can meet your timing requirements, but it's not easy. Or, you can try to write those languages in a way that they never allocate after initialization, which might be possible, at least for Java.)

Python? Can't you get "method not supported" (or whatever the technical term is within Python)? That's not safety, by any stretch of the imagination. Or is there some way to prove that it can't happen, by some kind of (ahem) external tooling?

Ada I could accept. Go and Swift might be suitable. I don't know enough about Scheme or OCaml to comment.

Re: The Power of Ten – Rules for Developing Safety Critical Code

#134

Post by lisper »

AnimalMuppet wrote: post #133
lisper wrote: post #132

Earlier quoted context omitted.

> did you actually read the article? Yes. I used to work with the person who wrote it. > One of the reasons for C is that the tooling around it gives you much more support. That's because C is an unsafe language, so to write safe code you need that tooling. If you start with a safe language the need for that tooling simply evaporates because many of the mistakes that the tooling is designed to catch are simply not po…

Well, of those, Java, Haskell, and Lisp (at a minimum) are completely unsuitable due to allocation and, worse, garbage collection. In a hard real-time system those are a deal breaker. (Usually. You can have deterministic allocators and guaranteed-worst-response-time garbage collectors, and then you can still prove you can meet your timing requirements, but it's not easy. Or, you can try to write those languages in a…

> completely unsuitable

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.

Re: The Power of Ten – Rules for Developing Safety Critical Code

#135

Post by AnimalMuppet »

lisper wrote: post #134
AnimalMuppet wrote: post #133

Earlier quoted context omitted.

Well, of those, Java, Haskell, and Lisp (at a minimum) are completely unsuitable due to allocation and, worse, garbage collection. In a hard real-time system those are a deal breaker. (Usually. You can have deterministic allocators and guaranteed-worst-response-time garbage collectors, and then you can still prove you can meet your timing requirements, but it's not easy. Or, you can try to write those languages in a…

> completely unsuitable 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 writ…

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

Re: The Power of Ten – Rules for Developing Safety Critical Code

#136

Post by lisper »

AnimalMuppet wrote: post #135
lisper wrote: post #134

Earlier quoted context omitted.

> completely unsuitable 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 writ…

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

> Do you realize that you're agreeing with me?

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

Re: The Power of Ten – Rules for Developing Safety Critical Code

#137

Post by AnimalMuppet »

lisper wrote: post #136
AnimalMuppet wrote: post #135

Earlier quoted context omitted.

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

> Do you realize that you're agreeing with me? 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 o…

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

Re: The Power of Ten – Rules for Developing Safety Critical Code

#138

Post by lisper »

AnimalMuppet wrote: post #137
lisper wrote: post #136

Earlier quoted context omitted.

> Do you realize that you're agreeing with me? 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 o…

> 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 dominate…

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

https://ti.arc.nasa.gov/tech/asr/planning-and-scheduling/rem...

Does that qualify me to talk about these things?

Re: The Power of Ten – Rules for Developing Safety Critical Code

#139

Post by AnimalMuppet »

lisper wrote: post #138
AnimalMuppet wrote: post #137

Earlier quoted context omitted.

> 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 dominate…

> 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. https://ti.arc.nasa.gov/tech/asr/planning-and-scheduling/rem... Does that qualify me…

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

Re: The Power of Ten – Rules for Developing Safety Critical Code

#140

Post by lisper »

AnimalMuppet wrote: post #139
lisper wrote: post #138

Earlier quoted context omitted.

> 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. https://ti.arc.nasa.gov/tech/asr/planning-and-scheduling/rem... Does that qualify me…

> 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 (besi…

> What part of the stuff from that link was written in Lisp?

All of it. (Except for an IPC system which was written in C. See https://www.youtube.com/watch?v=_gZK0tW8EhQ if you want to know the whole story.)

> Would you answer them?

I'll answer a few of them.

> if Lisp is so wonderful compared to C, how come so many more safety-critical systems are written in C?

Politics mainly. And inertia. And the sunk cost fallacy.

> Is it because the entire profession is blind, and only you and a few enlightened ones realize how wonderful Lisp is?

Yes. Pretty much.

> Or is it because people that have done this for decades see more problems with Lisp than you are aware of?

They, like you, think they see problems, but they, like you, are wrong.

Tellingly, none of the people who think there are problems with Lisp actually know Lisp.

Post reply on HN