This is an excellent resource: http://dev.stephendiehl.com/hask/ http://dev.stephendiehl.com/hask/ There's also Chris Allen's guide: https://github.com/bitemya

This is an excellent resource: http://dev.stephendiehl.com/hask/ http://dev.stephendiehl.com/hask/ There's also Chris Allen's guide: https://github.com/bitemyapp/learnhaskell https://github.com/bitemyapp/learnhaskell . You can also go through the (good, but very dated) book, Real World Haskell. Sometimes you have to find the tutorials and blog posts first. The lens type signatures aren't the easiest to understand, and sometimes its easier to just use things "empirically" without fully understanding them, and then get a sense of the type signatures when you really want to know what the compiler's actually doing. Being able to use lenses is not as hard as understanding why its intimidating rank-2 type signature is the right one. Finally, sometimes it helps to de-generalize. To replace (Monad m) with IO, for example, and think about what that special case might mean. For example, the type signature for Control.Arrow.first is: first :: Arrow a => a b c -> a (b, d) (c, d) If you're a beginning Haskeller, your reaction is going to be "WTF"? Well "Arrow" is a type class more general than function. (It could be the "effectful function" type or Kleisli arrow, a -> IO b.) If you specialize with a = (->), you get the more concrete type signature: first :: (b -> c) -> (b, d) -> (c, d) ... and it's much more clear what it does. As for nomenclature, I don't disagree. I had this discussion with Brian Hurt (and owe him for the insights): we'd be more marketable if we called Monoid "Appendable" and Functor "Mappable". Monad is one where it's hard to come up with a more accessible name for it: it abstracts over computational context (i.e. what do we actually mean when we talk about computational effects) but that would be a mouthful of words and not any more clear.