Considering I've yet to encounter some non-CPAN code (that is, code that actually runs solving some companies problem instead of just having the potential of doing so) that actually uses Moose, I'm not quite convinced about the "best-fit for most people" part.

I am the author of Moose so obviously I will be biased, but we have about 7-8 major production systems at $work that use Moose extensively to solve real world problems for some very large companies. Best Practical (RT, SVK, etc) uses Moose/Mouse in there new SD project and some of the Hiveminder API modules. Shadowcat Systems (of Catalyst/DBIx::Class fame) has deployed systems using Moose. I know that Moose is being used at ValueClick, IMDB, Yahoo! and Symatec to name a few. In short, just cause you haven't encountered it does not mean that it is not out there, because in fact it is very much out there. This is not to say that it is the "best fit for most people", even I won't agree with that statement.

What I do know is that Moose will get out of fashion and will be replaced by another system.

s/Moose/$anything_technical/g

In case you haven't noticed we work in a very "fashion" driven industry, this is just how it works. If you asked yourself that question before making all your technology choices (and weighted it heavily) then you would still be writing code with assembler on wire wrapped boards.

Assembly? Bah!

Any Real Programmer knows that 0100 is ADD, that 0001 is "perform this instruction if the Zero flag is clear", the numbers of the registers involved, etc. The right bit masks to combine such simple concepts and a reference to remind you of the bit patterns for all those extraneous instructions like SADDSUBX is all you need. ;-)

That's relevant to ARM, BTW. Some inferior Johnny-come-lately platforms probably used the wrong values. They might even involve microcode, the losers. ;-)

Tradition, nostalgia, popularity, trendiness, neophilia, neophobia, and familiarity are all powerful forces. We happen to be in an industry in which all of them compress into decades rather than millennia. Sometimes that's fortunate and sometimes it's unfortunate. What really matters most is what works, but we'll probably never overcome the "cool" factor. It's even fashionable to not care about trends.

What we should really try to figure out is why the first movers before a trend move to something and why the last movers abandon it after it's unfashionable. Once trend following, neophilia, neophobia, xenophobia, xenophilia, and every other secondary, tertiary, or downright meaningless motivation is eliminated we can see the true value of what a system's designer got right and what was broken.

Moose is used in the project at work (BBC).

And, I just came back from a London.pm tech meet where the topic of the talks was... Moose.

So statistically, Moose is used in 2/3 of all data points in this post. That should tell you something (what exactly is unclear though).

/J

Well, here's another non-Moose data point. We don't use it and probably never will. What I like about the current Perl approach to objects is that it is thin. It provides a layer of insulation to consumers of your objects without getting in the way of finding a best implementation internally to the object and without adding a lot of overhead.

That isn't to say we don't use formal OOP when the situation warrants it, but for systems that are that large and complex (loads of subclasses, co-varying types, etc), we use Java (gasp!), since the strict typing and compiler do a great job of inferring the correctness of code built around complex type systems. IMHO, any system complicated enough to justify the complexity of Moose needs something more robust and inferential than Moose.

Best, beth

Well, here's another non-Moose data point. We don't use it and probably never will.

Fair enough, it is not for everyone or every situation. In fact, I have found the people who are most resistant/hesitant to using Moose are the ones who have a clean set of OO "best practices" which work perfectly fine for them already. For them Moose only seems to provide extra baggage and not much more.

That said, I think this perception is feed by the fact that Moose (to them) seems only to be a "sugar" layer over normal Perl OOP. This is very much not true. Moose is built on Class::MOP, which is a formal object system for Perl which provides a pretty robust meta-programming environment. Every bit of "weight" in Moose is there for good reason and in fact the "sugar" end is quite light. Several former non-believers were converted after they took a closer look and realized that Moose is not just about the sugar. But as I said above, it is not for everyone, however I do encourage you to look a little deeper before you dismiss it (assuming you haven't already, in which case this statement is less for you the poster of this post and more for you the reader of this post).

What I like about the current Perl approach to objects is that it is thin.

Yes, but that thin-ness means you have to do a whole lot of tedious and repetitive code to just get some of the basic features that any other OO language would provide. I love the core Perl OO system too, but every time I used another language and then returned to Perl, I found myself wanting more.

It provides a layer of insulation to consumers of your objects without getting in the way of finding a best implementation internally to the object and without adding a lot of overhead.

Ah ha, see Moose does that for you (the programmer) as well. The meta-object protocol (MOP) provides a the means to change the internal representation of the object without having to re-write the entire object system. See MooseX::Object::GlobRef and MooseX::InsideOut for examples of that.

Yes, I know you will say "but it adds a lot of overhead", but this is really only true of compile time, not at runtime. Typically Moose accessors will benchmark as fast as hand-coded Perl accessors, and if you make the class immutable we will inline your constructor and destructors as well.

... but for systems that are that large and complex (loads of subclasses, co-varying types, etc), we use Java (gasp!), since the strict typing and compiler do a great job of inferring the correctness of code built around complex type systems.

Careful, Java's type system is not really that bullet proof, the simple fact you have dynamic casting means there is a giant gaping hole in the foundation of the type system. And javac very much does not "infer the correctness of code" it only verifies that you have not broken any of it's rules. If you really want to verify correctness you need something more like Haskell or Ada, but even those languages have their weaknesses.

IMHO, any system complicated enough to justify the complexity of Moose needs something more robust and inferential than Moose.

I disagree here because I think that while Moose itself might be a complex system, Moose code itself tends to be simpler then traditional Perl OOP. Including the complexity of Moose itself would be equivalent to saying "I cant justify using Java because javac is too complex a program".

Again, I must disagree with your implication that Java is "inferential" in any way. Java infers nothing, you explicitly tell it all about your types and classes and it just verifies that you are being consistent with your usage, any inference of "correctness" after that is your own, not Javas.

-stvn