Switch.pm was a core module for a long time and was never at all appropriate for use in Production. But I agree that a module being in core makes it more likely to be appropriate for Production use.
A module being "alpha" doesn't really mean that I should avoid using it in Production, IME. I also find it quite common for a module to have both some features that I would be comfortable using in Production and some that I would not.
The most useful metric I've found for avoiding the use of modules in Production is ETOOMUCHMAGIC. An inordinate amount of complexity being relied upon to implement a relatively simple feature is a very bad sign, IME. As is the use of even relatively small amounts of non-mundane complexity.
Non-mundane complexity (often found under the label "magic") is the worst kind because it leaks out in odd ways and interferes with other non-mundane complexity and often causes problems that don't appear at first, can be triggered or defused pretty much at random, and appear completely unrelated to their sources. You can waste huge amounts of time and effort trying to deal with such problems.
While excessive depth of mundane complexity thwarts attempts at quick resolution by the sheer volume to be searched through and the great distance that can result between the problem and its source, which can make fixing the problem impractical.
When deciding whether I want to use a module in Production or not, I usually read the source code. (Though, DBI is a good example of an exception to that; but it would take too long to try to properly explain that.)
- tye
In reply to Re^2: How can you determine a CPAN module's development status? ie alpha, beta, (RTM ?) etc (source)
by tye
in thread How can you determine a CPAN module's development status? ie alpha, beta, (RTM ?) etc
by zork42
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |