4 ms·
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 messag
by mark_h 16y ago
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 16y ago<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.