Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re: Perl black book

by RhetTbull (Curate)
on Sep 05, 2001 at 19:49 UTC ( #110338=note: print w/ replies, xml ) Need Help??


in reply to Perl black book

This node is being voted down and in fact made it on the Worst Nodes list for today, probably because kommesel said he liked it better than the Holy Camel Book. What gives folks? A new user took some time to write a review (albeit brief) of a book he found useful. That sounds worthwhile to me. He even prefaced his review by telling us he's not a programmer or perl geek so we know what context to read his review in. If you disagree with his review then writing about why you do or do not like the book in a comment is far more constructive and helpful to the Monastery than voting down the node. A negative vote doesn't tell us WHY you don't like or what's wrong with it. All the folks who voted this node down should go to the Confession Booth.

--RT


Comment on Re: Perl black book
Quality of Reviews on PM
by Masem (Monsignor) on Sep 05, 2001 at 21:39 UTC
    I have not voted for the node in either direction; I've not heard of this Black Book until now, but more importantely, the review tells me little about it that would influence my purchasing decisions.

    A growing problem/trend of PM latety in the Review areas is the quality of the Reviews. Before I get too far, let me slap this up:

    IMO!!

    I believe that if you are going to review something here at PM, you should consider giving out as many details as possible about the book or module, positive or negative, that would help me decide whether to use the item in question. Simply stating "I found it useful" doesn't help at all.

    Imaging if movie reviews were only listed by title and the number of stars that it was given; would that be helpful to determine what movie to go see? Definitely not, which is why most reviews give details such as the genre, the MPAA rating and any specific such as language or violence that earned it that rating, the actors and directors involved with it, the length of the movie, and maybe some 'preliminary' movies or material that you should be familiar with to fully enjoy the movie. Putting that all together, I now know if there's enough elements about the movie that I might want to see it.

    The same ought to go for book or module reviews. For book reviews, I would find it very helpful to know things such as the size, cost, and hardback/softback-ness of the book, year and publisher, a table of contents (particularly any references/appendix material), the amount of background and advanced material in it, the number of illustrations in it, and the amount of sample code in it. Most of this is factual, and thus should have no bias. However, it can help to improve a review. EGs: "This book has about 6 of 10 chapters dedicated to reviewing the basics of perl. Obviously, this book is not meant for the advanced perl programmer...". "While the book has frequent illustrations, these tend to be too large and reduces the amount of usable content in the book..." (Note those are not real reviews of any books, just examples). If it comes with a CD, information on what's on that too is helpful.

    Obviously, there's more on the 'personal' part of the review that's harder to distinguis. RhetTBull points out one aspect that I find helpful; stating what level the reviewer is and how helpful the book is too that level. Other aspects that should be considers is how readable it is (is it meant to be used as reference or can be taken on a plane or trip for casual reading?), quality of writing and code examples, organization of the book, how well the book met the reviews expectations, and other details that are going to vary depending on who reads it. Exactly what goes in here will all depend on what the book is and how the reviewer does it, but the more information a reviewer can give here, the better the review.

    For module reviews, again IMO, I believe there's a lot of fixed unbiased details that can be included to help out, including installation needs of a module, the amount of documentation associated with it, example code present, etc. Particularly for modules, I find it very helpful to have code of the module in use hopefully created by the reviewer, but borrowing code from the module isn't a bad thing either. If a module claims to be simple, but requires 4 function calls to do something simple, it's not a very good module, and an example would show that. A module review should go through all the general class of methods and objects that a module can provide, and any features that might be unique to the system. If module reviews for 2 or more compariable systems are done properly , I should be able to read those reviews side by side without resorting to looking at the module itself to determine which one will suit my needs. (Of course, a reviewer may completely miss a lacking/broken feature that they never would encounter that's critical for someone else, but here on PM, that's easily resolved since reviews can have additional feedback and be modified after posting to fix it).

    Again, this is all IMO, but I do believe that more in-depthness in reviews are needed here, at least to be more effective for my selection process. As of late, a lot of the reviews seem to be thin, and really have not helped me decide if I need a book or not. Of course, going by a review alone is poor, but when looking at filling a potental perl bookshelf or a module directory, a well-written review will at least help point me to good starting points.

    -----------------------------------------------------
    Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
    It's not what you know, but knowing how to find it if you don't know that's important

      IMRDO (In My Respectfully Differing Opinion ;--) you can _hope_ that people will write proper reviews, but there is not much you can really do to improve what they write.

      Especially the "factual" stuff. I can get the author bio and the number of pages from Think Geek or Amazon or my local bookstore. I don't care about the number of illustrations in a book, I'd rather the review writer spend more time telling me what he thought about the book than counting pictures! ;--)

      What is really interesting in a book review is whether the reviewer thinks the book is helpful, technically accurate and generally enjoyable. All of which are quite non-factual. And besides it is quite hard for a reviewer to judge both the helpfulness of a book (it has to be someone who needs to learn whats in the book) and its technical accuracy (in which case it helps if the reviewer knows a lot more than whats in the book).

      So a review that tells me who the reviewer is and then what he thought about the book is just fine. Other posters with different background can then comment and help the reader get the complete picture.

      At least this review showed us a book that I am sure few people here knew.

      And now back to some factual information: the book is 1400 pages, paperback, pretty thin paper I've been told, although I don't have the figures here, it was first published in August 1999, it looks like the current edition is still the 1rst (actually an important info, 1rst editions have more typos and errors than subsequent ones, plus publishers usually only prints a second edition if they've sold all of the first one), but there seems to be another one named the "CD-ROM edition" out there, it's listed price is $49.99 but its street price is around $35-$40. Is that enough non-biased info?

      Man, I don't think I've ever known so much about a book I will never buy!

        For what I consider good in a book review see any by footpad. (:

                - tye (but my friends call me "Tye")
        Certainly one can argue that facts for a book or module can be found elsewhere, but I think that the addition of this information is necessary for completion, as some of my examples indicate. Other examples: the reviewer claims that this book packs everything one needs to know about perl into it; I'd question that claim if the book is less than 100 pages long. alternatively, if a reviewer claims that the book is lacking and yet is 1000 pages long, I'd again question the reviewer.

        Of course, as you state, there's no way to control the quality of reviews here on PM; we can only use the voting system to let reviewers know if it was acceptable or not. In my case, I don't plan to downgrade any reviews unless they are completely baseless ("The Camel book is completely worthless because I say so!"), and upgrade those that I find useful, but I'll take a neutral stance on reviews that seem so-so.

        -----------------------------------------------------
        Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
        It's not what you know, but knowing how to find it if you don't know that's important

Re: Re: Perl black book
by John M. Dlugosz (Monsignor) on Sep 05, 2001 at 22:46 UTC
    I didn't find it particularly useful, and don't care that he likes it better than the Camel, especially since he detailed what audience he's representing. What bothered me about the post was his awful grammar.

    I did not vote at all on it, one way or the other. If he had written better, and included a link and other info about the book, I might have ++'ed it for his effort.

      I agree with your point about including a link and other info. Given the original review it would be very tricky to find the book in a bookstore.

      The comment about grammar isn't very helpful. It's possible English isn't his first language. Lots of monks here aren't from the USA, this should be borne in mind when correcting spelling and grammar.

      If you really wanted to help with the grammar problem a /msg would probably have been better.

      Before coming out with comments like that it's useful to think why you're making them: to help the original author, as an example to others or to make yourself look superior (my own reasons for this post are probably a bit suspect there, I confess).

      Kevin O'Rourke

Re^2: Perl black book
by rat (Initiate) on Apr 10, 2008 at 21:01 UTC
    I agree. Great book!! I have the first edition and office mates are ALWAYS borrowing it (for years sometimes - I know where it is!) My copy was so "in demand" that another colleague decided to just buy his own. The 2nd edition is out of print and the USED copies are going for $150+!! Pretty wild! It makes me very curious what was changed in the 2nd edition and why they didn't bring out a 3rd. RAT

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (9)
As of 2014-11-26 12:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (170 votes), past polls