May I also congratulate you on your clear, concise writing.

I've read the piece twice through now, 2 or 3 times more and some of the implications might finally start to set in. As I read, three thoughts keep crossing my mind:

1. When oh when will someone come up with inheritance examples that aren't based on geometry or phylogenetics.

   Note: This isn't a criticism of your article. Space and time for real-world examples is rarely available.

   But useful computer programs for dogs that can bark and wag their tails, or chimera Goat-Lions are fairly few and far between in the real world.

   And, for example, there is rarely any real point (sic) in having a Point3D class inherit from a Point2D class. A 2D point is simple a 3D point where you ignore one component, as when mapping 3D space to 2D space. And that is just a method of the 3D Point class. Having the former inherit from the latter usually costs in terms of time, and saves little if any space. So it's usually more practical to just use a 3DPoint class and have done with it.

   In real-world applications, Manager is simply an attribute of Employee-- 1-bit in a flags field --rather than a superclass.

   Or, in those rare organisations that recognise that modelling themselves in terms of JobRoles that has-a Person attribute, rather than JobRoles that is-a person, makes more sense, benefit greatly. By using Encapsulation rather than Inheritance for composition, they get flatter, simpler hierarchies and greater decoupling. And that allows for cleaner, simpler segregation of datasets. Eg. Employee personal details can be kept in a separate DB from corporate structuring information, which greatly simplifies controlling access. Ever more important these days.

2. Who, other than academics pursuing PhDs in Category Theory are ever going to use all this power and complexity, unless the language forces it upon them?

   And aren't they gonna use something more academically credentialed (and hip), like Haskell or ML anyway.

   Without deep, compile time analysis, it will always be possible to construct an object or class at runtime and subsequently call a method upon it that will fail at runtime. Hence, it will still be necessary to: a) code defensively with exceptions; b) exercise and test thoroughly with 'bad data'.

   So, where's the benefit of using these optional strong type checking facilities if the can be both intentionally and accidentally subverted?

3. It's an awful lot of baggage and complexity for a runtime compiled language to carry around.

   Especially if there are few benefits to encourage anyone to use them?

Without a real-world, extensive, thorough (working, tested, costed, maintained) example to show both the benefits and costs of using these facilities, they will remain in that academic world of "wouldn't it be nice if".

Examples pulled from, or by reference to, other languages don't work if those languages use highly evolved and complex static compilation. Or heavily finance and extensively developed runtime JITing that took many years, $billions, and 5 attempts to get to the point where it is practical to use them. Perl 6 is unlikely to achieve such investment.

Using C++ and Java as examples encourages onlookers to look at the practical costs of developing projects using those languages. Neither are known for their simplicity of use, speed of development, ease of maintenance, nor absence of runtime failures. The benefits of adding such complexity to Perl 6, which will benefit from neither the multi-generational compile-time optimisations of the former, nor the extensively tuned, cross-platform runtime equivalents, are hard to perceive. If this thing ever comes to pass, what is the performance going to be like?

And will anyone using Perl, use the facilities that experience of C++/Java show, impose such complexities and costs on the development process?.

Sure, they are optional, so you can develop RAD-style omitting the complexity until you've got things up and running and then go back and add them where they will produce benefits. But, if the project is already running and tested, then it must already be handling all the possible errors that these facilities might prevent, so where is the mileage in retro-fitting them?

As always with my doubts about Perl 6, I'm hoping someone (or time) will prove me wrong. But, as with any opinion that I've given considerable thought to, I don't expect it to happen.