> 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
