Nathan Torkington wrote:
> We're lucky to have the experience of Chip to draw upon (he's already
> blazed some of the trails we'll be turning into fully-paved four-lane
> highways with Waffle Houses and Conocos), as well as a lot of people
> who've worked with perl5. They know what works and what doesn't,
> and experience is going to be invaluable in something as complicated
> as a Perl interpreter.
Unfortunately the greatest volume on the various p6 sublists tends to be
coming from the least experienced people. The comments based on common
sense and long experience tend to be lost in the hubbub of uninformed
noise. In retrospect I think the various sublists should have been
moderated and read-only, and have been populated with the handful of
people who understand most about a given area - and no, I don't include
myself in that list of people, although I would have liked to have
listened in.
The whole p6 process is more bizarre than bazaar, and I really can't see
how on earth a useful product is going to come out of it. Interest and
enthusiasm are great attributes, but in the end are no substitute for
knowledge and experience. If p6 is to be successful it needs to be
carefully designed and meticulously implemented. To do this
successfully it will need rigorous selection of the people carrying out
the work. This will inevitably mean that some people will be left on
the sidelines, and when that happens a lot of the current enthusiasm
will I fear turn to bitterness and disillusionment.
I feel it is grossly unfair to carry on this pretence of development by
brownian motion any longer, and that it is about time that the p6 core
developers (you know who you are!) started to be honest about this. A
lot of people will inevitably be disappointed when their enthusiastic
contributions are discarded, and I have seen absolutely no discussion of
the process by which RFCs will be accepted or rejected (and saying
'Larry will do it' isn't good enough). I've seen endless and
stultifying discussions of code repository tools, but very little talk
of project teams and deliverables.
The most difficult part of this process is sorting out the human issues,
not the technical issues, but that is the very area that seems to have
received least discussion. The body of code that comes out at the end
of the process is nothing like as important as the group of people who
are responsible for giving birth to it, but at the moment the focus and
priorities seem to be completely awry.
I'm sure the immediate response to my comments is that I'm being
unnecessarily pessimistic, and indeed I hope I am. However, past bitter
experience tells me that I'm probably at least partly correct, so please
don't discard my comments out of hand.
I'm sorry but I really can't stomach watching this slow motion train
wreck any longer, so good luck and goodbye.
Alan Burlison
