[Catalyst] RFC: The paradox of choice in web development

Zbigniew Lukasiak zzbbyy at gmail.com
Mon Feb 16 10:15:05 GMT 2009


On Sun, Feb 15, 2009 at 10:04 AM, Dan Dascalescu
<ddascalescu+catalyst at gmail.com> wrote:
>
> I think I can agree with that. What I'm saying is that there's simply
> too much useless choice. Random example:
>
> Data::Dumper
> vs.
> Data::Dump.
>
> I've just discovered Data::Dump but it appears to beat the crap out of
> Data::Dumper. Yet does it say anywhere "Hey, if you're getting started
> with Perl and need to dump variables, use Data::Dump, and don't waste
> your time investigating other modules"? If I were the author of
> Data::Dumper, I'd somehow retire the module, or plaster a note in the
> POD redirecting people to Data::Dump. Imagine a programmer new to Perl
> picks up an example that uses Data::Dumper. Will they find out about
> Data::Dump? No.

There is also:

http://search.cpan.org/~jmcnamara/Data-Dumper-Perltidy-0.01/lib/Data/Dumper/Perltidy.pm

And frankly I think this naming convention is the way to go - this is
much better findable than Data::Dump. And there is also
Data::Dumper::HTML, that just recently I found very useful for
debugging in web context.

And to complicate the things - I cannot say for sure that this is the
reason, but it is quite probable that Data::Dumper would have much
better interface now if it was not in the Core.  Modules that get into
the Core generally get frozen and stop evolving because too many
things rely on them.  This is a complex matter and I lean towards the
'steady release cycles plus rigorous deprecating' proposed by
chromatic in his recent Modern Perl blog notes
(http://www.modernperlbooks.com/mt/).

Cheers,
Zbigniew
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/



More information about the Catalyst mailing list