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

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.


[deleted]


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.

https://news.ycombinator.com/item?id=5072224


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?




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

Search: