<i>What we really need is an "Advanced Haskell" book which assumes a knowledge of Level 1 Haskell and then lays out the CT bits in an orderly fashion. Monads for example, are best understood from a Category Theory perspective than through some tortured analogy to Space Stations or Elephants or whatever.</i><p>I think people are looking for something profound where there really isn't anything as profound as they are imagining. Monads are applicative functors with "join". Applicative functors are functors with "ap". Functors are containers that can apply a function ("fmap") to their contents. Add in some laws, and that's what you have; a few very generic concepts that let similar things have the same API. There is nothing more profound here than any other generic API, except that the "genericness" goes beyond what most programmers are used to. (Most programmers seem to be used to abstractions that take some "noun" and make variants -- map => hashmap, alist, plist, binary tree; list => linked list, vector. Haskell's abstraction is more like an adjective -- a functor isn't really a thing that you can hold in your hand, it's just a property of something. "Monad" is a property of "list" like "red" is a property of "apple".)<p>(Monoids are even more generic -- they are something that has an "identity" and an "append" operation. Lists are monoids, but so are booleans like "Any" and "All", and integers form monoids over addition and multiplication. Monoid is just a word that relates the common properties. The advantage of this abstraction in Haskell is that you can "mconcat" a list of sentences into a paragraph just like you can "mconcat" a list of numbers into their sum.)<p>Monads get a lot of mindshare in Haskell because they are a good way to sequence computations -- you write a single sequencing combinator, and you get convenient syntax sugar and a big collection of utility functions ("liftM", etc.). Write another function, and you can create monads from other monads, which happens to be convenient for writing applications. (Reading the definition of the type "X" in xmonad is enlightening, if only because you realize that the entire program is a bunch of functions that return "X", and that the mechanics of X's "monad" instance make the program work the way it does. xmonad is really the X monad!)<p>Arrows are like monads, except instead of "bind" you have a variety of other combinators; "fanin", "fanout", etc. If your data flow looks like that, Arrows make your code look like your dataflow. (And from a category theoretic perspective, every monad is an arrow. Kind of how every "light red" is "red".)<p>I think RWH provides good coverage of monads, although reading RWH once you "get" monads can be tedious. The good news is, by the time you learn what the word "monad" means, you already know what it does for you.<p>So anyway, just start programming, and you'll see why these abstractions are useful. You'll also see why "easy to understand" abstractions like "foldable" and "traversable" are useful too, even though there is not much category theory there.<p>I guess to summarize: don't let unfamiliar words scare you away from simple concepts! You already know how to program, and programming Haskell is just programming!