I agree partly, but not fully.

Where I agree is that we did a lousy job in having tighter control by
not requiring authors to record the opposing opinions or pointed out
deficiencies, not requiring more work on the implementation side, not
bestowing more power to the chairs/moderators, and so on.  The whole
term RFC might have been a bad move.

But I certainly don't agree on that the whole process was a fiasco.

Firstly, now, for the first time in the Perl history, we opened up the
floodgates, so the speak, and had at least some sort of (admittedly)
weakly formalized protocol of submitting ideas for enhancement,
instead of the shark tank known as perl5-porters.

(On the other hand, we need shark tanks.  If an idea wasn't solid
 enough to survive the p5p ordeal by fire, it probably wasn't solid
 enough to begin with.  In p5p you also ultimately had to have the code
 to prove your point, re the puny IMPLEMENTATION sections.)

Secondly, what was -- and still is -- sorely missing form the p5p
process is writing things down, dammit.  The first round of the Perl 6
RFCs certainly weren't shining examples of how RFCs should be written,
but at least they were written down.  Unless an idea is written down,
it is close to impossible to discuss it in any serious terms in the
email media.

Thirdly, to continue on the first point, now we have a record of the
kind of things people want.  Not perhaps a well-thought out list,
quite often suggested in a much too detailed way, trying to shoehorn
new un-Perlish ways into Perl, suggesting things that clearly do not
belong to a langugage core, breaking backward compatibility, and other
evil things.  But now we have an idea of the kind of things (both
language-wise and application/ata-wise) people want to do in Perl, or
don't like about Perl.  Based on that feedback we (errr, Larry) can
design Perl 6 to be more flexible, to accommodate as many of those
requests in some way.  Not all of them, and most of them will probably
be implemented in some more Perlish way than suggested, and I guess
often in some much more lower level way than the RFC submitter thought
it should be done.

Without the RFC process we wouldn't have had that feedback.
I vehemently disagree with the quip that we would have been better off
by everybody just sending Larry their suggestions.  Now we did have a
process: it was public, it was announced, it began, we had rules, we
had discussions, it had a definite deadline.

We certainly expected (I certainly expected) RFCs of deeper technical
level, with more implementation plands or details, or with more
background research on existing practices in other languagesor
application areas.  But obviously our expectations were wrong,
and we will have to work what we got.

$jhi++; # http://www.iki.fi/jhi/
        # There is this special biologist word we use for 'stable'.
        # It is 'dead'. -- Jack Cohen

Reply via email to