some lessons from Perl 6

From: Eugene Eric Kim (
Date: Tue Jul 25 2000 - 12:55:04 PDT

As Grant mentioned on unrev-ii, at last week's Open Source Conference,
Larry Wall announced the Perl 6 initiative. Not only do they plan on
completely rewriting the internals of Perl, they plan on, in Larry's
words, "rewriting the Perl community."

To kick off this experiment, they launched a new mailing list on July 19,, whose mail archives are available here:">

The list was set up ostensibly for discussing the early stages of
rewriting the community. They wanted to to consensus on issues
such as: Where should we discuss these issues? How will people be
able to propose changes? What will be the organizational structure? How
will decisions get made? The list was not meant to be a place to discuss
actual language design issues. Organizationally, the only thing truly set
in stone was that Larry, Perl's creator, would be the man in charge of
language design.

Based on the first week of activity of this mailing list, I think there
are some important lessons that we can apply to the building of the OHS.

1. Value of views.

The first items on Doug's vector is to make e-mail addressable, and to
come up with multiple views for e-mail archives. In a sense, the outcome
of this vector item will be a glorified e-mail archiving software, but in
reality, there is much more to it.

If you look at the archives of, you'll notice that they
are not really very valuable for reading through the archives. Part of
the reason for this is that the mail list software they are using seems to
be breaking headers, so you can't get real thread trees. Even if this
were not broken, however, we can certainly see how better views could make
it easier to browse through this information effectively.

2. Design by consensus doesn't work.

Even though people weren't supposed to discuss design on this list, as
soon as it was created, people sent literally hundreds of e-mails within a
few days on various design issues. Perl is a complex language and has an
enormous user community with some very strong opinions. Clearly, from a
methodological standpoint, design by consensus does not work with this
type of community (as if we didn't already know that), regardless of how
good the support tools are.

3. E-mail addressability and the OHS can help the design process.

Larry Wall is in charge of language design, and while he can do whatever
he wants, knowing Larry, he will actually read all of the design-related
messages on the Perl 6 bootstrap mailing list. Some of the messages and
threads may actually influence some of Larry's design decisions. With
the OHS (and initially, with citable e-mail), as he begins to develop a
design document, he can link specifications to relevant threads. This
creates a useful form of organization for accessing the knowledge within
the mailing list, as well as documents part of the reasoning behind
certain decisions.

This works for requirements as well. Some people have proposed
requirements to the list (again, even though this is not the list's
purpose). As Larry starts building a requirements document, with the OHS,
he could link individual requirements to relevant threads, with the same
advantages as cited above.


+=== Eugene Eric Kim ===== ===== ===+
|       "Writer's block is a fancy term made up by whiners so they        |
+=====  can have an excuse to drink alcohol."  --Steve Martin  ===========+

This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:47 PDT