Re: Proposal for groups
On Mon, Dec 04, 2000 at 07:56:21AM +, Alan Burlison wrote: > How about a design document (format to be decided) and a 'design + > commentary' document which is the design document with the condensed email > discussion inserted into it as the commentary. That way there is a design > spec for the implementation, but also the 'why we did it that way' is > captured for posterity. Mailing lists are OK for having the discussion, but > aren't very good for recording it for posterity. I'm inspired by the perl5 > digest produced by Simon, which I think is a really, really useful thing - > you can use it to get the essence of what went on and why, and then drill > down to the meat if you need to. I'm planning to write (in my copious free time) an open-source-licensed book on the implementation and design of Perl 6, which should capture for posterity the sense of the discussions we will have had while hammering out the design: Several models were discussed for garbage collection, but XXX turned out to be the best for our purposes, because . YYY initially looked good, but had the disadvantage that , and it was felt that . We also considered ZZZ, but all agreed that . -- The sky already fell. Now what? -- Steven Wright
Re: Proposal for groups
> I'm planning to write (in my copious free time) an > open-source-licensed book on the implementation and design of Perl > 6, which should capture for posterity the sense of the discussions > we will have had while hammering out the design: This reminds me of: Hmm, doubtful. The source code generally wasn't there when I needed it. -- Larry Wall when asked if he learned Perl from the perl source -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Proposal for groups
On Mon, Dec 04, 2000 at 07:56:21AM +, Alan Burlison wrote: > How are you going to publish the design? Asking people to follow email > discussions and try to piece together what is proposed from that doesn't > seem a very optimal way to go about it. How about a design document > (format to be decided) and a 'design + commentary' document which is the > design document with the condensed email discussion inserted into it as > the commentary. Are you asking for a Design Document (tm) to be published/updated along with an Annotated Design Document (tm)? Sounds like what Tim Bray did for the XML Spec at http://www.xml.com/axml/testaxml.htm. Perl6 should produce something like that as part of the design process. Z.
Re: Proposal for groups
As another example of a process that seems to be working well (as far as I can tell by being a lurker) check out the xml-dist-app mailing list archives at http://lists.w3.org/Archives/Public/xml-dist-app/ They have a draft up in the web [1] and the Subject lines directly refer to such and such sections of the draft. When you discuss an issue it's unambiguous what you are talking about. Of course, as almost always, "working well" is a direct function of the editors time and skill... [1] http://www.w3.org/2000/xp/Group/ -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Proposal for groups
On Sat, 2 Dec 2000, Nathan Torkington wrote: > * it's difficult for the design to happen through the questions Is that really true? Have we tried? As far as I can tell we've got a lot of well-intentioned people that for whatever reason are spending very little time making Perl 6 happen. Let me explain why I think this is a useful comment instead of just slander from the sidelines. I'm somone who's reasonably knowledgeable about compiler technology and about Perl internals. Still, I'm not so expert that I feel comfortable leading the design of the Perl 6 internals. I'd hoped to be involved as a skilled helper - able to develop and debug proposed systems. The problem is that I can't be of much use until the people that really are qualified to design this stuff start producing designs. So, here's my opinion: we have enough structure. All the people are here that are going to show up. Now it's time to do the work and that means the experts have got to dedicate some serious time to sketching out the skeleton of this beast. Once you've done that then I think you'll find there are more people around to add the needed muscles, skin and brains. If you need to go off in a room alone to that, well, I guess that's your option. I just don't think you've actually given the existing structure much of a trial yet. -sam > > How about we do this to design the architecture and API: > > perl6-internals-design is for a team of no more than 10 people. These > people should have experience either with perl5 or with a similar > system. Mail to this list goes to perl6-internals-design and to > perl6-internals. > > perl6-internals is a public access list, where folks can feel free to > question and kibitz. The design team will probably want to have a few > people on the public list as well. This is where the consciousness of > the rest of us can be raised. We can see what they're doing, ask > questions, and make suggestions. Because the meta discussion happens > off the -design list, designers will be able to tune it out if they > have to focus on the task at hand. > > This lets us satisfy these goals: > * open process, both for visible and participation > * small team doing the design (elephant is a mouse designed by >committee, etc) > > Make sense? > > Nat >
Re: Proposal for groups
Alan Burlison writes: > seem a very optimal way to go about it. How about a design document > (format to be decided) and a 'design + commentary' document which is the > design document with the condensed email discussion inserted into it as > the commentary. That way there is a design spec for the implementation, Cool. You're volunteering to edit it? Nat
Designers step forward now
Simon Cozens writes: > As for me, I hate this "self-selection" thing because it forces me to be > immodest. Oh well, better get used to it: Me. I think I'd be useful. Excellent. Anyone else who wants to be part of the initial design team, now is the time to speak up. If you have perl5 internals experience, or design experience with a comparable project, then offer your name to Dan Sugalski. Let's see how we go by Friday, and then consider pruning if we have too many people. It's no tragedy either if we only have 3 or 4. The individual experience of the participants is far more important than the number of participants at this stage (this can and will change when we get to test cases and implementation). We will keep the number of people small (5 to 10, smaller being better) and their job will be to come up with the architecture and API for the systems. We can watch their work and comment, but on a separate list. Nat
Re: Proposal for groups
Nathan Torkington <[EMAIL PROTECTED]> wrote: > How about we do this to design the architecture and API: > > perl6-internals-design is for a team of no more than 10 people. These > people should have experience either with perl5 or with a similar > system. Mail to this list goes to perl6-internals-design and to > perl6-internals. One minor suggestion: If we do this, please also make or something like that, which is a list that simply redistributes mail from to its subscribers. In other words, only post would go there, but no subscriber could post. Rationale: Some people who aren't on the design team may want to follow the progress, but aren't particularly interested in the public list. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
