But when reading that, I just had that thought that it is actually more breadth-first exploration - while forcing to collaborate on one solution would be depth-first exploration.

This is rather abstract to discuss without a concrete example, but you need to have breadth and depth both, don't you? Having x modules all do the same task with different interfaces will shake out the "most preferred" over time or it will result in multiple interfaces existing to suit different types of people.

Again, collaboration is good, and for these modules to eventually use the same "engine" under the hood could be a good thing. Even though that model of development (create differing solutions and then try to cobble them together) appears to be ass-backwards and more work, it seems to work pretty well.


All dogma is stupid.

Seriously, I don't see Moose emerging as "the one best fit for most people" more than the Inside-Out fad, that Moose supplanted.

Which just serves to emphasise my point, it is a good thing that multiple solutions exist :-). From what I've seen, many people looking for a "more modern" Perl OO system seem to settle on Moose these days, and it seems to be getting to the stage where s/many/most/. But if you think there's a better alternative out there (out of interest, which would that be, btw?), then clearly it is a good thing that these alternatives exist.


All dogma is stupid.

And just look how many attempts (some by very well-respected authors) there were to devise a better object system for Perl 5 until one finally emerged that seems to be best-fit for most people.

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

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.

-stvn

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.

. <-- data point without Moose

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