Hacker News Reader

Comment by mbrock | Hacker News Reader

"The choice of a pure functional language like Haskell to do lots of IO seems like a strange choice given that Haskell makes side effects like IO more difficult than other languages. I'm curious to know how that affected the implementation. I'd like to use more functional languages, but since my job is primarily IO of some sort, watching people struggle with writing to sockets leaves me more than a little hesitant."

Haskell has excellent I/O support. How do you mean that Haskell makes I/O difficult?

View on HN

> Haskell has excellent I/O support. How do you mean that Haskell makes I/O difficult?

Composability is different since effects must be explicit, which is both a strength and weakness of Haskell. So say you want to add an effectful computation P in some function G, G and all its callers must have modified signatures accordingly. That could be annoying depending on what you are doing.

I use Haskell a lot. I can't recall ever having to have added IO to a deeply nested expression like this.

Why would it be done if it was hard? The path of least resistance in Haskell dictates not doing this, and carefully figuring out where you want IO up front. In contrast, in a language with side effects you just do it whenever you want and everything compiles as before, for better or worse.

PL design is like a box of tradeoffs.

Debugging...

log "Var x =" x

Nope, just use trace.

He means you have to climb the IO Monad learning curve.

Learning is fun! And Haskell's IO functionality is pretty easy. They teach it in the very first programming course at Chalmers in Gothenburg. It's covered in any introductory Haskell book.

Yes it's covered in any Haskell book - what use would a language book be without covering IO? How far back in the book it comes, relative to other languages, is the telling piece. LYAH has it as Chapter 9, after algebraic data types, higher order functions, functors, and recursion... I note that in the one week introduction I did for my MSc at the University of Oxford, they didn't cover it, considering it to be too much to fit in to the week.

Having taken the rite of passage that is writing my own monad tutorial, I would agree, the concept is both easy and intuitive. Getting it in to your head, however, takes considerably more work than in any other language I've used.

Waiting until chapter 9 isn't so bad when you realize that many professional programmers including myself have been doing this for 20+ years and are still learning the best way to structure effects within a program. What's the rush anyways?

That's only a problem when looking for the cheapest souce of http://c2.com/cgi/wiki?PlugCompatibleInterchangeableEngineer...

In truth, you don't actually have to climb the IO monad learning curve. IO in Haskell has nothing to do with monads.[1] It's simply a type which encodes input and output effects. Simple and elegant. The fact that people so thoroughly confuse the issue by mixing the disparate topics of IO and monads, is a shame.

[1] http://blog.jle.im/entry/io-monad-considered-harmful

Reply on news.ycombinator.com