magnify
Home coding Explaining Why Moose is Awesome – The Direct Way
formats

Explaining Why Moose is Awesome – The Direct Way

The Perl community knows that Moose is awesome as evidenced by the amount of talks at YAPC and the number of times it is mentioned on blog articles and discussion boards. However, to me, what often seems to get lost is why Moose is awesome and why it is relevant, especially to those outside the Perl community. At the same time, I think it is vitally important to simply and directly convey why Moose is awesome to both increase Perl awareness and encourage other languages to adopt similar techniques.

This article covers how I explain Moose and why I think it not only addresses the key concerns with Perl but makes it more attractive when compared to some other languages as they are today.

The ideas here started when I was recently showing off a project of mine to a YC-funded Xoogler that asked me what it was written in. When I told him it was mostly Perl, he said, “Oh Perl, you’re old school!” I could have left it at that if it were true, but it wasn’t and I wanted to explain why it wasn’t. I had specifically chosen Perl for this project in 2011 over Python because it provided things that were not yet in (or popular in) other languages. This is how I presented it.

Why: Moose makes Perl more Maintainable than Other Languages

Nothing is more attention grabbing than saying something opposite to what people expect so this is exactly what I said. Of course, the gauntlet was already thrown so I wanted to respond in kind. I was able to say this honestly because I backed it up using my recent experiences using Perl and JavaScript with some Ruby, Python and C#. At the same time, it is important to tell it as it is and not sugar coat things. I’ve had my share of head scratching when looking at my own 6-month old pre-Moose Perl code so I’m painfully aware of Perl’s write once reputation.

The way I explain it is that while it can be argued that some languages may be cleaner than Perl on a line-by-line basis, my view is that Moose makes Perl cleaner and more maintainable on a class and method basis. By providing an expressive attribute getter/setter system, Moose helps you freeze APIs and limit the scope for maintainability to the attribute / method level. It does this by adding one key feature…

How: Moose adds Static Typing to Getters and Setters

What Moose really does is add type checking to getters and setters. While it supports some built-in types (integers, numbers, strings, arrayrefs, hashrefs, etc.), the real power is in composite types like an arrayref of objects e.g. ‘ArrayRef[Email::Simple]‘. By freezing the API, Moose improves coding speed and reduces errors, enabling me to write 1000s of lines of code and having it all run with minimal typo correction. The great thing about this explanation is that static typing is something that people are generally looking at and interested in for many dynamic languages so once you get this point across, the benefits are easily understood and don’t have to be explained further.

Bonus: Moose Eliminates Write Once Code

Generally, I don’t have to go further than explaining static typing with Moose; however, it can be useful to note that Moose also eliminates write-once Perl code by providing a “template” for getter/setter creation. Creating classes this way ensures that your classes will follow well-ordered, well-understood convention. After having to maintain several old pre-Moose Perl apps, I was pleasantly surprised when I opened a 6 month old Moose class and had to double-check to see if it was written months ago or just the other day.

Summary

So there you have it. In one fell swoop, the key benefits of Moose are explained in a way that addresses long-running, key concerns with Perl with key features not yet readily available, but often desired, in other languages.

By succinctly explaining why Moose is awesome, hopefully we can raise more awareness for the great work being done by the Moose team and the Perl ecosystem.

What You Can Do

If you like this approach, one thing that can be done to more quickly explain the effectiveness of Moose programming is to create side-by-side code examples of code with Moose and without Moose, in other languages. This is often done to compare and contrast languages and I think it would be useful to more succinctly explain the benefits here. Expressive modern Perl code can impress those outside the community, there just needs to be more of it.

 
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
2 Comments  comments 
  • http://openscripture.net/sterling Sterling Hanenkamp

    I would be careful about saying that Moose adds static checking to attributes. It does add something that looks like type checking to attributes and it is very useful and very powerful, but it is not static type checking. Setting the isa on an attribute gives that attribute a type constraint, but this is more akin to input validation that it is to typing. Under the usual circumstances this distinction does not make much of a difference.

    It does make a difference which comes out most clearly when you perform type coercion. When coercion happens the system starts by guessing what type the value could be (from the list of available coercions) and then applies the coercion. In static typing, the type of the value is known at compile time. From the standpoint of analysis that’s a pretty big difference.

    • http://johnwang.com John Wang

      I agree with what you’re saying about the implementation details and in my conversations I make it clear that Moose doesn’t provide actual static typing but provides a similar benefit. Here, I try to suggest this by saying it’s a check on “setters” (“getters” should probably be removed for technical correctness) which I think of as a runtime check as opposed to an attribute which would happen at compile time.

      That being said, often times you only get 30 seconds to explain why something is powerful. In that context I want to explain why something is useful and worth looking into from a benefit perspective so it is important to use terminology that someone will understand, even if it is just a first approximation.

      From that perspective, do you think it is a useful description?