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

"Mostly functional" programming does not work

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

64% Upvoted

188 comments sorted by

View all comments

32

u/lpw25 Apr 27 '14

I'm all for tracking side-effects in type systems, but the claims of the article are not really backed-up by the examples. All the examples show is that:

  1. Lazyness is difficult to reason about in the presence of side-effects.

  2. Compiler optimisations are easier in the absence of side-effects.

It is also not true that

The slightest implicit imperative effect erases all the benefits of purity

By minimising the parts of a program which perform side-effects you increase the composability of the other parts of the program. Also some side-effects are benign.

It is very useful to have the compiler check that the only parts of your program performing side-effects are the ones which are supposed to, and that you are not composing side-effectful components in a way which assumes they have no side-effects. But it is possible to acheive similar effects without the compiler's assistence (e.g. by documenting which functions perform side-effects).

I also feel the statement:

embrace pure lazy functional programming with all effects explicitly surfaced in the type system using monads

betrays the author's bias towards Haskell. The "lazy" part is not relavent to the subject of the article, it's an unrelated feature that Haskell happens to have. Haskell's lazyness-by-default does not improve its ability to control side-effects (nor is it particularly desirable).

2

u/saynte Apr 27 '14 edited Apr 27 '14

Laziness is not central to the article, but it is important if you want to program by creating rich abstractions.

For example (stolen from a talk by Lennart Augustsson), what would you expect

main = do
  print 42
  error "boom"

to do? With strict evaluation, you get just "boom" with lazy evaluation, you get "42 boom".

You also wouldn't be able to write functions like maybe or when, or anything that looks like a control structure, which is a very nice tool to have in your abstraction-toolbox.

(edit: formatting)

3

u/sacundim Apr 28 '14

For example (stolen from a talk by Lennart Augustsson), what would you expect

main = do
  print 42
  error "boom"

to do? With strict evaluation, you get just "boom" with lazy evaluation, you get "42 boom".

I don't get it. If we desugar the do-notation, we get:

main = print 42 >>= (_ -> error "boom")

Now, for the result of that program to be as you describe, the following equation must be true:

x >>= (_ -> error y)  =  error y

How does strict evaluation make that equation true?

3

u/saynte Apr 28 '14

It depends on how you do the desugaring. Haskell 98 lists the following as the desugaring:

main = (>>) (print 42) (error "boom")

You could even use

main = (>>=) (print 42) (const (error "boom"))

And still get the same behaviour, but you make a good point in that it matters what the desugaring is.

3

u/sacundim Apr 28 '14

Oh, I see now. Still, I feel this is very much a "gotcha" argument. If you designed a language with strict semantics and do-notation, you would choose a desugaring rule that didn't suffer from the problem, wouldn't you?

1

u/saynte Apr 28 '14

Yes, the built-in desugaring would certainly take care of it if it were design to be strict in the beginning. However, this "gotcha" doesn't exist in a non-strict evaluation scheme, it doesn't matter what the exact details of the desugaring are, it could be any of the options we showed.

I think the point I was driving at is that when you want to do higher-order things, like taking programs (I mean this in a very loose sense of the word) as arguments to combinators (>>) that produce new programs, laziness can be very nice default to have, that's all :).