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.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.