in reply to Re^2: Modern Perl Programming Highs and Lows
in thread Modern Perl Programming Highs and Lows

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. :)

Replies are listed 'Best First'.
Re^4: Modern Perl Programming Highs and Lows
by stvn (Monsignor) on Apr 29, 2009 at 18:04 UTC
    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
[reply]
      Maybe this is because I am not, nor have I ever been, a sysadmin and have always been a programmer.

      Interesting point and one I've not seen made before. I have worked as both a sysadmin and as a programmer. Unfortunately, I can't remember what my feelings on long dependency chains were prior to my taking a sysadmin job. OTOH, I do recall some bad experiences involving vendors breaking my code with updates to the libraries I depended on, so they may have been similar.

[reply]
Re^4: Modern Perl Programming Highs and Lows
by tilly (Archbishop) on May 01, 2009 at 23:29 UTC
    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.

[reply]
[d/l]

      That's good to know, though I did include "or something" because nothing had been decided or vetted but I saw it supports locales. You did submit bug reports to improve the module, right? :)

[reply]
        Better yet. For the bugs I found I submitted code demonstrating the problem and patches that fixed the problems.
[reply]

In Section Meditations