Why I use Moose, Perl's Post Modern Object System

The following is an edited and updated version of a Moose advocacy bit I wrote on the Google AppEngine for Perl project mailing list quite a while ago.  I decided to republish it here since with the recent release of Catalyst 5.8, which uses Moose as a core technological foundation, I felt it would be a good idea to reflect on why I think this is a great thing.  There are quite a few tutorials and code overviews for why Moose is a superior object system (links at the end of the article) but I don't see many postings that are simple reflections on Moose and why I, as a developer, am happy it belongs to Perl.

I also think the Google AppEngine for Perl project is not getting nearly enough love and I'm hoping to draw a bit of attention to it as well.

You can read the original here, but that version has an embarrassing number of spelling and grammar errors :)

Without Moose, I'd probably have lost the faith and left Perl for another language.  This is not a lightly written statement, since I've been using Perl as a primary server side development language since 1996.  When I first started programming I gravitated toward Perl for two reasons:  First, it let me do what I needed to do without getting in the way or forcing me to jump through a lot of hoops.  Second, it introduced me to what is now broadly thought of as the Open Source community, an idea of how software development and knowledge sharing could be that excited my idealistic nature.  I have to imagine there are quite a few programmers in Perl with a similar story.  A lot of us started using Perl because the module CGI made it trivial to create server side web forms, while DBI created a straightforward means to shuffle information between the web and back end databases.  Perl did what I needed it to do.

However, over the time, my love affair with Perl diminished.  Perl's default Object Oriented system is very minimalistic and I found myself envious of languages that allowed --and even encouraged-- a best practices approach in modeling your application.  For the first time I started to feel like Perl was getting in the way of me just doing what I needed to do, mostly because I was spending a lot of time jumping through hoops and not expressing my problem domain.  Even worse, this lack in Perl caused many large projects to create there own ways to close the gaps left open by existing methodologies.  How many different and incompatible component systems have been written for Perl?  How many systems for making it easier to do object oriented programming?  And each time you go to load a new module from CPAN, you end up also loading a bunch of dependencies for yet another half baked OO framework that is only being used on a handful of projects.  This reality makes it much harder for newcomers to usefully contribute code, since each time you have to learn a new underlying framework and all its idiosyncrasies.  That's why most important Perl CPAN modules have at most a small handful of contributors.  Worse, if fed the common belief that Perl is spaghetti code not suitable for larger applications.  Now, I do think having competing ideas is good, and that value is one of the things that makes Perl strong, however for basic, core programming tasks the lack of consistency really hurts us.  Where would Perl be if CGI had not been so complete, or if DBI did not become the dominate method of accessing databases?

Moose has reinvigorated my love for the Perl language, it's community and programming in general.  It cleanly solves the problem of Perl's minimal OO features.  I write less boilerplate and spend more time expressing my problem domain.  It provides a wealth of expression around which a rich economy of best practices and shared solutions can grow.  Additionally, since it's written for programmers by programmers, I find that it fits my brain better than any other ivy tower OO solution.  It has a large and growing community of active developers, more than any other competing system OO framework for Perl AFAIK.  Lastly, some of the most important Perl projects of our day, such as Catalyst, DBIx::Class, etc are either using Moose or moving toward Moose.  For me, Moose makes OO Perl just as expressive and fun as I found Perl to be when I first started writing website applications all those years ago.

Is it perfect?  No, certainly there is a lot of room for Moose to improve.  However, all the right decisions to let those improvements happen have been made.  The developer community is very serious about feature enhancements and about growing adoption of the framework as well as growing the number of contributors.  I am a case in point, since although I've been using Perl for more than 10 years, Moose is one of a small number of projects that I've managed to become involved at the contributor level.  Moose not working the way you need it to?  That's fine, come to IRC and make your case.  However, I would encourage to do your homework first, since the Moose channels have some of the brightest minds I have ever had the chance to see in action.

For me, properly written Perl starts with Moose.  It should serve as the basis for any serious project you may be about to undertake.

• For more about Perl.
• For more about Moose.
• The Official Moose Learning Manual
  
• For more about the Google AppEngine for Perl project.

Comments

[Hans]

John-But what _specifically_ do you like about Moose? You are quite emphatic how much you like it, but that does not really tell me anything.Also, how is Moose performance? Perl is quite slow if you are calling very small functions (manual inlining is sometimes necessary, ugh). And perl is also slow if you are handling a lot (100000 and more) of small objects. Doubling that overhead by going through an additional OO layer sounds bad to me.Thank you!Hans

[John Napiorkowski]

I wasn't really intending this to be a feature list of great stuff about Moose, it was more aimed as a meditation. I would say the number one reason I like Moose is that it makes using Objects in Perl very easy and it gets out of the way. For example, the way Moose does Attributes is really great. Unlike Java, which I like from a completeness and overall expressiveness view, which requires a lot of boilerplate code to get even simple things done, Moose and the Moose tool chain (like MooseX::Types and related) is very quick to roll out your ideas.I guess I'll write a new blog next, "Top 10 things great about Moose" and I'll make that more feature oriented. Until then I recommend the Moose project homepage which maintains tutorials and links to presentations that review Moose and discuss some of the features.For the speed issue, I know there are companies using Moose in production on websites getting 10-15 million pages views a day. So Moose can scale. I really can't speak to Perl being slow overall though, since for me it's fast enough and the scaling options are good. If you need a dead fast language, OCAML is rumored to be super fast.Without more context I really can't say more. For me, reducing complexity, and giving me a lot of open sourc code as well as a large community is more important than dead speed in a single process on a single box. Your needs may be different. For example, I wouldn't use Perl for realtime stuff, or for things like launching the Space Shuttle or writing heart monitoring software.

[Hans]

Thanks, John. I just saw you posted the "Top 10". Looking forward to reading it.As for performance: my perl-based software manages complex structured documents. They model as trees of 100s of thousands of nodes of different types. Kinda like how you'd model very large XML. Traversing these documents in pure perl is rather slow. I'm looking forward to a parrot JIT based backend. Simple objects might actually be fast then. Alternatively, an XS based backend has big problems with deployment....CheersHans

[John Napiorkowski]

Editorial note: I deleted a recent comment by "http://sandy183.vox.com/" since it contained an advertisement for a sexual therapy. I have nothing against it overall, but I object to someone misusing this conversation thread in that matter. I will quote the semi relevant part of the comment:[quote] Hey Also, how is Moose performance? Perl is quite slow if you are calling
very small functions (manual inlining is sometimes necessary, ugh) [/quote]There are numerous blogs concerning this topic. For myself, I find Moose performance to be more than good enough and the speed penalty over Mooseless Perl is small enough that give how much better Moose makes my Perl programming on every benchmark available (better code, less errors, more readable and maintainable, amazing community support, etc.) I have no reason to worry about the performance price.Your needs may differ. I heard Erlang is a very fast language, if crazy speed is a core requirement you may wish to take a look.