good chemistry is complicated,
and a little bit messy -LW
Amidst all the great comments on the book here at TPC, I was alerted that someone bashed the book here. So, of course, I had to look and respond :) Not only because that is my personality but because I tend to find bad reviews (about many books, not just mine since there have only been two, and this is one) based from people who basically the book isn't for. Anyways, on with the show...
It looks like a nice thick book, but it's very padded; this verges on dishonesty, IMHO. The font is huge (12 to 14 points), there's a lot of padding (most code samples listed twice, 40 pages of appendix material that could have been 8 URLs), the margins are huge, and there's an awful lot of repetition (the 10 lines justifying -wT are repeated nearly every time it's used in a program).
Well, I can't comment on your taste of fonts, that is too subjective. When code samples are listed twice (which you didn't give any example of this, and I can't think of any which were) it would have been done for clarity. Sure, the appendix could be a list of 8 URLs, but then again, almost any book on Perl (c, Python, etc..) could be one page saying RTFM. Appendicies are meant for reference mateials. So, while reading (or whenever) you can quickly look some things up instead of needing to get on the web to look at a URL, and maybe have to print it. As well, it shows what was current when the book was written. Things on URLs may not be the same as you find in a book. So, you need the context. The bits repeated on using -wT are repeated a lot, why? Because it is important. If someone learns nothing from the book but to use -wT in CGI, then the book served a purpose. Sometimes, people need to see things many times before they remember and understand it.
Some chapters belong better in a Perl book ("Tied Variables").
Um... it is a Perl book. Refer to the title. Of course, if we didn't cover tied variables, and just used them, then people would complain that we didn't cover this topic (which many people don't know about).
Some inclusions/exclusions and focus choices are very odd. There's a very detailed chapter for Mason, but no mention of templates (literally - not even in the index).
Because it covered Mason, not templates. There are too many templating systems and, IMO, if you cover one, you need to cover them all. If there is a 2nd Ed. I do want to cover TT.
Their style is very choppy. They'll present a couple lines of code, then a paragraph talking about it, repeat. It's very difficult to get a cohesive view of the program this way - it's spoon-fed to you rather than presented whole.
When you have a 100+ line program, it is quite hard (and ugly) to list all the code then explain it. An explination of code which was shown 5 pages before isn't very friendly, or helpful. If you want to see the full code, you look at the end of the chapter in the section titled Listings. One of the points of the book was to explain what was happening in digestable chunks. So, you have to spoon feed large scripts if you want to actually encourage learning.
The cover's odd. What are we supposed to call it, "The Spiky Ball book?" ;)
Actually, some people call it that. It has no name, and is mostly refered to as 'the book with that cover', or the M&M book.
rest of comments not quoted
Actually, I think you have it backwards. I think the Mouse book and this book are good compliments of one another. I (and most I speak with) find the book to be educational, then vocational. It teaches many concepts (of CGI, DBI, graphics, Perl, etc...) Then, once you learn, you can refer to it.
I bet that the Mouse book squeezes twice as much content into 450 pages as Spiky Ball does in 525.
If you are to blurt something like this out, please back it up, or remove it. As a (new) author, I find that when people simply spew out comments like this, it doesn't help anyone. What does the Mouse cover that we don't? What do they cover in more depth? What do we cover they don't? What do we cover in more depth? Do the books seem to go after different audiences? Do they compliment eachother?
You say you wouldn't recommend this to anyone, but really haven't given any good (IMO), reason as to why. Because you don't like the font? Because we repeat important concepts like tainting and warnings? Because we cover Mason and not templates? Because we give code in digestable amounts, and then give detailed explinations of that code? Because you don't know what is one the cover? These really aren't good reasons. Good reasons would be: we got things wrong, the code is bad, it is unsafe, we don't cover important and interesting topics (which we do, DBI, XML, POP, graphic manipulation, cookies, embedded Perl, security, etc...) Maybe the book simply isn't for you, but that doesn't mean it isn't good for someone else and you should really consider if your reasoning to not recommend (especially in a public arena like this) is valid. If you have some valid gripes, send email to us so we can take them into account for future printing/editions. If you do not, and you simply didn't enjoy or 'get' the book, keep in mind that others may.
In reply to Re: Re: Re: Re: Matt's Script Archive Strikes Again!