I just started using Moose in production code. At first I found it's documentation dense and unapproachable but a few blog posts cleared the air. Right now, I'm approaching Moose as I did C++ (C++ as a better C). Sure I'm nowhere near using the full power of Moose but just having auto-generated constructors and setters/getters is a win for me.

You'll miss out on learning a lot of perl. Yes, you can learn this other ways. But having to actually learn how to build an OO class (perl module)- is priceless experience. Of course, it can be argued you shouldn't have to learn what you won't be learning right away

Moose does not hide anything but the arcane OO mechanisms, so you will not really miss out on learning all that much. Perhaps you are referring though to horrors such as manual type-glob fiddling, AUTOLOAD and some of the crazier OO techniques described in Damian's book. In which case I think your point is debatable and many people consider the usage of those techniques to be ill advised for even the most skilled of perl programmers.

Some people complain that it's slow.

To clarify, the startup time is slow, runtime is not. Moose has to bootstrap the entire object system and create several meta-level objects for your classes. Once you enter the runtime though, Moose is very often comparable to the equivalent hand coded Perl and/or slimmer modules like Class::Accessor and Class::Accessor::Fast.

Some people complain about the million dependencies it has- and installing them.

Actually it has 4 non-core dependencies, I explained in some more detail here. As long as you have a reasonably up to date perl, it is really not that bad. The worst is when you need to update Test::Simple and Test::Exception, as they have long dependency chains that can get ugly. But this is really not Moose so much as the Moose test suite.

It's in development

True, but I would think that would be a good thing since you want active development in your tools and not bitrot. Moose is highly stable and has been so for a couple years now. It is used in many large codebases in many large companies. We are very responsive about bugs, and have a pretty large test suite. I also consider the 550+ other CPAN modules that depend on Moose to be our "external" test suite, so if you factor those in, we have 10s of thousands of tests. Also factor in the recently ported Catalyst and all the apps that run on it too.

In short, I would not worry about Moose's maturity and stability at all.

++ great discussion.. Interesting point on slow startup vs slow runtime.. Useful to know for daemons and mod perl stuffs.. Stuff that may do heavy lifting.. (Not the most useful for funky cli trick scripts.. but then.. Paul Graham (who's actually a lisp hacker.. ) has some interesting arguments about coder time vs cpu time. I'm sure perl hackers will take kindly to it.)

I gotta tell ya, the use of Moose is radical enough that with it.. I would argue you're not writing perl anymore. (Nothing wrong with that!)

hobbs made a very simple but important point 786957, about how the coder is likely to introduce bugs themselves.

Perhaps there is discussion on, should Moose be native to perl?
Maybe this is the way that perl should implement OO- is that a stretch?
I mean.. If we open a book that teaches perl, and the OO section comes up, should it just teach Moose? (Not a rhetorical question.)

I have some concerns about .. the development of perl addresses some of the issues that Moose does- is this incorrect? If so.. Should we not trust the development of perl over the development of Moose? (It's also possible that this last, is not an important issue. As the world is evolving rather quickly.)

Not the most useful for funky cli trick scripts ... but then.. Paul Graham (who's actually a lisp hacker.. ) has some interesting arguments about coder time vs cpu time

True, and for a lot of programs the couple of seconds extra that Moose and the classes written in Moose will take will be nothing compared to the 20 minutes it takes to parse that log file, or 10 second it takes to download that web page, etc etc. As with everything in life, there are tradeoffs and you eventually have to pick you battles.

I gotta tell ya, the use of Moose is radical enough that with it.. I would argue you're not writing perl anymore. (Nothing wrong with that!)

Well, your certainly not writing Perl 5 OO anymore yes, but aside from a few new "keywords" vanilla Moose is still very much Perl 5. Now if you throw in MooseX::Declare and Moose::Autobox, then yes, your into a new world there, but those are both optional :)

Perhaps there is discussion on, should Moose be native to perl?

People mumble about putting Moose in core every once in a while, put frankly I don't want the problems that go along with that (dual life-ing, etc). There is some fiddling about for Perl 5.12 about including some level of Moose and the MOP into the interpreter itself, but more likely it will be a subset of the MOP enough that it makes Moose faster and still allows others to do OOP the old way if they want.

Maybe this is the way that perl should implement OO- is that a stretch?

Well I stole a bunch of it from Perl 6, and MooseX::Declare is bringing the syntax of things even closer. But in the end TIMTOWTDI is too strong in Perl culture (which is a good thing) and not everyone loves the Moose.

I mean.. If we open a book that teaches perl, and the OO section comes up, should it just teach Moose? (Not a rhetorical question.)

This is exactly what the new Catalyst book does (kinda). As for future Perl books, well you will have to convince someone to publish one, after all, Perl is dead ;)

I have some concerns about .. the development of perl addresses some of the issues that Moose does- is this incorrect? If so.. Should we not trust the development of perl over the development of Moose? (It's also possible that this last, is not an important issue. As the world is evolving rather quickly.)

Well, the core Moose hackers are close to and in cases even overlapping with, the p5p crowd enough that I don't think you need to worry about that. Any future perl features that overlap with Moose features will either be intentional (collaboration between the p5p and Moose groups) or be addressed in Moose early enough that you will never know it happened. In fact, we were using the 5.10 MRO features very shortly after 5.10 came out with seamless backcompat (thanks to MRO::Compat).

-stvn

"Well, I don't think I'm crazy saying that using perl's implementation of OO is more stable and dependable then using Moose right now."

I'm hearing a lot of good things about Mouse as a lighter-weight alternate to Moose.

(Nothing I like better than having ten-thousand WTDI to investigate some time, in my copious spare time... the curse of the perl programmer.)

I'm hearing a lot of good things about Mouse as a lighter-weight alternate to Moose.

Actually, we have been discouraging the use of Mouse since it is just impossible to make Mouse and Moose smoothly interact with one another. Any::Moose was an attempted solution to this, and it works to a degree, but all too often Mouse code will outgrow what Mouse can provide and the author will end up switching to Moose. This is exactly what happened with CHI actually.

-stvn