Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Modern Perl Programming Highs and Lows

by derby (Abbot)
on Apr 28, 2009 at 11:19 UTC ( #760581=perlmeditation: print w/replies, xml ) Need Help??

Lately I've been wading through all the Modern Perl/Enlightened Perl blogs (thanks to the Ironman challenge). I really like the syntactic sugar of Moose and specifically MooseX::Declare. I had give Moose a whirl some time ago and for whatever reason, I was not impressed (more than likely it was my inability at that time to wrap my head around the concept). The past few days, I've been running through the BankAccount/CheckingAccount example from the docs and something clicked. Then I ran through mst's Devel::Repl and that's when the power really hit home. However, here's the low ... the dependency chain on Moose and MooseX is *long*.

Now CPAN is good to me and it did the right thing but after about an hour and *several* dozen dependencies, I was starting to get worried. Is the cost too high? Not for me ... but would I be able to sell it as reasonable to TPTB? I think so but that started me down another path. Several years ago there were great strides made to remove a lot of the cruft from the standard installation. Will we swing back around and increase the standard install with Moose or is it time for something else? Is it time to start treating Perl like linux and have *distributions* that package what we need? A Sysad distro? A Web App distro? A Modern Perl distro? I don't have an answer ... just curious.


Replies are listed 'Best First'.
Re: Modern Perl Programming Highs and Lows
by moritz (Cardinal) on Apr 28, 2009 at 12:20 UTC

    The first answer is Perl 6 - it will come with a strong object system in which much can be declared, so I guess it'll make most (or all) of Moose and MooseX::Declare superfluous.

    But I agree that Perl distributions are a good idea. Actually ActiveState ships with more than just the core modules by default, and I wouldn't be surprised if Strawberry did as well. Many Linux distributions already have native packages for many CPAN modules (for example Debian has packages for Moose, named libmoose-perl). So it's already happening in some sense.

    Putting more modules into the Perl core is to be avoided, and neither the Moose folks nor p5p really want it.

Re: Modern Perl Programming Highs and Lows
by perrin (Chancellor) on Apr 28, 2009 at 13:37 UTC
    If you just want the basic features of Moose in an easier-to-install package, there is Mouse. BTW, the improvements in the Moose documentation were a recent project by Dave Rolsky (autarch), sponsored by a grant from The Perl Foundation.

      Actually Mouse should really only be used in cases when it is a hard requirement to use less memory/cpu/dependencies. We are trying to actively discourage people from using it for convenience sake, since we hope by the end of this year to have completely removed the need for it to exist at all.

        we hope by the end of this year to have completely removed the need for it to exist at all.

        Can you elaborate on what need you see for it to exist and how you aim to remove it? Depending on how you define the terms, this statement could mean anything from "we're working to improve Moose's speed" to "Moose is replacing blessed hashes in /usr/bin/perl".

        I won't speak to the performance issue, but you could cut down the dependency insanity by not requiring Test::Exception. Is your Test Flavor of the Day worth 17 dependencies?
Re: Modern Perl Programming Highs and Lows
by Your Mother (Bishop) on Apr 28, 2009 at 15:57 UTC

    I also have a hard time choking down some of the dependency lists for things I like but many CPAN authors have been taking a lot of responsibility for making sure their code passes tests and won't jam up a long list of stuff. I'm really impressed with it. Ultimately, it also seems exactly the right course. Should Catalyst, for example, duplicate the snippets it uses from 50 other modules just to have a self-contained release? No, (exact) duplication is a great evil in this stuff. It should be in its place with its changes, bugs, expert owners, etc.

    On the Linux dist front; they are very convenient but I have seen them used repeatedly at $work as an excuse to not fix bugs and do without features for a year or more after they become available. I know tracking builds and installations ad hoc is difficult but I really dislike the way dists play out in the real world. They move the burden from the sysadmin to the hacker. And maybe that right there sums up why I'd keep CPAN/Perl chugging along as it is. It only seems to be improving and it's driven by peers, not anyone up or down the chain.

      In principle, I agree that exact duplication is to be avoided.

      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 dependencies1 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.


      1 "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."

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

Re: Modern Perl Programming Highs and Lows
by stvn (Monsignor) on Apr 28, 2009 at 21:54 UTC

    Well, keep in mind that Moose is different from MooseX::Declare. The later has a much longer dependency chain because honestly it is doing a lot more (parsing signatures, fiddling with op-trees, wrapping methods, etc). This is quite different from the core Moose dependency chain, which is fairly short for what it provides.

    Now, I have personally run into occasions where a Moose install was pretty hefty, but in those cases it was usually because some of the core modules I had were old. If I recall correctly it was the Test:: modules that were out of date and that did result in a seemingly long dependency chain.

    Is it time to start treating Perl like linux and have *distributions* that package what we need? A Sysad distro? A Web App distro? A Modern Perl distro? I don't have an answer ... just curious.

    One of the eventual goals of the Enlightened Perl Organization is to eventually have an "enlightened perl" distro that will include all these things already. I am not sure where this project is currently at, but if you are interested in helping you should shoot them an email.


      The status of the EPO Group working on that project is probably easiest to find on teh EPO wiki

      Moose's dependencies according to cpantesters is 24 modules including 4 core modules under 5.8x. This number drops under 5.10x because more of them are folded into core.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://760581]
Approved by citromatik
Front-paged by Arunbear
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (4)
As of 2020-08-04 17:24 GMT
Find Nodes?
    Voting Booth?
    Which rocket would you take to Mars?

    Results (33 votes). Check out past polls.