I find that learning new tools gives me perspective on why I do things the way I do. Sometimes the new techniques and technologies get integrated into my day to day tool-set, sometimes they don't. It depends on what the New Thing makes easier, simpler, or possible.

I learned CGI when I was confronted with creating more than a single static web-page; CGI::Fast when I started running up against the performance wall with CGI. I learned mod_perl of necessity when I started a contract at a site the used it in preference to CGI::Fast.

I looked at the 'inside-out' object formalism when it came out and adopted it for a home-project before deciding that it was really over-kill for what I was doing. Abigail II and I had a couple of spirited debates (in both senses -- lively and we were both drinking beer at the time) about the techniques culminating an an agreement that I'd try inside-out on a live (paying contract) some time and report back.

I consider Moose and Catalyst in the same light. They are different ways to approach my basic problem: how do I apply my knowledge and tool-set toward solving a 'Problem in the Real World'. That is, after all, what I am paid to do.

Knowing about Moose or Catalyst increases my store of knowledge and adds to the number of problem solving techniques in my arsenal. The more different techniques I have at my disposal for sorting my Client's Problem, the better my chances for building them a good solution, on time and under budget. (Which is also what I'm paid for.)

I wonder if we had Moose a few years ago, if more developers would have stuck with Perl instead of jumping ship. I think it's fab, and it deals, in part, with many of the problems some people have with Perl's OO model. Check out Chromatic's Attributes of Elegant Perl: Concision for an example of one of Moose's benefits (it actually uses MooseX::Declare, a Moose extension)

I wonder if we had Moose a few years ago, ...

But we did, Moose is almost 3 1/2 years old at this point :)

... if more developers would have stuck with Perl instead of jumping ship.

Actually, I have had several people tell me that Moose has kept them from jumping ship, and I know of at least one case (Piers Cawley) who has come back from Ruby-land because of Moose (MooseX::Declare specifically).

-stvn

True, we did have Moose 3.5 years ago, but it was just one of the competing object solutions, and it's Meta model benefits weren't apparent to me in those days. I seem to remember Inside-Out objects being popular at the time, as well as of the MakeMethod-type of solutions. Plus MooseX::Declare is the cherry on top! I'm hoping that Moose becomes a defacto standard, kinda like Catalyst and DBIx::Class. The alternatives will still be available to those who want them (I use CGI::Application rather than Catalyst myself), but it means those looking for a solution don't just trawl through CPAN and guess...

Whether you should invest the time and energy to learn Moose depends on what you want from an object system. If Moose provides you what you want, by all means, learn Moose. If you have no need for its features, do something else. If you don't know yet, postpone till you do know.

Thank you. In that case, I like to know if anyone NOT willing to learn Moose because of its disadvantages or it may not be helpful in their work.

Functional programmers aren't interested in OO, so no Moose for them :)

A lot of MooseX tensions require perl 5.10, for some this isn't an option.

Yes. It makes complex code direct and easy to read. It's close to what Perl 6's objects will look/act like. It's a good resume entry. It will improve your knowledge of OO theory and the capabilities and the features it affords like traits and roles. It's flexible. It's still vanilla Perl OO beneath so most of the things to which you are accustomed can be used with it. The basics are easy. It's fun.

I'm curious - what sort of bells and whistles do you think Moose and the MooseX modules are missing?