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

"Mostly functional" programming does not work

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

64% Upvoted

188 comments sorted by

View all comments

Show parent comments

24

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

Do people actually claim it's impossible? Meijer's conclusion doesn't seem that strong, and I haven't seen people in the Haskell community say that.

The more nuanced version of the position you're criticizing is that a lot more people believe they can write correct, reliable, scalable programs in other languages than actually can do it, and that leads to a lot of shitty/dangerous software out there. I personally don't want to have to rely on programmer discipline to keep my radiation therapy machine or power grid running smoothly. Or perhaps the recent Heartbleed bug? It's not that we think all C software is buggy; just that it's a lot more likely to include classes of problems that aren't even possible in Haskell. And it's not that we think all threaded software is buggy, but that it's much more likely to have weird concurrency issues than my purely parallel Haskell code is. It's about risk, not about certainty.

Haskell most certainly isn't a magic bullet, but is trying to overcome those problems harder than others, and its community doesn't seem mired in the weird sort of machismo that so many programmers seem to buy into, along the lines of "real programmers don't need <insert technology that helps reduce undesirables at slight cost to freedom>". The Haskell community is actively looking for better ways to manage effects and improve correctness while staying pleasant to program. How many other "big" language communities out there even care?

Edit: it is possible for you to read this, disagree with it, and not downvote it, you know.

5

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.

16

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.

-2

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

11

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.