RE: Perl, the new generation

> > What is Camel4 going to look like for perl 6?  What is going to
> be required
> > knowledge for perl6.  Let's just start by looking at Apoc2.  To
> use perl,
> > you'll have to know Unicode, you'll have to know OO, you'll have to
> > understand references.  Those are three very technical concepts
> that make
>
> Ummm, I must have missed the "have to know Unicode, have to to know OO,
> have to know references" part in the Apoc2.  Could you show it to me?

Stephen:

Using the features of the language whose underpinnings are based in OO,
Unicode, and references does not require a knowledge of the workings of
those features. Not yet at least. Unicode may be an exception if we start
thinking in terms of U"Unicode string" or something, but that's a guess
based on other languages.

Jarkko:

Understanding /why/ those features work in what way helps to understand the
features themselves. No doubt Simon would simplify the bucket lecture into a
rope-and-bucket lecture, or something like that, but many Perl users need a
bit more clarification. However, /how/ that clarification depends on how the
culture evolves to describe them.

Both:

I believe that the tree/folder semantics change on Win32 is a good example
of how things might change here. Where we used to talk about trees, we now
talk about file cabinets, folders, and files. The concepts are mostly the
same, but use different words now. For Perl 6, those words haven't been
invented, but I've no doubt we'll be able to simplify it sufficiently for
new users once we figure it out ourselves.

As for the size of Camel III, I imagine it would be only a few pages longer
than Camel II were it not for having so many unfinished and unsafe features.
The features of pink Camel were already community-tested, as were those of
Blue Camel. Camel III seems to have been written more by the P5P for the
P5P, since those new features were known to very few, and didn't have
adequate simplified-by-usage ways of being expressed. Camel III is certainly
no determining factor of the /pending/ complexity of Perl 6, because IMO it
was very poorly planned and written (features seem to have been stuck here
and there in order to have something to publish, rather than, as above,
allowing things to settle and coming up with a "natural order of things" way
to describe the changes (or sticking them into an appendix until they were
ready).)

A couple of things will simplify Camel IV:

1) O'Reilly will hopefully have learned that publishing a book for the sake
of having something to publish, before the general public has had time to
digest the ideas and start using terms that could be caught by authors. Tom
wrote the book very aptly for a P5P member, but probably needed to step out
of that P5P role and collect information in a way, uh, sort of not "straight
from the techies". I hope that made sense.

2) Hopefully, the community-orientation of Perl 6 will influence this, as
more non-techie speech is introduced to our vocabulary in a more open
environment, we will have better ways of describing features to non-gods. If
the "community orientation" falls apart, then, of course, this potential
avenue to a better Camel will likely fall with it.


David T. Grove
Blue Square Group
[email protected]
[email protected]