Larry Wall wrote:
On Sun, Dec 02, 2007 at 07:43:25PM -0800, Peter Scott wrote:
: I do feel strongly that we need some sort of solution to this so that Perl
: 6 is not merely an outstanding framework that leaves all domain-specific
: extensions to the end user.
Perl 6 as a language doesn't address this (except to keep the library
namespaces precise and accurate), but that doesn't mean it won't get
addressed or that we don't want it addressed. We're aiming for an
ecology more like Linux, where we distribute the kernel, and others
build distributions around it, and those distributions are designed
to make it easier for various classes of end users.
Bear with me a minute: compiler implementation is conceptually different
from language specification, yet language design choices affect compiler
implementation, and hence compilation is taken into account when
designing a language. The two are closely intertwined.
So too, it seems to me, are language utilisation and language design
intertwined, whilst appearing theoretically to be conceptually separate.
The reasoning that eliminates as much problem related functionality from
the core is solid. But if it leaves to others or to fate, the infant of
perl6, I fear perl6 will not survive much beyond being a beautiful baby.
If ordinary users, such as myself, cannot use the language because
functionality does not exist, it wont be used.
So much thought has gone into the language design. Surely, some
concentrated thought by the inventive and resouceful minds of who lead
this project should go into language utilisation and popularisation.
Surely some common problem areas have to be addressed so that
functionality - of some form - is available when p6 is at a stage it can
be released? Database (SQL), web, xml processing as my guess for common
functionality that people might need. The modules may change in the
future, or evolve. But initial modules, and mechanisms to replace them,
will help users use perl6.
Richard
In any case,
I'm certain the community will also make sure that something CPANishly
downloadable is there, since no distribution can possibly guess right
all the time. But a single editorial board is not scalable over the
long haul. We'll eventually need multiple such boards that compete
among various perceived and real ecological niches. We can start
with one distribution as long as it is explicitly realized that anyone
can fork it at any time, for any reason. Then let Darwin take over,
and see what the service economy does with it.
Now, it might well be that a Perl standards body could specify a
mininum suggested set of modules for any distribution to enhance
interoperability, but we haven't got to that point yet, I don't think.
Someone with an organizational bent could get a running start to come up with such a editorial center, but setting standards out ahead of
practice is rarely the optimal approach. And right now, we would,
at best, be guessing from Perl 5 "best practice". Maybe that's good
enough to start with, if we can get any two people to agree on what
the Perl 5 best practices are. :)
Anyway, that's the reasoning behind supplying as little as possible
with the P6 kernel. We don't want anyone mistaking it for a
distribution in the first place, nor do we want us language lawyers
to evolve into any kind of "official distribution board". Central
planning doesn't scale over the long term. We should restrict our
"federal" activities to those that help all the "states" get along
with each other, at least well enough to avoid a civil war.
Of course, as the U.S. proved at the beginning, when you fear a
strong federal government it's possible to invent too weak a federal
government. There's a balance in there somewhere that we're still
trying to figure out...
Larry
