The modernist movements of the late nineteenth and early twentieth centuries in art, architecture and music, were all about rejecting the accepted wisdoms, forms and dogmas that existed up until that time. These essentially aped the values and forms of the Ancient Egyptians and Greeks which were rediscovered as the Dark ages gave way to the Renaissance. The basic premise was to deconstruct and simplify what had gone before.

So, in art, they rejected the stiffly posed, formal portraits; formulaic 'perfect' landscapes and repetitive, fussy, still lifes, in favour of exploring line, form and color in the abstract. Primary colors and rectilinear forms were depicted and explored for their own sake.

In architecture, the ornate decoration and complex structural forms were again simplified. Favouring function over form; rejecting the Greek proportional orthodoxy and Gothic detailing; they moved to clean lines, light facades and simple outlines; whilst adopting and advancing the latest technologies in construction.

Post-modernism in these fields to some extent returned to utilising the formalism and rules of the ancients, seeking to combine them with the techniques pioneered by the modernists to produce realism, and 'character'. Along with that formalism came complexity--both of forms and the rules governing them--and weight.

To that end, Moose is very post-modern.

I've not tried Moose. I've read up on it, tried some examples, but haven't done production code with it.

I think it's extremely interesting. The possibilities.. Autodocumentation.. hmmmm.. yummy!

If you want to learn perl, I get the feeling there are some down sides to using Moose.

• 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.
• Some people complain that it's slow.
• Some people complain about the million dependencies it has- and installing them.
• It's in development- Yes, but so is perl- right.. 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.
  Perl's OO hack I think is elegant and simple.

That said.. That wouldn't stop me from using it - The thing will evolve and solidify as people use it and feedback to the developers.

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.

-derby

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.

-stvn

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

s/priceless experience/worthless experience/. Native Perl OO mostly ends up being about writing lots of repetitive useless code and forcing the programmer to deal with things that they should never even have to think about.

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

If you consider only bugs in Perl vs. bugs in Moose, you're probably right (although Moose is pretty solid). If you consider the number of bugs that you are likely to create, then Moose probably results in more solid code, especially once you start doing anything interesting.

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

An old joke from Larry Wall was that perl is a post-modern programming language.

The idea being that the essence of "post-modernism" is cut-up and collage, working with lots of different pieces from different sources without privileging any one point of view, or any one doctrine of what the right way is of doing things.

This joke does not, in fact, apply terribly well to Moose, which is more like "retro-nouveau-modernism" or something.

Well ++ to you doom! I've never understood modernism and post-modernism, your link to Larry Wall's paper has finally explained it all. Ta muchly.