In an online venue, space isn't the problem like it is in magazines. The real issue is that a real example needs to be explained. If I grabbed something from work, it would need explaining as to what it is, why it's necessary, and take a considerable effort to grasp before doing any work on it.

The toy examples embody the interesting features: Take something that works, derive from it to add a new attribute. I did steer clear of the "equal" method which is common place, because testing for equality is more special in Perl than just using some provided method.

If you can think of any more interesting toys, please let me know. The other extreme is something so abstract that you never remember what it means. That is, m1 and m2 interact but it's just abstract names with no feel for what it does.

I think a lot of the appeal of Perl 6 is the refactoring of paradigms and cutting-edge features. Roles themselves are a case in point. It's what I wish I could do in any language I do major development in! C# missed the boat, and it's up to Perl 6 to embrace the new ideas.

Perhaps I'm seeing Perl 6 not as a language for golfing, but as a replacement for the professional development I do in C++, C#, etc. and notice what is problematic about the strongly typed languages. On the other hand, when I did Smalltalk in school, I was most amused at the section in the text book on debugging, since everything but one would be a compile-time error with strong typing.

As for performance, Parrot did JITing a long time ago and the performance of the virtual machine is quite good. I remember when C++ compilers could not run on PCs, and Ada compile and link time was a joke. I think strong typing will improve the performance of Perl, allowing premade dispatch tables to be used once a type is known. But look at the modern implementations of Smalltalk, Self, etc. for dispatch speed.

—John