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.
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.
<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.
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.