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.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.