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. :)
In reply to Re^3: Modern Perl Programming Highs and Lows
by Your Mother
in thread Modern Perl Programming Highs and Lows
by derby
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |