Hacker News new | comments | show | ask | jobs | submit login

"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?

> 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.


log "Var x =" x

Nope, just use trace.

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

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

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.


I know there's some debate over it, but I think it's important to teach the general concept of a Monad first, before attempting to teach IO.

Ask yourself: why does everyone write a Monad tutorial after they understand Monads? It's because they seem obvious in _retrospect_. The only tutorial I've seen that's anything like approaching a "works for everyone" tutorial is "You could have invented Monads".

As to your specific explanation, I think it falls down with IO ().

"Monad" is a cool word, and they have a reputation of being extremely profound and obscure. Lots of people in the Haskell world, as you probably know, find this a bit overwrought.

Yes, the mathematical background for the concept is very abstract, like everything in category theory. But in a way, talking about that is like going into "Principia Mathematica" to explain how sets work.

You can also just say that monad is a name for the general kind of thing that you can use with the do syntax. That is, types that support binding variables and returning values.

That the abstract mathematical theory of binding variables and returning values is a bit abstruse is not such a big deal. People can use IO without really grokking the theory of monads.

Yeah, to people used to imperative languages, it's surprising that you can't just call an IO thing in the middle of your function.

But that doesn't mean Haskell makes IO difficult. And it doesn't mean Haskell is a bad choice for IO-heavy applications.

I worked at a web startup that used Haskell for its backend. It worked extremely well, was quite short and clear, and rarely had problems.

>As to your specific explanation, I think it falls down with IO ().

I was trying to avoid replies like this with my disclaimer at the beginning of my comment. I've deleted it.


Don't ask for feedback if you're only looking for encouragement?

I knew the explanation didn't cover `IO ()` and some other corner cases, I hinted at the fuller understanding in the second half of my comment.

I was trying to avoid the low-effort dismissal you put forth by saying it was a very silly explanation.

What do you think you've accomplished?

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...

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact