Real World Haskell Paperback
Code You Can Believe In
- Format: Paperback
- Pages: 714 pages, 1, black & white illustrations
- Publisher: O'Reilly Media, Inc, USA
- Publication Date: 05/12/2008
- Category: Functional programming
- ISBN: 9780596514983
Showing 1 - 2 of 2 reviews.
Review by joeyreads
Finally done! I started reading this book before it was published. I stalled out several times, and restarted from the beginning, so some parts have been read 3 or 4 times. Eventually it became a proxy for learning Haskell. So it's hard to say I'm done.<br/><br/>I contributed a lot of stupid comments to the first several introductory chapters, and hopefully made them better. The book was reviewed on the web by many people, in a rather unique way, and I'm one of many proud to be listed as a reviewer in the book.<br/><br/>The first several chapters are a good introduction. I didn't really develop the ability to evaluate nontrivial haskell code by reading them though, and that made it much harder for me later. (I also didn't really do the exercises, which probably didn't help with this.)<br/><br/>I got stuck around chapter 6, on typeclasses. The explanation didn't stick well, and I struggled especially with the multiple different namespaces used in typeclasses, often with a single Word being defined in more than one. Also with polymorphic types. Hard to tell if this was the book's problem or my own.<br/><br/>The chapter on IO wisely comes before monads, and this works quite well.<br/><br/>But, the development of monads used in the book didn't work for me. Part of the problem is that the example code that is used to motivate monads is tangled up in a chapter that involves parsing PGM image files. The monad-free code written to do this was clearly not the right way, but I also found it so incomprehensible, with my poor grasp of the syntax, and relating to such boring subject matter that it was hard to get through.<br/><br/>Similarly, arrays and maps are buried in a chapter that develops a barcode parser. While quite an impressive thing to put in this book, I wonder if that is somehow too impressive to expect readers to wade through while still shakey in syntax and foundations. (And, similarly, getopt is only explained in the last chapter of the book, which purports to be about STM! It's not even in the index, so unless you read it all right through before trying to write any real world program, you'll struggle to find some decent getopt docs elsewhere.)<br/><br/>Some of the better chapters don't have a large body of code attached. The shining example of this is the awesome chapter on profiling, which concerns itself with 5 lines of code and dives down all the way to assembly language to make it optimal. It's a great reference chapter the first time you get stuck on haskell space use, too.<br/><br/>That seems to be the main tension in the book, is it about showing actual real-world code, or real-world techniques? Perhaps the book errs on the side of showing off too many of the authors' pet projects.<br/><br/>I also suspect that, despite the heavy reviewing of chapters as they were written, O'Reilly may have rushed this book to press somewhat. (My own limited experience with working with O'Rielly suggests this is not uncommon.) It's a bit sad to see corrections that were made before publication time and did not get in. I hope for a second edition one day. Particularly, the book needs to be updated to use new style exceptions, and some of the other examples have rotted.<br/><br/>Still and all, I read the book, and "Learn You a Haskell", and a bunch of web writings, and I eventually learned haskell well enough to write a real-world, eleven thousand line program that is being used by a fair number of people. Without having actually sat down and written the program, I'd not truely understand haskell to the extent I do. Without this book, I'd certainly not have even tried.<br/><br/>
Review by sbloom42
Real World Haskell does a good job of introducing Haskell. It tries to show that Haskell has use in real world applications, and while I'm sure it does, in my opinion there are a lot of better choices for real world applications than Haskell. The learning curve for Haskell is very very steep and until you make it up that hill, most of your development efforts are focused on getting the type system setup and correct for your application. Personally I'd rather focus my efforts on code that has results - like getting the GUI working or returning database results - rather than deciding which monads my type class will implement.