On Sat, 09 Nov 2002 13:21:06 Michael Lazzaro wrote: >Markus Laire wrote: >> On 9 Nov 2002 at 18:56, Andrew Wilson wrote: >> > I will be happy to be proved wrong about this but I have a feeling that >> > too much attention to detail will get us bogged down. >> >> I also think that we shouldn't try to provide too exact and final >> documentation at once. Just define each area "with enough detail" >> (whatever that means) and then move on. Until whole language-design >> is somewhat complete, there will be things which requires earlier >> decisions to be changed. > >My feelings are mixed. I don't think we need to fill _every_ hole in >exact sequence. But I'd like to be as precise and ordered as possible, >because I think that's where this group can contribute to the effort: by >filling in the details, or encouraging the designers to do it. If we >keep the basic needs in mind, we should be fine: > >-- We should be making sure nothing nasty gets missed. The nightmare >scenario is if very basic assumptions need to be revisited a year or two >after the fact, because of some "oops" in the details that has a >cascading effect through the entire design. > >-- In order to be useful to the internals team, we have to specify >primitive, narrow behaviors wherever possible, as soon as possible. If >the details specify something they weren't originally counting on, it >can blow large sections of their code away in trying to meet the new >expectations. I think we've all been there before. 8-( > >Don't know -- we'll just have to play it by ear. The primary thing I >*don't* want is for this to be a clone of perl6-language, where umpteen >people are asking umpteen different, unrelated questions, and there's no >particular motivation to see any of the details through.
I've become convinced that one of the most important things we can do is produce test cases - when showing something to a programmer, their gonna want working code. In P6L we bandy about questionable code all the time. What should be done is that once this questionable code has a defined behavior it should be turned into a test and put whereever it needs to go. If the test is well documented, we have clear documentation AND an automatic wy of testing our implementation - ie run the tests. The next big advantage of tests is that we can catch contradictions or snags with decisions made weeks or months apart, in an automatic way. Writing tests for all these behaviors has the side effect of making us experienced Perl 6 programmers before the language is finished. Definitely an edge in the job market :-) -Erik That would >make it impossible to make useful progress on documenting anything. So >I think the one place we _do_ need to be fairly hard-nosed is in >focusing the discussion on only a few topics at a time, and politely >directing other questions to perl6-language if we're not prepared to >deal with them yet. > >MikeL > ____________________________________________________________ Get 25MB of email storage with Lycos Mail Plus! Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
