27 of 38 people found the following review helpful
Better than others, but still not good enough,
This review is from: Real World Haskell (Paperback)
Haskell books are in general among the worst I have seen for any programming language, which is really a pity for such an interesting language. I was really excited when I got this book because of all the good reviews, so I thought I would finally understand what a monad is and learn how to make practical programs.
I would like to mention that I have been a C++ programmer, currently work at a research institution, and my main tool at work is now Modelica: I think I am not completely dense and have experience with different programming paradigms, so I suppose my problems may not be limited to me.
Having read The Craft of Functional Programming, I had some background on the first chapters, which sail along nicely on their own; map, filter, fold, partial application and type classes are really nice and well explained.
There are entire chapters dedicated to case studies, in which the authors clearly favoured quantity versus quality: these example chapters are long-winded, nebulous and downright boring. JSON data? Parsers for some godforsaken image format? The authors clearly ignored the basic fact that examples need to be simple to be pedagogical, and lost themselves in details instead. Which would be tolerable if the case-study chapters could be skipped, but new stuff is introduced in these, so one has to follow through.
The coding style is mediocre: as unfortunately common in Haskell textbooks and resources, variables are often identified with single letters, originating cryptic code. It appears that the authors of those code snippets never wrote production code (i.e. code that has to be maintained down the road, possibly by others), given the total lack of semantics; if they did, someone now maintaining their code must be hating their guts. An argument should be named "state", "name", "address", "previous", not "x", "y", "z". In other cases, the choice of function or argument names is plainly misleading, such as in the case of the parser examples.
A terrible quote (approximately): "A SimpleState is actually a state extractor ..." so what about naming it "StateExtractor", instead of ending up with a bunch of misleading function signatures? Were their fingertips hurting, or did they want to save ink?
However, as customary for Haskell documentation, the worst comes with monads. Introduced early because of the IO monad, which is necessary for basic I/O operations, they are however left unexplained until chapter 14, during which time the reader is left to wonder what they are.
The usual foggy buzzwords are then thrown unsystematically around: "side effects" (what side effects could the Maybe data type or lists have? Yet they are monads), "actions", messy function specifications, confusing "examples" that raise more questions than they address.
I tried hard to wrap my brain around these concepts, I read and re-read the relevant chapters at various time over a month, but in the end I threw the book into the recycle bin - at some point I had to cut my losses. I stress this is the first time ever I throw a book away. Well, actually the second, because the first time I threw it away I recovered it because I got a bad conscience about it.
Sorry if I sound bitter, but I am really angry at myself for wasting so much time and effort for a language that will however never be of any practical use. Now, I'll rather learn Python, thankyouverymuch.
Sort: Oldest first | Newest first
Showing 1-3 of 3 posts in this discussion
Initial post: Sep 23, 2009 10:13:20 AM PDT
Last edited by the author on Sep 23, 2009 10:14:26 AM PDT
Alba C. says:
I think that the extensive use of Monads destroy the advantage of functional programming. But they are nothing complicate at all.. it is just an interface.. like Comparable in Java.. an interface whose main feature is that it allows the compiler to easily understand that it can overwrite data instead of creating new objects. So your code (and the code of those who use your monad) lose flexibility but become more easy to optimize. This come handy also for IO because the old "worlds" can't be preserved and destructive update is unavoidable (and having this limitation enforced by the compiler is better, either natively by the language or by the standard type system coupled with a bit of syntactic sugar, as in Haskell with the 'do' notation).
Posted on Apr 25, 2010 7:10:21 AM PDT
Jas Bro says:
Thank you for a very insightful review, I voted it as helpful.
However, I find it unfortunate that you ended the review with the remark, "a language that will however never be of any practical use". It weakens your other excellent points...
In reply to an earlier post on Nov 30, 2011 1:46:55 PM PST
Marc Sunet Perez says:
I'm gonna second this, especially when he says that he's going to learn python, "thankyouverymuch". The review was excellent until that point. Anyway, I was also put off by this book and turned to Learn You A Haskell. Turns out Haskell _is_ in fact a very practical language, so I encourage everyone who has been disappointed by RWH to retake their journey if they haven't done so already.
‹ Previous 1 Next ›