Live data from Hacker News

The Power of Ten – Rules for Developing Safety Critical Code

spinroot.com

71–80 of 155 posts

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

#71
post #58

- What tools do they use for error checking/linting? - Well... why C? If correctness is so important... surely there are better languages than C - not only better type systems, but also theorem proving and other fancy modern features. It doesn't even have to be garbage collected. - at the very least are they using language extensions? even gcc primitves would help!

This formatting doesn't match the rest of HN which makes it difficult to read. Is this a bug somewhere?

Some kind of unicode copy/paste hijinx, probably coming from a PDF somewhere.

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

#72

Earlier quoted context omitted.

I'm afraid I don't know what you mean by that either.

It must unknowingly be embedded-specific terminology, because I knew exactly what he was talking about.

So, what is it, then?

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

#73

Earlier quoted context omitted.

Even in C you can e.g. use singleton structs to distinguish different semantic types.

Didn't you used to be able to use typedef scalars for that? Somewhere that got lost (some name-mangling issue trumped it).

> Didn't you used to be able to use typedef scalars for that?

Oh, I was so disappointed when I realised that those aren't considered distinct types. That ruins half the use of typedef.

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

#74
post #67
post #58

Earlier quoted context omitted.

This formatting doesn't match the rest of HN which makes it difficult to read. Is this a bug somewhere?

They seem to be different Unicode codepoints: FULLWIDTH LATIN SMALL LETTER

I wonder, is that really something that should go into a character set?

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

#75
post #17

If we're talking about high reliability code, one thing claimed about Haskell, is "if it compiles, it has no bugs". How close is it to the truth ? And how close are we to having that kind of capability for real-time programming(even assuming we're willing to forsake protability, community, and maximum efficiency to some extent ) ?

It's more "If it compiles it probably does something that someone would find useful but possibly not what you actually want."

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

#76
post #2

The original paper describing and justifying these rules in more detail is at http://spinroot.com/gerard/pdf/P10.pdf , and the official document is at http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf

Thanks! We updated the link from http://www.rankred.com/nasa-coding-rules.

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

#78

Earlier quoted context omitted.

dynamic memory allocation is very much frowned upon in embedded systems, not just for strings. Everything should be static and deterministic at all times. This is the easiest/only way to ensure you have no resource issues. You should always (statically) allocate for maximum/worst case.. because you have analysed your worst-case, haven't you?

That rhetorical question touches on a very important point, and I agree 100%. Dynamic memory allocation allows programmers to absolve themselves of considering worst case (memory usage) scenarios. As long as they handle allocation failures, their program should function predictably under all memory circumstances (in reality, we know this isn’t always the case, especially when the failure occurs deep in the call stack…

true, embedded systems (and in theory server s/w) are different in a number of respects to your typical desktop-level s/w.

Embedded systems typically are not 'manned', they have to handle all issues themselves and continue providing service. Note that this does not mean "no resets".

Resets should be designed for because they will happen.

All effort should be made to make errors deterministic as (like you say) they will become a real time-suck.

IMO, servers should also be considered embedded systems and designed like this, but unfortunately the culture around server software is for very dynamic, very resource heavy and very inefficient, non-deterministic s/w.

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

#79
post #25

Earlier quoted context omitted.

Sadly quality is highly disregarded in our field. I dream of the day when not making use of contracts, static analysis and type based programming is seen as quality smell and not something that only a few are allowed to make use of.

It's not "disregarded", it's eclipsed by a need to ship often and ship a lot. There is a tendency to overstate amount of problems that come from bugs because they are painful to debug. Therefore, somewhat experienced programmers are often too defensive and suspect to paralysis by analysis (of which uber-complicated and rigid typing is a sort). Even if some advanced typing system will save a few days of debugging afte…

> paralysis by analysis (of which uber-complicated and rigid typing is a sort).

How "paralysis by analysis" has anything to do with typing? And how is typing uber-complicated to begin with? This is ultra basic logic... And why exactly you you think dynamic langages are exempt of typing?

How does all of that has anything to do with a competitor shipping "buggy RoR-based systems a few months earlier"? You can do all kind of shit even in more statically checked langages if you really don't care about quality, and ship buggy products sooner too.

How is a system that prove that some aspects of your program is free of some class of defect should be considered "training wheels"? Do you also consider that compiler warnings are a bad thing for time to market, and so should be disabled? How can you gain any time from not using an automatic checker? Your brain is faster than a microprocessor to do repetitive tasks? This makes no sense. You do not abstain to put on your seat-belt just because you thing you know how to drive, nor do you disable all safety feature of whatever equipment just because you kind of think, without even the beginning of a reasoning to backup that, that you are going to do things "faster". And while the logic telling that what you are going to do is more dangerous is immediate and irrefutable. And while the studies about costs of discovery of bugs depending on the phase of dev clear.

Arguably there are some meta-programming aspects of Ruby which can let you program faster than with a language without equivalent features. But in no way we can deduce from this that "Advanced typing/static analysis" are "training wheels". This is one the the thing that is just so wrong in our industry that I sometimes just don't really know what to answer. I mean I could as well see a claim that the earth is flat and try to convince the crazy claimer that this is not the case, but I have the feeling that people making such claims are not sensible to logic to begin with.

Post reply on HN