What to do....
Rod Adams
noticed the following two trends:
1) All of the work forward on p6 design seems to come from either Larry or
Damian. (If there are others working in the shadows back there, please make
yourselves heard.) Most, if not all, the discussions of recent has been of
the form "How does <concept x> work in relation to <feature y> mentioned in
<Apoc/Ex z>?". While meaningful and worthwhile topics all, they do not
drive the language forward terribly fast.
2) Reality is constantly interrupting Larry and Damian's efforts in rather
nasty ways.
Taken separately, either of these trends are bothersome.
Taken together, this feels like a problem.
So the next question is, is there anything that can be done to improve matters?
I'm moderately certain that everyone wishes they could do something about
#2, I'm moderately sure that the p6 community has done as much as they can
on that account.
So my real question is, is there any way for the community to get together
and help take some of the load off these two in the design, or is the
current process the Best We Can Do (tm) and we just need to practice that
most unvirtuous of things "patience"?
Can apocalypses be something more along the line of scratches on the wall,
that then go through some level of deciphering or translation into
something closer to English? Are there topics that need brainstorming that
this list could take over?
I certainly don't want the language to loose the internal cohesiveness that
all languages need, and am suitably scared of "design by committee"... but
I'd like to think that there's something that could be done to help matters.
Comments?
Suggestions?
-- Rod Adams
PS -- I'm willing to commit several hrs a week to the effort.
Chromatic
> (If there are others working in the shadows back there, please make
> yourselves heard.)
Allison Randal, Dan Sugalski, Hugo van der Sanden, and I usually help
out.
> Can apocalypses be something more along the line of scratches on the wall,
> that then go through some level of deciphering or translation into
> something closer to English? Are there topics that need brainstorming that
> this list could take over?
Probably not as such. The Perl 6 RFC process demonstrated fairly
convincingly that there still needs to be one coherent design that takes
into account all of the various desires and uses.
Larry is shockingly good at that synthesis. (Just ask Piers Cawley;
he'll wax eloquent on the subject.) On the other hand, after every
Apocalypse and Exegesis, the discussion here exposes certain confusing
spots and improvements to the vision. It has to be synthesized first
though.
Or syncretized.
> I certainly don't want the language to loose the internal cohesiveness that
> all languages need, and am suitably scared of "design by committee"... but
> I'd like to think that there's something that could be done to help matters.
I'd really like to see people start turning the existing design
documents into story cards and programmer tests for Perl 6. That'll
make it much easier to implement the thing.
Design decisions have to be broken into individual tasks at some point.
Sure, some of them will change as we go along. There's enough there
that can be implemented now, though, without waiting for the big thud of
specifications. There's plenty of useful work to go around.
Running test cases are *much* easier to implement against than anything
else.
(Hey, it's been working fairly well on the Perl XP Training Wiki:
http://xptrain.perl-cw.com/).
-- c
Rod Adams
>I'd really like to see people start turning the existing design
>documents into story cards and programmer tests for Perl 6. That'll
>make it much easier to implement the thing.
So basically go back through the existing Apoc/Exeg's and break it down
into a long list of features. Then start building tests for each feature.
I'll give this some thought.
Piers Cawley
> Larry is shockingly good at that synthesis. (Just ask Piers Cawley;
> he'll wax eloquent on the subject.)
I'm not sure 'eloquent' is quite the adjective you were looking
for. 'incoherent'?