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.

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

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

About twenty years ago I worked on a system written in C++ that dealt with various financial instruments (fixed term deposits (with fixed or variable interest rates), stocks, bonds, options, futures and all that financial soup). The original architects had decomposed the different instruments into distinct classes (class Bond, class Option and so on).

Sadly, they completely missed the concept of ISA hierarchies. A lot of these instruments build on existing things, with an added twist. Yet the architects had merely cut'n'pasted code from class to another, for things like yield and amortisation calculations. Which meant that you had to chase down similar bugs in many similar classes.

Having learnt object-oriented programming a few years previously with such toy examples as decried by BrowserUK, it struck me that here was a real world example that was easy to explain, easy to code, produced tangible results and probably one of the few textbook cases where true inheritance hierarchies really make sense (insofar as compositional has-a architectures are much more frequent).

Fortunately enough for me, I left the project and moved on to greener pastures, and since then I have managed to forget just about everything I had learnt about the subject, but someone who has kept up with the field should be able to produce a simple example to demonstrate the basic concepts.

• another intruder with the mooring in the heart of the Perl

• Wow. This is my first introduction to Perl6 polymorphism, and, just, wow.
• The focus understandably is on the languages that most associate with OO programming, such as C++, Java, Smalltalk. However, your audience may be mostly Perl5 hackers. Consider including some additional verbiage (not too much, but a few sentences here and there) tailored to engineers who will naturally want to compare polymorphism to the object model of Perl5.
• At the top of page 4, s/the return the return types/the return types/.
• It's hard to believe the symbol for British currency is really being proposed for the language. Being an ethnocentric American, I wouldn't even know where to find it on my keyboard. A truly horrendous design decision.

Many thanks for the compliments. I am an accomplished writer, but programming magazines aren't what they used to be <sigh>.

I'm working on Perl 6 while I'm on sabbatical, and have been refactoring the documentation into a solid standard specification.

What more might I say about Perl 5 objects? I suppose I could be more explicit in summary, showing the typelessness and freedom compared with C++ etc.

The orthodox documentation has the "french quotes" like %h«hello $world». But every non-ASCII construct has an equivalent. I figured £ would be easier to type than ⍈. You're in China now, so maybe you can easily type 元? Seriously, I expect a lot of brainstorming over that. The important thing is to introduce syntax to correspond to the concepts — choosing a symbol not used for anything else let me not worry about messing up the existing grammar and be more succinct then discussing alternatives. It goes with the "shocking" part, I do think...

—John

With respect to Perl5 objects, I would guess there are three things a Perl5 hacker would be interested in:
1. A simple Perl5 vs. Perl6 example of syntax showing basic inheritance under Perl5 and Perl6
   • It will just give Perl5 hackers a reference point. "Oh, what used to be that now looks like that!"
2. How can the new architecture be best used to improve existing code? Perhaps you could provide one or two examples of the "low hanging fruit."
   • Think about the question that current Perl5 coders will ask: "What is the motivation to change?"
3. How will legacy code have to be changed?
   • For example, if you are using, say, a CPAN module that has been updated to the new object model, what are the most likely "gotchas" that will trigger errors?
   • Are there particularly widely used CPAN modules that you would expect to take full advantage of more restrictive typing or creative polymorphism (and thus possibly present some issues to legacy code)?
An alternative to sprinkling verbiage throughout the paper would be to create a 1-2 page appendix.

P.S. And add a table of contents.

... and have been refactoring the documentation into a solid standard specification.

I don't understand. Don't the Synopses already serve that purpose?

well written, though conflates what is defined now for perl6 versus what you are proposing.

Further down things go off track, and it looks like a language comparison followed by some really bizarre code that may or may not be written in Perl 6. You almost had me suckered into it, until I skimmed forward and saw your disclaimer at the end.

For example, the code uses '£' as a "symbol to indicate higher-order type conformance". You mention that this is not in a Synopses, and yet you don't explicitly say that this is a new proposal. This, and the other "Concepts discussed in this paper that are not on the Synopses" sound to me like this is not a really a paper about the Perl 6 language.

If the paper is a proposal, I would advocate marking it as such. If it is a paper about how to use the Perl 6 type system, I suggest documenting Perl 6 as it stands.

I like the 2D/3D point example. Mentioning quaternions is cool. Working quaternion midpoint code would be very cool. This would be spherical linear interpolation, and no, inheriting the 2D code won't cut it.

It is indeed marked, at the top: "This is a first look at a working design for the Perl 6 type system. It has not been accepted or endorsed by anyone, but is being shown for first impressions and feedback." The status will evolve through subsequent drafts. I wanted a wider discussion than just the perl6-language group since everything there is quiet agreement "you work on your area" and not much discussion. The ideas of higher-order polymorphism have not been explained to outsiders, just kind of assumed as part of the requirements.

Maybe you should start with the first page, so you won't be so surprised when you get to the last? Or do I need to put cute icons next to important paragraphs like with mass-market computer books? Maybe I'll change the font or the color.

I read the note at the top, and thought that 'it has not been accepted' referred to your paper, not the Perl 6 type system itself. I assumed that Perl 6 has some sort of type system, and it is approved at some level. So it didn't occur to me to read it as 'this paper is a proposal to change the Perl 6 type system.'

I would move the list of new and unapproved features from the bottom to the top.

I also suggest this pattern for the first sections. That is, move the conclusion to the top of the section, and explain what you are getting at. This drops the 'shocking revelation' motif, but would be an easier read. The text and examples are interesting enough. It doesn't need additional drama, in my opinion.

I think it would be interesting to continue demonstrating inheritance with the Complex and Quaternion examples that you hint at. You could show how they do or do not give correct answers when inheritance is used. What makes this interesting is that one would probably work, and the other probably wouldn't, which I think would make your point well.

It should work perfectly the first time! - toma