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

121–130 of 155 posts

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

#121

Post by AnimalMuppet »

Jtsummers wrote: post #92
elcapitan wrote: post #46

Earlier quoted context omitted.

Just out of curiosity, why is that harder than writing a static analysis that determines if a loop with condition will finish?

The sort of software these rules are intended for run in constrained environments. The other question besides "Will this loop/recursion terminate?" is "Will we blow up the stack?". Ignoring the time required to establish a new stackframe (versus a mere jump for a loop), the creation of a stack frame uses more memory. The less memory you can use, while still producing maintainable code, the better. And an easy way to…

And tail recursion is equivalent to a loop, but a form of loop which breaks Rule 2.

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

#122

Post by ska »

betenoire wrote: post #105
davidgrenier wrote: post #38

Earlier quoted context omitted.

I think you should take what he said as saying we should get rid of those

> get rid of those There are many legitimate uses for scripting languages. It would be impossible and undesirable to get rid of them.

weakly typed != scripting.

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

#123

Post by astrange »

Bromskloss wrote: post #74
drauh wrote: post #67

Earlier quoted context omitted.

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

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

It was needed for JIS compatibility, since they encode halfwidth and fullwidth versions of kana and English characters, because having different fonts for them was too expensive.

Also it's needed for this tweet.

https://twitter.com/pisscop/status/67709754859995136

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

#124

Post by Jtsummers »

AnimalMuppet wrote: post #121
Jtsummers wrote: post #92

Earlier quoted context omitted.

The sort of software these rules are intended for run in constrained environments. The other question besides "Will this loop/recursion terminate?" is "Will we blow up the stack?". Ignoring the time required to establish a new stackframe (versus a mere jump for a loop), the creation of a stack frame uses more memory. The less memory you can use, while still producing maintainable code, the better. And an easy way to…

And tail recursion is equivalent to a loop, but a form of loop which breaks Rule 2 .

Tali recursion should be equivalent to a loop, if the language compiler/implementation offers TCE/TCO. C does not guarantee this.

But I'll also point out, tail recursion could be statically analyzed in the same way that you would with a for loop (for the purpose of Rule 2). As long as it is structured in a way that demonstrates that:

1) Forward progress is always being made (that is, there's an iteration/index parameter that always increases/decreases monotonically) towards a bound: void f(state,n) { if(n > MAX) return; f(g(state),n+1); }

2) There's a single entry point which initiates the recursion (loop) with 0 (or MAX if you're decrementing, or whatever): void start(state) { f(state,0); }

Both can be demonstrated (with code structured like the above) statically.

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

#125

Post by AnimalMuppet »

Jtsummers wrote: post #124
AnimalMuppet wrote: post #121

Earlier quoted context omitted.

And tail recursion is equivalent to a loop, but a form of loop which breaks Rule 2 .

Tali recursion should be equivalent to a loop, if the language compiler/implementation offers TCE/TCO. C does not guarantee this. But I'll also point out, tail recursion could be statically analyzed in the same way that you would with a for loop (for the purpose of Rule 2). As long as it is structured in a way that demonstrates that: 1) Forward progress is always being made (that is, there's an iteration/index parame…

All true.

A modified C compiler could be built that would do TCO. But, for this kind of application, it would mean that you'd have to re-validate your compiler, so that's pretty much not going to happen.

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

#126

Post by Jtsummers »

AnimalMuppet wrote: post #125
Jtsummers wrote: post #124

Earlier quoted context omitted.

Tali recursion should be equivalent to a loop, if the language compiler/implementation offers TCE/TCO. C does not guarantee this. But I'll also point out, tail recursion could be statically analyzed in the same way that you would with a for loop (for the purpose of Rule 2). As long as it is structured in a way that demonstrates that: 1) Forward progress is always being made (that is, there's an iteration/index parame…

All true. A modified C compiler could be built that would do TCO. But, for this kind of application, it would mean that you'd have to re-validate your compiler, so that's pretty much not going to happen.

Looking it up, it seems that GCC (at least) presently does do (at some optimization levels) tail call elimination. Others probably do as well. I guess I've never looked it up because it was never relevant (if I'm using C, I might as well use for loops, they're at least as clear as the equivalent tail recursive function).

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

#127

Post by betenoire »

pjmlp wrote: post #109
betenoire wrote: post #105

Earlier quoted context omitted.

> get rid of those There are many legitimate uses for scripting languages. It would be impossible and undesirable to get rid of them.

Scripting languages are just that, for plain scripts, not full blown applications.

that's my point. you don't get rid of the tools you use incorrectly, you learn to use them correctly.

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

#128

Post by pjmlp »

betenoire wrote: post #127
pjmlp wrote: post #109

Earlier quoted context omitted.

Scripting languages are just that, for plain scripts, not full blown applications.

that's my point. you don't get rid of the tools you use incorrectly, you learn to use them correctly.

I was talking in the context of making full stack applications, not scripts for copying files around, automate software installation and such.

And even there I am most likely to use a ML derivative language than Perl, Python or something else.

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

#129

Post by brianwawok »

betenoire wrote: post #127
pjmlp wrote: post #109

Earlier quoted context omitted.

Scripting languages are just that, for plain scripts, not full blown applications.

that's my point. you don't get rid of the tools you use incorrectly, you learn to use them correctly.

What is the correct use of node.js? I claim there is none.

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

#130

Post by pjmlp »

marcosdumay wrote: post #112
xorblurb wrote: post #79

Earlier quoted context omitted.

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

> 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". Lots of people do. Yes, they often turn out dead, or missing limbs. But it's a fact that they do, to the point that industries have to p…

> Developers have a similar mindset, just way less dangerous.

Less dangerous? Not really.

- Therac-25

- Ariane 5

- Airbus A400M crash

- JAS 39 Gripen crash

- Chinook helicopter crash

- Patriot missile failure

Just a few examples as I am not bothered to provide an exhaustive list.

Post reply on HN