Edward Peschko
Thu, 22 Feb 2001 14:47:33 -0800
> Well, there's always the implementation. Granted, it's the messy, nasty > side of things, but it is the area we're presently working in. Knowledge of > C is *not* required either--just because that's what the current pieces up > for discussion are written or going to be written in doesn't mean we can't > open things up more. A good chunk of perl 6's internals will be extendable > via perl. funny thing though, I *offered* a piece of implementation, with something that I really thought could help perl - namely that RFC searcher/parser/etc. I even got to the point of asking for resources so that the beta that I develop here can be put on 'official machines'. Great idea, got even some help from people on this list, and then *bam* my momentum got sapped out of me. My momentum for developing things is driven by making something that I find is useful, for something that I feel fills in a gap. And the ongoing RFC process is definitely something that fills in a gap. What you are basically saying is that between: having someone do something productive, and having someone do nothing, we'd better do nothing because it doesn't fit the schedule. I mean after I got done with the searcher, and had my say through my potential RFCs, I might join you on the PDDs. But its very difficult for me to do otherwise; its just really not the way my brain works. I have something to say, I say it, put it out there and its gone. Its very frustrating to keep it bottled up inside. > I'm not entirely sure about that. Writing proposal documents that build on > a foundation that doesn't actually exist may not be the most productive use > of your time. It would really suck to spend days on something that turns > out to be unimplementable or meaningless because the design decisions it > was based on were faulty. But they are implementable because they are mostly pragmatic, down to earth things that I've had to re-invent every single time I go to a new environment. They are things that are more at the versioning/qa/API end of the spectrum than the internals (although there are a couple of internals ones) Ed