Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Well, I use use for pretty much everything so my opinion is suspect. Most of the Pro 'Why Moose' bits have already be said so I will just add one. My gut feeling is that Moose based projects will have a much easier time growing and bringing new developers onboard. That's due to the fact Moose gives you most of what you need to develop well and after it's been in the wild for a few years we have developed a set of best practices. So Moose projects are easier to jump into. Non Moose projects have to incorporate a pile of bits just to be productive, such as something to speed up making accessors, validating parameters, dealing with inheritance ugliness, etc. Usually people end up rolling there own half baked, poorly written solutions, which a newcomer has to figure out before she can even start contributing. With Moose I look at the code and very quickly I know what is what. There are much fewer surprises to me. That's my opinion and I only have anecdotal proof of it. For example, Catalyst pre Moose was being used a lot but development and new releases seemed basically dead for like 18 months. Then, we are on Moose and it's been regular releases and updates. Sure, part of that has been fixing up some of the backcompat issues, but there has been a lot of new things added and there seems to be to be a lot more excitement about the platform. I expect similar things to happen when eventually DBIx::Class moves onto Moose. So, my feeling is that chooing Moose as a core tech makes it a lot easier to grow and manage a development community. That's why I would choose it.
    Waiting on the Road to Eventually, I lost my Place On Line