Hacker News Reader

Comment by mpu | Hacker News Reader

I find it hilarious that all the examples he gives in the beginning have weird semantics only because of LAZINESS, mixing effects with laziness gives nonsense, give a cbv semantics to the language and you get the intended behavior (intended even by HIM who is arguing for laziness). Unbelievable.

Edit: in my comment, oppose pureness (that is put forward in his rant) to laziness (what he unintentionally is arguing against).

View on HN

Laziness is just one way you'd see that issue crop up. It's merely an example of the dangers of functional programming in a language with side effects. When you compose functions, you have to be very careful that they either 1) have no effects, or 2) have very predictable and controlled effects. This isn't a problem you can have in a purely functional language, because it's a compilation error.

Also, it's not an argument against laziness. Laziness is fine in a purely functional language. It's one of the things that makes Haskell so pleasant.

And yet the first example is in C# which is not a "lazy language". The problem is that in any language you do want lazy behaviour from time-to-time. For example in "get me the first element of this list that is positive" you do not want to traverse the rest of the list after you find your positive element. Laziness always has a weird interaction with effects and you always want (the potential for) some laziness, hence the problem.

1 - Why would you ever want to add a logger to a pure function?

2 - If you really, for some unknown reason, wants to do that, you can pass the logger as an argument to f2, and have it run inside the IO monad somewhere outside of that fragment. But really, read #1 first.

Did you reply to the wrong comment?

Ops. I did.

Reply on news.ycombinator.com