Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re: Re: Re: Re: Matt's Script Archive Strikes Again!

by KM (Priest)
on Jul 26, 2001 at 22:41 UTC ( #100086=note: print w/ replies, xml ) Need Help??


in reply to Re: Re: Re: Matt's Script Archive Strikes Again!
in thread Matt's Script Archive Strikes Again!

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.

Cheers,
KM


Comment on Re: Re: Re: Re: Matt's Script Archive Strikes Again!
Re: Matt's Script Archive Strikes Again!
by legLess (Hermit) on Jul 27, 2001 at 07:23 UTC
    I wrote a long, detailed response to your post, giving point-by-point rebuttals to most things you said, and they thought ... why? It's pointless. The last thing you say is:
    If you have some valid gripes, send email to us so we can take them into account for future printing/editions.
    But you clearly can't mean this. After reading your defensive rampage I'm even less likely to raise concerns with you. I have every reason to believe that you'd respond the same way you did here, by saying "The book's obviously not for you, and you're wrong anyway." You're not likely to get "valid gripes" if your definition of "valid" is "must agree with me."
    --
    man with no legs, inc.
      You are completely wrong. First, it isn't a rampage. It is pointing out to others who may benefit from the book that you aren't really disliking it for any (given) valid reasons, aside from personal dislikes.

      I have gotten a decent amount of email from folks with various gripes and corrections and have been happy to correspond with them. I like it because this ensures that the next printing and edition can incorporate some of these things. But because you don't like a font, or don't like repeating important points, or don't know what is on the cover are not good reasons to not suggest to someone else to buy the book. Maybe the book isn't for you. A large problem (with many books) is people *think* a book is for them, but it isn't. Then they dislike the book because their ego is hurt that the book didn't seem to be written for them. But no, I don't find your gripes valid. If you find something that was wrong in the book (and not on the errata web page), broken code, points on concepts which we missed, etc... please pass them along. Those would be valid gripes. Not understanding the books layout and purpose isn't. I'd be happy to take this offline, so if you can 'slam' the book with specific and valid problems with it, you know where to find my email address. If you can't cite specific problems with it, don't go around in public arenas trashing it.

      One problem with things like this (and a reason why I may seem defensive) is that it takes a lot of work to put together a book. This project took a year, and many peoples time and energy (between editing and reviewing). Then, someone comes along and says they don't suggest the book because they don't like fonts, and mentions no real problems with the book. I think that doing that is shameful. Good reviewers would say things like "Although they did X Y and Z very well, and the information was technically correct and accurate, the tone of the book wasn't useful to me." What you did was give subjective issues which pertain to noone but yourself, and precede it by saying "I wouldn't recommend it to anyone." That is a harsh thing to say, and you didn't argue your position with anything actually useful to me, or possible readers.

      Anyways, just think of this next time you casually trash someones work with shallow, subjective gripes.

      Cheers,
      KM

        You want specific points? You got 'em. First let me respond to this post. I wouldn't have replied at all, and let our disagreemnt just rest, except for the blatant misrepresentations in your post. I don't know if you're intentionally ignoring most of what I say, or just missing it. I've tried to be more clear and explicit here.
        But because you don't like a font, or don't like repeating important points, or don't know what is on the cover are not good reasons to not suggest to someone else to buy the book.
        I don't mean this at all as a flame, but is English your first language? I ask only because you seem to misunderstand things easily. If you grew up learning another language, then your grasp of English is remarkable - certainly better than I write or understand any other language - and to be commended.

        Fonts: this is addressed below. Here are the basics, though: I talked about the size of the fonts as they relate to the padding (or not padding) of the book. My specific words were "The font is huge," and I think this a very specific complaint. I don't care about the font type, style or anything else (nor did I mention these). I think it's extremely dishonest of you to mention "fonts" 5 times in your two replies, and not once to mention my very specific complaint about them - their size.

        Cover: I'm very sorry that you misunderstood this comment. If you examine it again, and indeed, look at the text you copied and quoted in your first reply, you'll see a little symbol at the end. I'll reproduce it here: " ;) ". This type of symbol is called an "emoticon." A Google search for the term yields over 26,000 results, so it is a fairly common term. The emoticon I used is usually called a "winky," and indicates that the comment it follows is a joke or not to be taken seriously.

        In other words, my comment about the book cover was in jest and not a serious criticism. Again, I'm very sorry if you've never encountered emoticons before and don't understand them. I assumed that someone who'd spent enough time on the web to write a book about it would know such things. I was wrong, and I apologize. Some links from that Google search above will help you, I bet.

        Not understanding the books layout and purpose isn't.
        This is the bottom line of our disagreement, I think. Let me say this very simply: the fact that you don't agree with my criticisms does not invalidate them. You are the author, and you have many vested interests in the book. Of course you won't agree with someone who doesn't like it.
        If you can't cite specific problems with it, don't go around in public arenas trashing it.
        I cited several very specific problems with the book, and many of them are expanded upon below. What you've done is typically called a "straw man argument." In other words, you've cherry-picked the points from my post that you feel are easy to respond to, then ignored the rest. You repeat again and again that I "didn't like the font" (a dishonest misrepresentation), and ignore other things I criticized, like templates.
        a lot of work to put together a book.
        This is 100% irrelevent. If you put your life's work into a book it can suck just as badly as if you spent 2 weeks on it. I'm talking about your product, not your process.
        Then, someone comes along and says they don't suggest the book because they don't like fonts, and mentions no real problems with the book.
        Frankly, I don't know why you keep repeating this point. Your style of argument seems to be:
        • See response that you don't like.
        • Deny that it is a valid response.
        • Claim that therefore there are no responses.
        • Repeat.
        Again: just because you don't agree with my points doesn't mean I didn't raise any. I don't expect you to agree. That's fine. But your disagreement alone is not enough to invalidate what I say.

        How about this for a real problem with the book? "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)." This is very specific and clear, but you don't agree, so you blithely ignore it. "There are no points here," you say, with your hands over your eyes.

        Here is the original response I wrote, then didn't post. I expect that you'll disagree with it, and that's fine. But for the sake of logic, don't pretend that there aren't any points here, ok?

        Well, I can't comment on your taste of fonts, that is too subjective.
        This point you missed. I don't care what font you used; I'm talking about font size. My point is simply that the fonts are unusually large for a tech book, and this has the side effect of making the book look bigger. Whether or not this is intentional, your decision or your publisher's, I can't say.
        When code samples are listed twice (which you didn't give any example of this, and I can't think of any which were)
        OK, how about nearly every chapter. Most chapters have a "listings" section at the end, which contains nothing but code already printed. To my understanding of the word "twice," this qualifies.
        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.
        Good point. Except that certain documents (the GPL for instance) are updated when they have to be, when it's important. It's a disservice and a waste IMHO to print copies of documents that live (e.g. "change constantly") on the web.

        Server codes, environmental variables, ASCII codes, etc are all good and valuable things to have in an appendix. I found it annoying that your extra-wide spacing (25 lines/page - yes, I counted) made these references less usable than they could have been. I've seen several clear, coherent and readable ASCII code charts that fit on one page; that's much more useful.

        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.
        I don't disagree at all. But this reinforces two of my previous points: the book is mainly vocational, not educational, and the book is padded.
        Some chapters belong better in a Perl book ("Tied Variables").
        Um... it is a Perl book.
        Yes. I meant "a Perl language reference."
        There are too many templating systems and, IMO, if you cover one, you need to cover them all.
        So because you couldn't exhaustively cover every single templating system you decided not to even mention them? Come on - that's just silly. Perl templates are incredibly powerful; they're also easier to use and more widely available at ISPs than Mason. Templates are a class of solution, and a very valuable one. I notice that you don't apply this dubious logic to embedded Perl solutions. You don't talk about embperl, for instance.
        If there is a 2nd Ed. I do want to cover TT.
        So by your own logic, this would mean covering all template systems, right? I look forwrd to your next 800-page edition.
        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.
        A laudable goal. IMHO however you went to far in this direction and made it choppier than necessary.
        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.
        I hope you saw my wink - ;). This was not intended as serious criticism. :) (UPDATE: this is often called a "smiley" emoticon.)
        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?
        Ok, here are some more specific differences between your book and the Mouse:
        • Mouse has an entire chapter on template solutions; M&M does not mention them.
        • Mouse has a chapter on searching; M&M does not.
        • Mouse has extensive coverage and explanations of HTTP; M&M does not.
        • Mouse has an entire chapter on CGI.pm; M&M's coverage is not nearly as complete.
        • Mouse has a detailed chapter on JavaScript with some concrete uses: form validation, data exchange, and bookmarklets; M&M doesn't even mention JavaScript.
        • Mouse has useful and full chapters on debugging, coding and architecture guidelines, efficiency and optimization. These are all very valuable subjects that M&M either leaves out entirely or addresses in much less detail.
        You cover tied variables, Mason, and click tracking in more depth than the Mouse. These are all fairly useful, but not nearly as useful as the things you ommitted entirely (e.g. templates, efficiency).
        Do the books seem to go after different audiences?
        Yes, I think that clearly the books target different audiences, and I said that very specifically in my post. Here it is again: In short, the book is much more vocational than educational. Need to hack up some code fast? This book will help.
        Do they compliment each other?
        IMHO no they don't, and I think this was explicit too. I refer to the Mouse book constantly, and today is the first time I've opened yours since I made the original post.
        You say you wouldn't recommend this to anyone, but really haven't given any good (IMO), reason as to why.
        Forgive me for saying so, but as the author your opinion in this matter is highly suspect. You have strong personal and financial motivation to discount any and all arguments against your book. I believe I've made several good ones; you discount them out of turn. That's your right as a human, but has absolutely no bearing on whether or not my points are valid.
        Because we repeat important concepts like tainting and warnings?
        Yes, because you repeat things ad naseum. I think that's a very valid criticism of any technical book. There's obviously a continuum between (e.g.) the Camel book, which is very dense, and a "Perl for Dummies" book which is very repetitive and simple. Your book is closer to the latter, I believe.
        Because we cover Mason and not templates?
        Yes, that too is a very good reason for criticizing the book. Templates are arguably much more useful and usable (especially to your target audience - Perl and CGI newbies, like me) than Mason.
        Because we give code in digestable amounts, and then give detailed explinations of that code?
        Again, yes. Your style is very choppy, and I find it distracting, not helpful. There are thousands of programming books on the shelves, and IMHO nearly all the ones I've seen them do a better job at mixing code and commentary than yours.
        Because you don't know what is one the cover?
        Repeat - this was clearly not meant seriously. If you missed my winky emoticon - ;) - then I apologize.
        If you do not, and you simply didn't enjoy or 'get' the book, keep in mind that others may.
        And still others may not, for the same reasons I listed. What did I actually say? ...I wouldn't recommend it to anyone. That's a demonstrably true statement, backed up by concrete examples. I don't mind for you or anyone else to disagree, but to imply that it's somehow inappropriate for me to air opposing views is sad. If your book can't stand on its own to some criticism then it's very weak indeed.
        --
        man with no legs, inc.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://100086]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (9)
As of 2014-09-19 11:22 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (135 votes), past polls