Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??
A simple "negative module recommendation" would be too simplistic to be useful, I think. It would be much more valuable to know why you don't care for a module.

The problem is that nontrivial modules often need to balance multiple competing objectives: speed, scalability, robustness, battle hardening, simplicity of API, debuggability, flexibility, etc. (I'm intentionally only listing dimensions that have caused me to reject a module.) As a result, it's not always about good vs bad; sometimes, it's a matter of matching a module to your situation.

So, for example, I write code for a variety of situations:

  • production code that I and others will be re-reading and maintaining for some time, some of which is for occasional tasks and some of which will be run repeatedly with huge amounts of aggregate data
  • support code that somebody else might read but mostly will be behind the scenes and maintained only by me
  • one-off programs to do simple maintenance or analysis operations on some short-lived input
  • experimental programs just to see if some idea or other will pan out
That is certainly not an exhaustive list of scenarios, but it's still representative enough to demonstrate that a module that is perfect for one situation might be completely unsuitable for another. For example, there's nothing wrong with using regular expressions to parse HTML or XML if you're only using it on files with known formatting, or if you'll be able to figure out immediately if it gets it wrong. If another module uses a more robust parsing mechanism, then of course you would use that module instead -- unless it were slower, more complicated to use, or worse in some other way that mattered to you more for the task at hand.

Which is not to say that I disagree with the whole idea of negative ratings, just that a blanket "this module sucks" is not likely to be as helpful as some additional information. Alternatives would be:

  • Rate the module on a whole range of dimensions
  • Record negative ratings, but require the rater to submit the reason or reasons
  • Restrict negative ratings to suggestions of alternatives, preferably with reasons why each alternative is superior
In some cases, a blanket negative rating is appropriate, if there are better modules out there in all dimensions, or if the module has some fundamental flaw (eg incorrect behavior on common input) that would cause you to recommend never using the module in any circumstance.

I work for Reactrix Systems, and am willing to admit it.

In reply to Re: Negative module recommendations by sfink
in thread Negative module recommendations by zby

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • 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.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (5)
As of 2024-03-29 00:17 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found