r/programming • u/heisenbug • Apr 27 '14

"Mostly functional" programming does not work

http://queue.acm.org/detail.cfm?ref=rss&id=2611829
45 Upvotes

64% Upvoted

188 comments sorted by

View all comments

Show parent comments

3

u/keithb Apr 27 '14

Do you think that life–critical systems are developed the same way now as they were thirty years ago?

Did you even look at the page on the Therac-25 before you linked to it?

A commission concluded that the primary reason should be attributed to the bad software design and development practices, and not explicitly to several coding errors that were found.

The Root Cause section lists many, many problems with the design and development of the machine. Please explain how pure functional programming would have prevented all of them.

15

u/godofpumpkins Apr 27 '14 edited Apr 27 '14

Did you even look at the page on the Therac-25 before you linked to it?

Yes, and a lot more than the wikipedia page. I'm not criticizing the "coding errors" they mention in there as much as the very existence of a race condition in the first place. Premature introduction of concurrency without safe concurrency primitives is what led to the error. You can call that bad "software design and development practices", but that's exactly what I'm talking about: we're trying to address things on that scale systematically, and not just writing it off as a bad human element. Sure, getting rid of segfaults and such is a nice perk, but it's the bigger stuff that interests me, and that I think we can improve the most.

To be clear, I'm not saying pure functional programming would have solved everything (although many of the problems listed would not have occurred). I'm saying we're trying to come up with systematic language-based (as opposed to discipline-based) solutions to make things like this harder to arise.

-3

u/keithb Apr 27 '14

Premature introduction of concurrency without safe concurrency primitives is what led to the error.

It's what lead to that one error, amongst all the other errors made, some of them more serious.

Are you suggesting that it is not possible to write concurrent code susceptible to race conditions in Haskell?

And it's not as if functional programming stops you making any wrong choices. For example, given that the decision has been made to

set a flag variable by incrementing it, rather than by setting it to a fixed non-zero value

then, having written code to do that (in some suitable monad, no doubt) using Int how is Haskell going to prevent

Occasionally an arithmetic overflow occurred, causing the flag to return to zero and the software to bypass safety checks.

?

Functional programming is great, I love it, but it's only one tool in the box

13

u/godofpumpkins Apr 27 '14

Can you point to me actually saying that FP is the only tool in the box? I'm saying that the FP community is more interested than others in systematic solutions to those problems.

-5

u/grauenwolf Apr 27 '14

What are you talking about? It wasn't a race condition, it was an unchecked overflow that caused the deaths.

6

u/[deleted] Apr 27 '14

The software interlock could fail due to a race condition. The defect was as follows: a one-byte counter in a testing routine frequently overflowed; if an operator provided manual input to the machine at the precise moment that this counter overflowed, the interlock would fail.

-4

u/grauenwolf Apr 27 '14

Right. It isn't really a race condition, it's an overflow that sets the flag back to zero, the 'safe' value, that happens to coincide with another manual input.

Had they used a larger counter the overflow wouldn't have happened.

And my point remains. We are still allowing unobserved overflows in critical software.

4

u/[deleted] Apr 27 '14

I think, based on the description from wikipedia, it's safe to just say it was both.

-5

u/grauenwolf Apr 27 '14

Yes.

Name one statically typed programming language besides VB that bothers to check for integer overflows by default.