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:

1. 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.

2. Less boilerplate: Moose is not the only option for doing that.

   And most of the others are cheaper.

3. 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.

4. 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'.

5. 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.

6. 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.