Re^3: Moose or Mouse for production use

What, besides declarative syntax and auto-generated accessors--which are both available at far less cost from other modules--does Moose buy the application programmer, that makes it worth the not inconsiderable costs?

Moose is much more than "declarative syntax and auto-generated accessors" it also provides:

A base class (Moose::Object) that provides a sensible default constructor and controlled object initialization (through BUILD/BUILDALL) and just as controlled destruction (through DEMOLISH/DEMOLISHALL). This may not seem like much, but is eliminates a whole lot of boilerplate.
A formal system for managing object attributes/properties/slots that allows the programmer to not have to worry about any details such as inheritance, etc. (basically this means you don't have to remember to call SUPER::new in your constructor and/or worry about initialization order).
A complete role system, which provides very useful ways in which you can re-use code that would otherwise not be as easily re-used. (Really once you get hang of roles, you will love them).
A powerful AOP-ish set of method modifiers (before/after/around).
A powerful and extensible type-constraint system.
A set of very useful extensions in the MooseX:: namespace.
A complete meta-programming environment, which means that everything above is introspectable, manipulatable and extensible.
... and lastly, all the above components are built on a single platform and is guaranteed to always work well together (this fact should not be underestimated).

Basically, everything any other modern object oriented language would give you (and then some).

For (my) best interest, I'm not looking for a straight list of features--which I have found around.

Okay, the "list of features" not what you want, here is a "list of benefits" for Moose.

Less testing - Why test what Moose already tests? Because Moose writes a lot of code for you and we very thoroughly test that code writing, there is no need to test simple things like accessors and such.
Less boilerplate - You can get up and running with a simple package Foo; use Moose; and Foo is now a full fledged class instead of just a plain perl package. One more line package Foo; use Moose; has baz => (is => 'ro', isa => 'Int'); and you can have access controlled attributes which have type checking and a constructor that accepts named parameters.
Less Tedium - Moose takes care of a whole lot of very repetitive and tedious tasks for you (managing inheritance, generating accessors, etc). By taking care of the boring bits for you, Moose eliminates a whole class of typo errors and other hard-to-track-down problems.
More Consistency - Moose respects the Perl motto of TIMTOWTDI, but does it's best to inject a level of consistency to the otherwise chaotic world of Perl OOP. The results of this is that it becomes easier to do basic OO things like inheritance because you can be sure of how the extended class will behave. Of course in isolation this is not that interesting, but when you realize this doesn't just apply within your project, but applies to anything else written in Moose. Which means that you no longer need to wonder if CPAN modules will be amenable to subclassing, if they are written in Moose, it should Just Work.
More Readability - This is not always true at first, but once you get familiar with the Moose way of doing things, it is very easy to pick up any Moose code and understand it in a relatively short period of time. No longer do you need to figure out how they have implemented their OO or what kind of accessors they are using, etc etc etc.
More Maintainability - With Moose you write less code, so therefore you have less to maintain. This leads back again to the point about consistency, because consistent code is easier to maintain, especially when you program in the large.

I'm more looking for examples of how people have used those features, to implement something that they would have had to implement anyway, had they used some other OO framework.

Here are 382 examples :)

Honestly, I think perhaps the best way to answer this question is to try out Moose for yourself. You have been dancing around Moose for years now and (as best I know) have not just sat down and tried to solve a problem with it. There is no better way to know if Moose is useful for you then to just give it a try.

-stvn

Comment on Re^3: Moose or Mouse for production use Select or Download Code

Replies are listed 'Best First'.
Re^4: Moose or Mouse for production use by BrowserUk (Patriarch) on Apr 02, 2009 at 03:46 UTC
Okay stvn, since you've chosen not to answer the question I asked, I'll try to respond to what you have said. You've repeated the features list I've already seen. But, you sound vaguely like Jeremy Clarkson when describing the latest run-of-the-mill family hatchback or people-carrier. He's always sure to mention the 17, strategically placed, one-touch-deploying cup-holders--and the vanity mirror! But you have to catch his tone. Features are all well and good, but unless they implement something for me, that I would have had to implement manually, then the questions become: Do I need that feature? Or will I benefit from that feature in seriously significant ways? You don't (and never have?) addressed these questions. If, like the cup-holders and vanity mirrors, their cost was insignificant, then fine, I'll take them. But, when the costs are significant--like say, ceramic disk brakes that I'll never need except for track days or the next time James Bond is chasing me down an alpine pass--then given the option, I'm going to decline to pay for that feature. So then we come to your second list. Which I can only describe as 'subjective sales hype'. That doesn't mean that there isn't important (or just good) stuff in there. It just means that when I see an advert for detergent or shampoo that claims "New formula" or "contains Jojoba extract", I don't instantly run out to buy it. I tend to ask: Is that new formula an improvement over the old one? And is it a significantly better formula than the supermarket's cheaper, 'own brand'? Or: Does the inclusion of Jojoba extract get my hair cleaner? Or improve its health in some significant way? Now let me take your "benefits" one at a time: Less testing: Only true if the code you generate is code that I would have had to write myself anyway. If the code you are generating is stuff that I wouldn't have written if I'd done it myself, then that code (and all the testing), is not just not a benefit--it is a cost. In terms of both memory; and performance; and of complexity when it comes to tracking down errors. With the best will in the world, no testing is ever 100%. So when my Moose based class starts doing something untoward, that isn't obviously routed in the code I've written, then I'm going to have to start digging into your code--even if it is only to convince myself that it really is my error and not yours. And that's when all that code that you've generated, that I don't specifically see the benefit of, becomes a real burden rather than a benefit. Less boilerplate: Moose is not the only option for doing that. And most of the others are cheaper. Less Tedium: Ditto. And when they get it wrong--or I get it wrong in ways that manifest themselves in the code they generate for me--their far less complex solutions, are far simpler for me to work through, to find the cause. More Consistency (...if they are written in Moose, it should Just Work.): That's a big 'if'! How soon will all the packages on CPAN, (Wikipedia currently quotes 14,800, though not all will be Moosable), be converted to Moose? Because until then, this benefit is not just an 'if' or a 'maybe', but a 'probably not'. More Readability (...but once you get familiar with the Moose way of doing things,): Hmmmm. I think you already see the problem here. If there are other benefits, then this cost--gaining that familiarity--may be worth while. But if there are no other benefits, then that cost is just a cost. And also one that any code shop will have to pay over and over each time they employ a new, non-Moose developer. It may be that once (if!) Moose achieves a high level of penetration, that the declarative syntax might become a benefit. But until that time, listing it as a benefit is--the politest term I can think of is--hyperbole. More Maintainability: Ditto 2 & 3. This is a generic benefit of both consistent code; and (done right) OO code. You can write consistent code without OO. And you can write OO code without Moose. The 382 examples are all well and good, but they do not tell me how the Moose solution stacks up against an equivalent non-Moose solution. Were they easier to write than if they had been done with one of the other syntax driven generators? Do they perform better (in all senses of the term)? Have they proved easier to maintain than previous, non-Moose equivalents written by the same author(s)? Most importantly, do they make good use of some Moose-only feature that significantly simplified their implementation? Or significantly enhanced their function or usability? And to that end, a pointer to single example of some reasonably substantial class--preferably written by someone with a reasonable amount of non-Moose, Perl OO, and who is not one of the Moose cabal--would be far, far more impressive than either the sales pitch or the numbers game. Especially if they could be persuaded to write a "wart's and all" comparison of their experiences. Honestly, I think perhaps the best way to answer this question is to try out Moose for yourself. Actually I have had a few goes, that I can categorise them in two ways: Sitting down and just following the tutorials and examples and knocking up a couple of trivial classes just to see how it is done. Lots of "That's cool". But also lots of "Why would I need that?", and "Hm. How would I use that?". A couple where I've set out to write something I needed, and attempted to use Moose to do it. On two occasions I ditched Moose and went with what I knew, because I knew that what I was writing would have a very limited shelf life. As such I wouldn't see any long term benefits, and the short term learning curve was more that I wanted to expend at those times. On the third occasion, the application was CPU-intensive, (genome manipulations), and I moved away from Moose for performance reasons. Indeed, I eventually moved the guts of the stuff into Inline::C in order to try and tame the extended run-times. Quite successfully. But I know you do not consider cpu-intensive code the 'natural home' of Moose, so I won't labour the point. That said, if there was a Moose facility that made it easy to fill in the guts of Moose methods using C, I think you'd have a winner on your hands. Okay. More of a winner than you already have :) Most of the Perl world seems to have bought into it already. And I guess that last point is my point. What is it (pragmatically speaking) that they are seeing that I am not? They cannot all be writing performance-irrelevant shopping carts and whatnot. Or working for big government where they can just throw hardware at the issue. And not all of them can be fashionistas. So, somewhere amongst them, there must be one or two that have chosen to use Moose, rather than one of the 'cheaper' or less 'of-the-moment' equivalents, because they see real, practical, hardnosed, unavailable-anywhere-else benefits. And that all I'm asking for. Some reference to some blog or write up that describes the experience of using Moose, for a real project, that goes beyond the "It's real cool!" level. In all our discussions, I've tried very hard to be non-negative regarding Moose. I really want to like it. But so far, maybe it's just the kind of code I find myself needing to write, I haven't seen the killer feature that balances the equation. And I've failed to find anyone else that describes one either. Maybe I'm just looking in all the wrong places. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^5: Moose or Mouse for production use by tilly (Archbishop) on Apr 02, 2009 at 05:16 UTC
I may have exactly what you are looking for. Ovid has a series of blog articles about his attempts to solve some of the inheritance tangles at the BBC. Here they are in order. Pictures of the class hierarchy in question. Initial thoughts on how roles might help. Then he ran into an interesting technical issue. More thoughts on refactoring using Moose roles. Then roles start to pay off for him. Then more on why this is good. This gives you a sense of how migrating to Moose worked out for a good programmer on a realistically complex code base. Better yet, he describes exactly why it was helpful for him, and you get to see both the positives and negatives with a timeline to indicate how much of an investment this was. Speaking personally my reaction was, "I'd rather work on a small code base without all of that complexity." But if I had to work in a larger code base, I'd definitely investigate whether Moose could clean things up.	[reply]
Re^6: Moose or Mouse for production use by BrowserUk (Patriarch) on Apr 02, 2009 at 07:42 UTC
I may have exactly what you are looking for. Indeed you do. Thank you to Ovid for making this available. And a double thankyou to you for not only pointing me at it, but for the effort you expended in picking out the series relevant to my interest. Above and beyond++ I am now absolutely convinced by Roles. I've had a gut feel that they were something special from way back when I first encountered them here and sought further information about them, and I've been an avid follower of any discussion about them whenever them come up here. Whether Moose (and the overhead and complexity of Class::MOP), is the only or best way of gaining access to them from P5 is still an open question in my mind. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^5: Moose or Mouse for production use by stvn (Monsignor) on Apr 02, 2009 at 06:07 UTC
It is way to late here (2 a.m. EST) to respond to you in detail, but let me just respond to one of your final points that struck a chord. But so far, maybe it just the kind of code I find myself needing to write, I haven't seen the killer feature that balances the equation. I think that is the key, the type of code you write is not a place where Moose would help. I get the impression (based on this and your other posts) you mostly write a combination of "limited shelf life" scripts and "CPU-intensive" programs, neither of which Moose (or even OO for that matter) really is useful for. Where Moose really has benefits is when programming larger OO applications such as "performance-irrelevant shopping carts and whatnot", which is also where OO in general is most useful (and why people don't write shell scripts in Java). Honestly, there is nothing that you can do with Moose that you can't also do without Moose, on some level it is about "how you get there". Sometimes it is nice to have "one-touch-deploying cup-holders" and "vanity mirrors" and also to know that even if your just driving the kids to soccer practice you have "ceramic disk brakes" to protect you and your family. And yes, I am implying that some day Moose will save your life !!! Install it now and Save 50%!! It slices, it dices, it can even cut at Tin Can!! Yes, that's right, act now ... get them while supplies last ... operators are standing by ... once in a lifetime offer ... -stvn	[reply]