> 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)


Reply via email to