What to do....
So I've been lingering around p6-language for a few months now, and have 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.
Re: What to do....
On Fri, 2003-11-14 at 22:23, Rod Adams wrote: (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
Re: This week's summary
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley wrote: newsub and implicit registers [...] ops [...] that IMCC needed to track. Leo has a patch in his tree that deals with the issue. Sorry, my posting seems to have been misleading. The register tracking code is in the CVS tree. I seem to be doing rather well at misrepresenting you in the summaries recently. Maybe we should make that the new running joke.
