One thing that has tripped me up trying to learn Haskell is that it always seems like each book has a different idea as to when particular aspects of the language should be introduced, and a lot of them are guilty of using more advanced constructs before explaining them. It's almost inevitable a Haskell text throws the IO monad at the reader and follow sit up with something like "Don't worry about what a monad is, we'll cover that later" Sure, I get it, we want people to understand their Haskell programs can actually do something, but I think introducing the instance before the concept in this case often makes things more mysterious and confusing than they need to be. perhaps it is because Haskell is so mathematical, but I feel as though a text book that presents Haskell almost in the form of a logical proof--i.e. shows how the concepts directly build upon one another--would make more sense than one that tries to approach the language like other traditional programming languages.

I also don't think most Haskell texts spend time acclimating the reader to the shift in thinking functional programming requires. Granted, that isn't the primary purpose of these books, but I think the difficulty in shifting the way one thinks about programs is the hardest part of learning Haskell--especially since Haskell is very functional in nature--more so than some other functional languages which are usually hybrids at least to a certain extent. Reading some more theoretical/general works on functional programming has helped me a bit in this regard, such as Functional Programming: Practice and Theory and An Introduction to Functional Programming Through Lambda Calculus

As far as books on Haskell go, I've found Real World Haskell to be the best--though it does cover a few topics too quickly in my opinion--it may almost be better as a second introduction to the language than a first. Haskell Programming from First Principles is also pretty good (not free).

I also wish Haskell texts would explain that all functions only take one argument earlier on. Most of them, with the noble aim of easing the reader in, present functions such as: `f :: a -> a -> b` early on and ask the reader to treat it simply as a function that takes two arguments. While this is nice at first, I think this approach only makes wrapping one's head around the one argument/higher order functions idea more difficult later when the author inevitably outs the first explanation as a white lie. Basically, you've understood a concept in one way and now you have to toss that understanding aside. What! You're just making more work for me. In the case of languages that require more or less a whole distinct framework of thinking about programs I'd rather tackle the difficult conceptual stuff up front so I can get used to thinking in a different way rather than delay this shift in thinking till the latest possible point and find out all my little toy programs and exercises were rather naive.

I think that's partly why some general texts on functional programming tend to be more effective--their focus is the conceptual shift in thought, not a language. With Haskell, I believe this shift in thinking is a necessary prerequisite, so It'd be good if Haskell books could integrate it more smoothly, or if necessary just state up front that if one does know the fundamental concepts underlying functional programming one should learn those first.

I've never been a huge fan of LYAH's method either. It is nice to have jokes, puns, and graphics peppered about the text, but I find it distracts me more than helps me. I'm also a bit wary about learning mathematical and logical concepts through analogy in general. It's often necessary when starting out, but a heavy reliance on analogy can really bite you in the long run since mathematics and logic have much to do with systemic relations and definitions, and it isn't always easy to resolve these relationships in terms that fit the analogies you originally employed.