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

81–90 of 155 posts

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

#81

Post by DominikR »

Recently there was a thread here where many argued against some company owner that has set the objective that the code created by his employees should be as simple as possible.

Often the arguments boiled down to: It looks only clever if the skill level of your employees is too low, you should work on that.

When I look now at the rules that NASA enforces, it seems to me that their objective is to prevent bugs by not allowing code that is overly complex and I doubt it's because their engineers are not clever enough.

In fact I believe that it takes a lot of cleverness to create code that seems so simple that you don't even need to read the documentation.

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

#82

Post by pjmlp »

cema wrote: post #37
pjmlp wrote: 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.

Type based programming does not quite work in weakly typed languages.

Which I am not a big fan of.

I rather use the Algol and ML family of languages, when given the option.

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

#83

Post by guntars »

sctb wrote: post #76
ranko wrote: 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 .

I understand the need for linking to the original source, but I just looked at both and the latter is arguably harder to read.

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

#84

Post by cmpb »

optforfon wrote: post #55

- What tools do they use for error checking/linting? - Well... why C？ If ｃｏｒｒｅｃｔｎｅｓｓ ｉｓ ｓｏ ｉｍｐｏｒｔａｎｔ．．． ｓｕｒｅｌｙ ｔｈｅｒｅ ａｒｅ ｂｅｔｔｅｒ ｌａｎｇｕａｇｅｓ ｔｈａｎ Ｃ － not only better type systems, but also theorem proving and other fancy modern features. It doesn't even have to be garbage collected. － ａｔ ｔｈｅ ｖｅｒｙ ｌｅａｓｔ ａｒｅ ｔｈｅｙ ｕｓｉｎｇ ｌａｎｇｕａｇｅ ｅｘｔｅｎｓｉｏｎｓ？ ｅｖｅｎ ｇｃｃ ｐｒｉｍｉｔｖｅｓ ｗｏｕｌｄ ｈｅｌｐ！

JPL's safety-critical programming seems like a really good place for Rust (https://www.rust-lang.org), given that Rust has an upfront focus on safety.

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

#86

Post by TickleSteve »

Bromskloss wrote: post #72
vonmoltke wrote: post #66

Earlier quoted context omitted.

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

So, what is it, then?

what is a task/thread/process?

where do I start.... a processor naturally has one thread of control, i.e. it executes instructions sequentially.

To simulate multiple things happening at a time a context-switcher periodically saves and restores the current processor state and switches to another sequence.

Each sequence is a thread-of-control... commonly known as a thread (or task, or process).

...and this isn't embedded-specific, just computer-science specific.

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

#87

Post by optforfon »

delinka wrote: post #58
optforfon wrote: post #55

- What tools do they use for error checking/linting? - Well... why C？ If ｃｏｒｒｅｃｔｎｅｓｓ ｉｓ ｓｏ ｉｍｐｏｒｔａｎｔ．．． ｓｕｒｅｌｙ ｔｈｅｒｅ ａｒｅ ｂｅｔｔｅｒ ｌａｎｇｕａｇｅｓ ｔｈａｎ Ｃ － not only better type systems, but also theorem proving and other fancy modern features. It doesn't even have to be garbage collected. － ａｔ ｔｈｅ ｖｅｒｙ ｌｅａｓｔ ａｒｅ ｔｈｅｙ ｕｓｉｎｇ ｌａｎｇｕａｇｅ ｅｘｔｅｎｓｉｏｎｓ？ ｅｖｅｎ ｇｃｃ ｐｒｉｍｉｔｖｅｓ ｗｏｕｌｄ ｈｅｌｐ！

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

oh, sorry, has to due with the way windows switches between chinese and english. Sometimes it goes into a weird mode monospaced mode for some reason. Thought that would get stripped

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

#88

Post by paulryanrogers »

finishingmove wrote: post #85

> a function shouldn’t have more than 60 lines of code. I started having headache spikes after reading this sentence that refers to keeping functions "short", in the article about safety critical programs.

While the embedded world does have some hard depth limits, my experience has been that the readability of breaking up a function are worth it. This seems especially true when the nested functions are carefully named.

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

#89

Post by akavi »

mk89 wrote: post #42
lambdadmitry wrote: post #30

Earlier quoted context omitted.

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…

> ... it doesn't matter if a competitor ships buggy RoR-based systems a few months earlier. You hit the nail on the head! However, I would like to mention that competition is only one very important factor. I'd add that IT is a cost as it is a baker for a bakery, a cook for a restaurant, a mechanic for a repair shop. Do you want to be the n.1 restaurant? Then you must pay, so that your business is good food , not mar…

> Do you want to be the n.1 restaurant?

Depends on what you mean by "n.1". The "n.1" restaurant in terms of monetary value is McDonalds. They do market (heavily). They don't pay for the best cook (not anywhere near). And they don't have the best recipes. But they are wildly successful. Conversely, michelin star restaurants go bankrupt all the time.

There's nothing wrong with aspiring to produce michelin star code. But as McDonalds shows, you can be incredibly ambitious and long-lasting with quality being at best a secondary priority.

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

#90

Post by dragonwriter »

akavi wrote: post #89
mk89 wrote: post #42

Earlier quoted context omitted.

> ... it doesn't matter if a competitor ships buggy RoR-based systems a few months earlier. You hit the nail on the head! However, I would like to mention that competition is only one very important factor. I'd add that IT is a cost as it is a baker for a bakery, a cook for a restaurant, a mechanic for a repair shop. Do you want to be the n.1 restaurant? Then you must pay, so that your business is good food , not mar…

> Do you want to be the n.1 restaurant? Depends on what you mean by "n.1". The "n.1" restaurant in terms of monetary value is McDonalds. They do market (heavily). They don't pay for the best cook (not anywhere near). And they don't have the best recipes. But they are wildly successful. Conversely, michelin star restaurants go bankrupt all the time. There's nothing wrong with aspiring to produce michelin star code. Bu…

> The "n.1" restaurant in terms of monetary value is McDonalds.

No, the No. 1 franchised chain of restaurants is McDonald's; there's a pretty big difference between the No. 1 restaurant and the No. 1 chain of restaurants.

> But they are wildly successful.

The chain has, over its lifetime, been wildly successful, a success initially fueled by a reputation for extremely high quality, consistency, and efficient service compared to the greasy-spoon diners that were the mainstay of low-cost restaurant food at the time of their initial growth; the recent history is something a bit different (they have, IIRC, recently ended a period of year-over-year drops in same-restaurant sales by, among other things, significantly cutting the number of restaurants, particularly the corporate-owned rather than franchised ones.)

> Conversely, michelin star restaurants go bankrupt all the time.

So do individual (independently owned and operated) McDonald's restaurants.

> But the goal of most companies isn't critical accolades, it's to make money.

Yeah, but McDonald's didn't make more money than other restaurants by skimping on quality, they made more money by being successful based on quality, and moving quickly with that success to branch out to other locations rather than merely saturated a single market, and by offloading much of the risk (and some of the rewards) of expansion to fee-paying franchisees, which is what differentiates them from single-location restaurants that are trying to extract maximum value from a particular local market.

Trying to generalize from this to say anything about succeeding in the software market is probably pointless, mostly resulting in very bad analogies.

Post reply on HN