What does Moose's mixins in role form give you over Ruby's mixins, or Scala's mixins, or PLT-Scheme's mixins, or just simulating mixins via a multiple-inheritance hierarchy ala Python or C++? I'm not going to spend a ton of time researching, but from what I see at links like http://search.cpan.org/~flora/Moose-1.05/lib/Moose/Manual/Ro..., it seems like a nice idea but it's certainly been done before and since in other languages. A lot of the features like method exclusion and aliasing or required host methods could easily be implemented in a library on top of your favorite dynamic language as well if they don't include them natively.
The MOP looks like a necessary tool for Perl's horribly designed OO that wouldn't be necessary for most other languages or could just as easily be implemented as a library. Python and Ruby both have what seems to be the equivalent of metaclasses. Most OO languages have some idea of what an attribute is. And so on. Once again, MOP looks neat, but it's certainly not unique to Moose.
edit: reading the MOP link more carefully, the idea of a class builder builder is more sophisticated than I originally thought MOP was, but as the link says, you're heading into esoteric territory at that point.
What does Moose's mixins in role form give you over Ruby's mixins, or Scala's mixins, or PLT-Scheme's mixins, or just simulating mixins via a multiple-inheritance hierarchy ala Python or C++?
Not sure what you mean. In Ruby, for instance, whenever a module is mixed in a hook method on the module is called. You can enforce any safety or correctness constraints on the parent class that you want at that point. You can easily imagine writing a library in ruby that lets you do the same things as in Moose in terms of correctness and safety. Similarly, you could write your own 'include' method that took extra parameters and performed the same mixin magic Moose is doing like excluding or aliasing methods, performing special handling of conflicting methods, etc.
My main point in all this is that, from my perspective, Moose may have a few bells and whistles beyond the base OO features of other dynamic languages, but these features are more 'nice to haves' than 'essentials. More importantly, these features could also be trivially added in other languages as libraries. Most importantly of all, none of these features is as important as starting out with a clean, well-designed language in the first place, and Perl is anything but clean or well-designed.
Duck typing suffers from the false cognate problem, and mixins suffer from false cognates and potential collisions. They also do nothing to ensure type safety or optional type-based compile-time optimizations.
More importantly, these features could also be trivially added in other languages as libraries.
Non-Moose Perl 5, Tcl, Lisp-pre-CLOS, Lua, and JavaScript to some extent demonstrate the "you can roll your own object system trivially!" fallacy, especially when you want to use libraries written by other people. Likewise, I'm not aware of anyone who's used roles in a serious project who wants to go back to object systems without them.
