I was browsing Planet Perl Iron Man over the holidays and reading many of the "Year in Perl" recaps as well as the "Perl in 2011" predictions. One in particular caught my attention, that is What I would love to see in 2011 for Perl by claudio in which he has many nice words to say about Moose and the Modern Perl movement in general. As I started to read the comments I noticed one from brian d foy in which he said:
Note, though, that calling Moose "the preferred OO framework" is a bit of puffery. Some people prefer it, but I'll bet you most Perlers have never even looked at it. Not only that, the fragmentation of Mouse, Moose, Moo, and whatever else out there is starting to confuse people who haven't started yet (so it's a frequent question I get).
Of course from inside the Modern Perl/Moose bubble it is hard to believe that people haven't heard of Moose. And while I do think Moose is seeping out more and more, brian, with his unique position of being a well known figure both inside and outside of the Perl community, is very much right about the confusion over Moose, Mouse, Moo, et al. So after much discussion with the other core Moose team I decided it was time to write a blog post to help clear things up.
So of course we (the core Moose devs) believe that Moose is the best choice, but we are not so ignorant as to believe that Moose is the right choice for everyone and every environment. And it was this exact reason that brought about Mouse and which is currently driving the Moo effort. Additionally Moose has always tried it's best to not make you pay for features you don't use by doing things like compiling highly focused accessors and lazy loading features when possible, which, when taken to the extreme leads to modules like Class::Method::Modifiers and Role::Basic in which Moose features are extracted completely.
So how does all this fit into the Moose ecosystem??
So as I said, we think Moose is the best choice, but when Moose is prohibitive, either because of startup overhead or memory usage, then Mouse is currently the best choice and one we encourage. Period.
In reality, there is no fragementation here because Mouse is very much commited to maintaining surface Moose compatability and runs a fair portion of the Moose test suite successfully (minus the Meta-Object tests of course).
Additionally tools like Any::Moose allow you to defer your decision and/or provide both options when possible. There have even been a few MooseX:: modules ported to MouseX and while this practice is generally discouraged because there are simply too many moving parts to keep in sync, the need existed and so people oblidged.
In the end, what is important for us is that people are writing good OO code following the guidelines that Moose encourages. If, for whatever reason, they need to use Mouse to do that, it is okay with us. At least for now that is ...
Ever since the early days of Moose we have been searching for ways to make Moose startup time faster. Recent heavy profiling by core Moose devs, Jesse Luehrs and Dave Rolsky, has lead to some pretty hefty speed-ups and plans for even more in the future. But we know that there is only so far this path can take us.
And then we come to mst and Moo.
Moo is an experiment from the sick and twisted mind of mst to radically re-think how Moose goes about compiling all it's meta objects. It builds on ideas from even more experimental MooseX::Compile born from the equally twisted mind of Yuval Kogman and an earlier mst experiment called MooseX::Antlers.
While mst and a few other brave souls are actually using Moo successfully, it is currently only in very limited situations with very simple "baby" Moose code. And really in the end, if Moo succeeds, you won't even know it is there because it will just be part of how Moose does it's thing. It is at this point that the community may choose to deprecate Mouse, but we will cross that bridge when we come to it.
So again, no real fragmentation here either, it is all part of the grand plan.
The Perl community has long prided itself as being an group of independent minded (cough stubborn cough) people who don't just jump on the shiniest bandwagon or take the easy way out. We are well aware that Moose is a lot of Kool-Aid to drink and is not the right choice for everyone. And obviously because of this Mouse is not useful to these people either. So this is where some of the Moose inspired modules come into play.
In some cases these modules are re-implmentations of Moose features, in other cases they are parts of Moose that have been extracted because of their usefulness to others outside of Moose. Here is a short, totally non comprehenvsive list ...
- Class::Method::Modifiers - Moose/CLOS like method modifiers
- Role::Basic - Ovid's latest Role module
- Class::Load - This is the class loading code extracted from Class::MOP
- Package::Stash - This is the package stash/typeglob manipulation code also extracted from Class::MOP
- Class::Accessor - A "moose-like" feature was recently added to this old standby of Perl OOP
As we said above, the ultimate goal of Moose has always been to make writing good OO code in Perl a less tedious and repeative process. While we think Moose is the best way to do that, it is understandable that sometimes you only need a small part of it and all these modules provide this. And really as long as they maintain some level of commitment to Moose compatability, this works for us because it still serves our ultimate goal.
So sure, a little fragmentation here, but with a compatability commitment these really just become gateway modules to Moose.
And lastly, I wanted to touch on the number of modules that have been in some way inspired by or related to Moose development. This subject really deserves it's own blog post, but I think it is worth mentioning these modules.
- Dist::CheckConflicts
- Test::DependentModules
- Devel::GlobalDestruction
- Eval::Closure
- Package::DeprecationManager
- Try::Tiny
- Test::Fatal
- List::AllUtils
- Devel::ChangePackage
So hopefully this helps clear up some of the confusion that brian has seen on his adventures outside of the Modern Perl bubble. One of the really interesting and beautiful things about Open Source software development and the CPAN community in particular is that it really is a true meritocracy and functions extremely well as highly organized chaos.