Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

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

by legLess (Hermit)
on Jul 04, 2001 at 08:29 UTC ( #93781=note: print w/ replies, xml ) Need Help??


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

I agree with most of what you say about Matt's scripts. I've been hacking Perl for less than two months, and they give me shudders just the same.

But your secure alternatives link game me pause. I actually bought that book (Writing CGI Applications with Perl, by Kevin Meltzer and Brent Michalski), and I wouldn't recommend it to anyone.

Now, I'm not trying to trash Kevin or Brent, both of whom I'm sure know far more about Perl than I do, but I thought the book was weak. Points:

  • 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).
  • Some chapters belong better in a Perl book ("Tied Variables").
  • 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).
  • 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.
  • The cover's odd. What are we supposed to call it, "The Spiky Ball book?" ;)
In short, the book is much more vocational than educational. Need to hack up some code fast? This book will help. If you really want to learn CGI, to know why and how it works, to have a broader grounding in the technologies used with it, and to build a firm foundation for future self-teaching, then IMHO nothing beats the Mouse book (CGI Programming with perl, an O'Reilly book). I bet that the Mouse book squeezes twice as much content into 450 pages as Spiky Ball does in 525.
--
man with no legs, inc.


Comment on Re: Re: Re: Matt's Script Archive Strikes Again!
Re: Re: Re: Re: Matt's Script Archive Strikes Again!
by KM (Priest) on Jul 26, 2001 at 22:41 UTC
    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

      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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (10)
As of 2014-08-20 05:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (105 votes), past polls