
Intro to Monads (new chapter of Learn You a Haskell for Great Good) - ab9
http://learnyouahaskell.com/monads
======
rincewind
I read "Categories for the working mathematican" by Saunders Mac Lane and "The
Typeclassopedia" by Brent Yorgey before I really understood monads.

If i just waited for this, it could have spared me all this reading ;-)

------
petercooper
Always loving bonus500's style. It's striking, though, how often guides to
monads crop up on sites like HN. No matter how many introductions or "monads
for idiots" type articles get written, it seems they're conceptually difficult
enough to always need more ;-)

~~~
Natsu
I'm one of the people who diligently reads each of these things on monads
because I know I don't understand them yet. Right now, I at least understand
some examples of monads (Maybe, IO, etc.) and why they're used, but the
internals of how they work (and what "context" they carry) are still too
fuzzy, even if I think I sorta understand the three monad laws (i.e. monads
can bind and return values so you can get normal data in and out of them, as
well a property reminiscent of function composition that allows them to be
chained).

I think I may have to break down and read the O'Reilly book on Haskell (I've
never looked for it, but I'm assuming one exists), because the tutorials all
seem to use Haskell syntax nowadays and that keeps me from fully understanding
many of the articles, even though I seem to be learning bits and pieces of
Haskell each time I read one of these.

~~~
mark_h
The O'Reilly book would be Real World Haskell:
<http://book.realworldhaskell.org/>

It is very good, and expressly isn't a monad tutorial in the usual style,
although they do get covered eventually of course (but from memory without any
extra emphasis or allusions to difficulty, magic, etc).

~~~
gaius
I am working my way through RWH at the moment. Its biggest flaw is that you
_have_ to work your way through it, in order. Don't care about reading
barcodes? Tough, because you can't read the later chapter on Monads unless you
grit your teeth.

The authors spend an awful lot of time showing you the wrong way (i.e. non-
idiomatic) to do something and revealing with a flourish the Haskell way.
Really you ought to just skip the first half of each chapter and not waste
time learning techniques that you have to unlearn later. But you can't,
because of the way it's all so intertwined.

Latest peeve - sometimes they talk about wrapping and unwrapping values, which
is fine. But sometimes they talk about "peeling". What's that? Is it just
another word for unwrap? Is it some special Haskell term? I don't know, I'm a
beginner!

On page 369 of my copy there's code that fails to compile and in the session
output in the book there are actual error messages from the compiler - but the
following paragraph of text talks about it as if it was giving the "correct"
results...

The only reason to read RWH is that there's a dearth of Haskell books so you
make the best of it - but compared to say Learning Python or Programming
Python also from O'Reilly it's really quite poor.

~~~
mark_h
It has been a while since I've read it (as a rusty but not novice haskell
programmer), but most of that does actually ring true. I do remember the error
message now that you mention it! I assume the code was run automatically when
the book was compiled.

There were a reasonable amount of typos and similar errors I seem to recall
now actually, which is either surprising or perhaps revealing given that it
was publicly reviewed.

That said, I still think it's a good book. I'm not that fussed by having to
work through it; that's just how some books are constructed if they're not
reference material, particularly when earlier chapters are pre-requisites. I
take your point though.

As I said it has been a while, but I don't recall being perturbed by the non-
idiomatic->idiom transition either. The numerous monad tutorials mentioned in
other comments are a great example of how forcing a particular learning path
on someone doesn't always work, but by the same token I believe it can be
useful to gently show a common path from common naive code to idiom for
example.

I'd still recommend it anyway, if just for the "real world" approach of the
title.

~~~
johnzabroski
<blockquote> There were a reasonable amount of typo and similar errors I seem
to recall now actually, which is either surprising or perhaps revealing given
that it was publicly reviewed.</blockquote>

A lot of people with Ph.D.s in Computer Science provided "comments" on the
book, but did not necessarily review the whole book. Reviewing a book cover to
cover takes time. I found a lot of academic mistakes in Real World Haskell,
such as the fact they used the phrase "strong typing" which has pretty much
been banned from academic programming language literature thanks to Benjamin
Pierce's book Types and Programming Language, where Pierce says he reviewed
tons of papers trying to decipher a common meaning for the phrase and
couldn't. A better way to characterize a type system is by whether it is (a)
sound (b) complete.

There were just too many examples in Real World Haskell where it could've been
much better explained, especially considering the authors CVs.

------
samratjp
Though I definitely didn't finish reading this, I couldn't help but remember
Why's Poignant Guide to Ruby (<http://mislav.uniqpath.com/poignant-guide/>) -
this is probably the prettiest Haskell learning resource writeup I've seen up
to date :)

------
ulan
I like how the author contrasts monads with applicative functors and
demonstrates why monads are more powerful.

------
cadr
Looking forward to his dead-tree book.

