2.1 Language Development
Theoretically,
language
design is the driving force behind all other parts of the project. In
actual practice, Parrot development and documentation frequently
affect the direction and focus of design efforts. A design that gave
no consideration to what can be implemented efficiently
wouldn't be much use. Equally, if the design work
followed a strictly linear path, it would be a waste of developer
resources. The Parrot project can't afford to go on
hold every time they need information from a future area of design.
For example, the design of OO syntax hasn't been
completed yet, but the design team took time to define enough of the
required semantics so that development can move ahead.
2.1.1 Development Cycles
Design
work goes in cycles. Each cycle begins with a quiet period. During
this time, the list traffic is fairly light, and Larry is rarely
seen. It can seem as if the project is stalled, but in fact, this
part of the cycle is where the bulk of original design work is done.
Larry disappears when he's working on an Apocalypse.
It's the most intense and creative phase.
The next phase is internal revision. Larry sends a draft of the
Apocalypse to the design team for comments and makes changes based on
their suggestions. Sometimes the changes are as simple as typo fixes,
but sometimes they entirely alter the shape of the design. Larry
repeats this several times before publishing the document. This is a
very fast-paced and dynamic phase, but again, low on visible results.
Next is the community review. Usually the first day or two after an
Apocalypse comes out are quiet, while the ideas soak in. Then the
list begins to fly. Some people suggest changes, while others ask
about the design. This phase reflects the most visible progress, but
the changes are mostly refinements. The changes introduced at
community review polish off the rough edges, add a few new tricks, or
make simplifications for the average user. Here the community takes
ownership of the design, as both the design and the people change
until the two are a comfortable fit. The Synopsis, a summary released
by the design team soon after each Apocalypse, assists in the
community review by breaking down the ideas from the Apocalypse into
a simple list of points.
The Exegesis comes next, and its process is much like that of the
Apocalypse. List traffic slows again while Damian writes and the
design team revises. The Exegesis responds to the community review.
The practical example at the core of each Exegesis explains the parts
of the Apocalypse that were hardest to understand and fleshes out
some of the holes found in the community review. The list bursts into
another flurry of activity as the community reviews the Exegesis.
Then the cycle starts all over again.
2.1.2 Getting Involved
The primary cycle of Apocalypses,
Synopses, and
Exegeses is not the only movement in design. Constant activity on and
off the list packs around the larger cycle. Old decisions are
revisited; future decisions are previewed.
Getting involved in Perl 6 design work is as simple, and as
difficult, as joining the list. Subscribing to a list takes almost no
effort, but the most valuable contributions don't
come from people who respond to an idea here and there, though those
are certainly welcome. The posts with the greatest impact come from
people who take the time to learn the system—to figure out what
Perl 6 is all about.
If you want to make a valuable contribution, get on the list and
listen. Work to understand the issues behind each thread of
discussion. Soon you'll find there are repetitions
in the themes, guiding principles that shape the debates.
Form a mental map of the new syntax. It's not an
easy task. There are no interpreters available for Perl 6, so if you
forget how a particular feature works you can't just
experiment. Mainly, you'll have to search through
the list archives—over, and over, and over again. And the
syntax keeps changing. You'll have a perfect grasp
on a feature just before it changes. It can be frustrating, but it is
well worth it.
|