Re: Is Text::Balanced production ready?

Special-purpose Damian modules that are useful for developing other modules or for solving difficult implementation problems, but which probably shouldn't be used directly in application code

That categorization looks rather odd to me. In what sense is a module you shouldn't use in production code good for "developing other modules"? Reading the code and getting inspired on how (not) to do things? Reading the code and understanding every bit and using those parts you absolutely can assert as being safe? Using that module in other modules you use in production code, thus using them indirectly?

TheDamian has given a hint in the BUGS section of that particular module:

There are undoubtedly serious bugs lurking somewhere in this code, if only because parts of it give the impression of understanding a great deal more about Perl than they really do.

OTOH many of the modules in that list are used heavily in production code (in the sense of CPAN modules being battle-tested, as dragonchild would have it :-) - Lingua::EN::Inflect comes to mind, Catalyst makes heavy use of Attribute::Handlers and NEXT, Hook::LexWrap is often recommended and so on. So, these modules might already be "battle tested" despite of any disclaimer they contain.

The general rules hold - don't use things you don't understand, because doing so leads to cargo cult code; read the docs and read the test suite: if your use cases fall within the boundary set up by those; if the bug list isn't too long and doesn't contain no-nos; if the module isn't alpha (i.e. hasn't too many moving parts), then it probably is production ready.

Of course, it depends on what you are producing and on your own notion of "production ready". What would be your answer?

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Comment on Re: Is Text::Balanced production ready?

Replies are listed 'Best First'.
Re^2: Is Text::Balanced production ready? by Jeffrey Kegler (Hermit) on Nov 13, 2007 at 02:09 UTC
That categorization looks rather odd to me. In what sense is a module you shouldn't use in production code good for "developing other modules"? My understanding of what Damian means here, includes things like use in test scripts; use in creating chunks of code that will be incorporated in production code after examination and testing; use in pretty-printers and checking for best practices; use for automatically rewriting all your array accesses to hash accesses; use in examining test results; etc. This "indirect" realm is surprisingly large, and Perl has inhabited it for years. I've been using Perl since 1987 (Perl 1), and acceptance that anything in Perl could be called "production quality" was non-existent to minimal in the beginning. It was a long time before a client would take a deliverable in Perl, as opposed to a deliverable created using Perl. Perl has a long history in this "indirect" demimonde. On the other point, one way of answering the question of "Is it production ready?" is to ask: "Suppose the time were available for you to write this in C or C++, as opposed to Perl using the Text::Balanced module? Would you think the result posed more risks, as many, or fewer?" thanks, jeffrey kegler	[reply]

Replies are listed 'Best First'.

Re^2: Is Text::Balanced production ready?
by Jeffrey Kegler (Hermit) on Nov 13, 2007 at 02:09 UTC

That categorization looks rather odd to me. In what sense is a module you shouldn't use in production code good for "developing other modules"?

My understanding of what Damian means here, includes things like use in test scripts; use in creating chunks of code that will be incorporated in production code after examination and testing; use in pretty-printers and checking for best practices; use for automatically rewriting all your array accesses to hash accesses; use in examining test results; etc. This "indirect" realm is surprisingly large, and Perl has inhabited it for years. I've been using Perl since 1987 (Perl 1), and acceptance that anything in Perl could be called "production quality" was non-existent to minimal in the beginning. It was a long time before a client would take a deliverable in Perl, as opposed to a deliverable created using Perl. Perl has a long history in this "indirect" demimonde.

On the other point, one way of answering the question of "Is it production ready?" is to ask: "Suppose the time were available for you to write this in C or C++, as opposed to Perl using the Text::Balanced module? Would you think the result posed more risks, as many, or fewer?"

thanks, jeffrey kegler

[reply]