In practice, I don't do Catalyst because I refuse to install half of CPAN just to get it running, particularly given that, when you have over 200 dependencies¹ involved, the odds are pretty high that the majority of them will not be actively used by any given Catalyst app. There are limits to how far you should bend over backwards in your attempts to avoid duplication.

¹ "Catalyst now depends on Moose among other things, with a very long overall dependency change[sic]. How long? I downloaded Catalyst 5.8 along with all of it’s non-core Perl module dependencies. The result was over 250 modules, not counting the Catalyst modules themselves, or anything in the Test::* name space. Bleh."
- http://mark.stosberg.com/blog/2008/11/review-of-mojo-087-a-new-perl-web-framework.html

Yeah, I don't enjoy the long lists either and I think it could be pared down but I have Cat running just fine on a budget host and in three different other environments under the test server, fastcgi, and modperl with very little effort so whatever critique or displeasure is involved is not actually in the way of using it. The Cat devs shouldn't be responsible for maintaining things like Set::Object or Data::Visitor and too often I see folks at work using the anti-dependency shtick as an excuse to put snippets from the Cookbook everywhere.

Just last week our manager insisted we use the &commify recipe we all know and love instead of Number::Format or something. This was one week after we were asked for an estimate of how long it would take to i18n our main app because we have some interest from a foreign buyer. So, we just put one more hurdle in the way of ever being able to manage that; commas v points in numbers based on locale. We chose to hardcode US-ish behavior based on fear of a single dependency.

Duplication isn't just wrong because of code drift, it's also wrong because it's a certainty in a big app that someone else has solved that part of the problem better than you can or that they will improve the solution over time in their code base.

200 dependencies is scary but you can view it as something like 10,000-50,000 free hours of development instead. :)

Duplication isn't just wrong because of code drift, it's also wrong because it's a certainty in a big app that someone else has solved that part of the problem better than you can or that they will improve the solution over time in their code base.

Excellent point.

Personally I don't understand the complaints about dependencies. Maybe this is because I am not, nor have I ever been, a sysadmin and have always been a programmer. From the point of view of a sysadmin, install time/issues are something that can really gum up your day, especially if you are installing on a more than one server. From my perspective as a programmer, the amount of time saved not having to write, test and maintain a piece of code is well worth the time it will take me to install it a handful of times.

-stvn

That is a poor example unless Number::Format has improved since I had to debug a co-worker's use of it. Which it probably has. For one thing I submitted patches for the more egregious problems.

What did I dislike, you ask? Suffice it to say that the bugs that I found in that module taught me things I didn't want to know about Perl. Such as that $_ is always in package main (so using its formatting statements in a map statement messed up the passed in array), and my $foo = "bar" if $cond; has some really strange behavior.

It is hopefully much better now. But the scars would still cause me to shy away.