not all of us are as speed obsessed as you seem to be.

Was that a personal dig? Never mind.

IO-bound programs are essentially event-driven. That means state machines, which virtually precludes good encapsulation, or even good abstraction.

Many applications are performance intensive (cpu-bound, data-bound), rather than IO-bound. And indeed, cpu-intensive applications are exactly the ones which most benefit from OO. That's why so many of the graphic simulations of cpu-intensive algorithms (from sorts to searches to the travelling salesman and other NP=hard problems), are written in Java. OO allows the mechanics of the graphics simulation to be separated (encapsulated) from the mechanics of the algorithms being simulated. The algorithm is just coded to operate on an extended data-structure (eg. a subclassed array or hash) and the internals of the enhanced DS take care of displaying the effects of the algorithmic actions upon that DS.

Perl is getting faster (the Moose and Class::MOP test suites both run noticeably faster in 5.10)

Perl is getting faster, because they (p5p) optimise for performance. Because they realise that the performance of their code impacts the performance of every piece of code built on top of it. Perl deserves to have the power and completeness of the OO-implementation that Moose gives them, so that Perl users can get on with the business of writing their applications instead of reinventing the OO wheel each time around.

That's what impresses me about Moose. The clear, clean (and in its basic form, simple) interface to a complex infrastructure that can do pretty much anything that is required. You can start out writing just as much code as you need to get the application running with a few 'has this' and 'has that' and 'extends something else' for each of your classes, and then get right on with writing the detail of the application using those classes. Once you have the application running, you can go back and enhance the classes to parameter typing, pre- & post- contracting, introspection and all the other good stuff required to make it robust. But you can prototype it quickly without all the frills and and if you have to scrap it and start again (that's what prototypes are for!), then you haven't needed to expend effort adding the frills before you found out whether it was going to work. That's what really impresses me about Moose. The ability to get something going quickly without have to cross every T and dot every I, safe in the knowledge you can go back and add the frills as and when you need them. But...

Any library that sits at the core of other peoples applications, like Perl itself, should do its utmost to impose as few performance penalties as possible. I think people writing cpu-intensive applications (like tos) deserve Moose (or something very similar to it). Then they could get on with the business of writing their applications and not re-inventing OO mechanisms (badly!). And, on the basis of my limited exploration of Moose guts, I truly believe that it wouldn't take a huge effort to reduce the performance penalty for using it to the point where it wouldn't have to advertise itself as for "non-performance critical applications only". It might require the dropping of a few Holy Cows though.

I totally disagree, this is a performance intensive application, and Moose has well known performance issues.

Graphical apps like tos' are only one of a whole range of non-IO-bound applications that would really benefit from a sound, extensible, thorough but essentially simple (interface-wise) OO-framework like Moose. And given the obvious skill-levels and motivation of the Moose team, it's my belief that it could be Moose, if the motivation was there to make it so.

Anyway, I'll get off your case now. Congratulations on what you've already achieved with Moose.