On Sun, Feb 11, 2001 at 11:05:22PM +0000, Simon Cozens wrote:
> On Sun, Feb 11, 2001 at 03:00:05PM -0800, Edward Peschko wrote:
> > Again, We'll have continued discussion, but what the perl development
> > project needs right now is a swift kick of *direction* from larry. And I'm
> > pretty sure that he knows this.
> 
> I thought part of the idea was that we become self-motivating, and
> "bus-proof".

yeah, of course, but there's a point at which you need someone to 'lead'. And
Larry's put himself in that position by saying that he would look at (and rule
on) all of the RFC's.

And PR is a function of people listening to people that they know (and 
presumably respect). As much as we make summaries, et al, it is Larry that 
they primarily know. And Larry saying something will get it put on slashdot.

As far as the bus-proof thing is concerned - I think that perl5/perl6 porters
is *already* pretty bus-proof in every aspect except one - that Larry should 
name a 'successor' to the language, someone who holds the trademark. 
(in the case that he gets hit by a metaphorical bus). That would get reported
too.

> > ps - and as far as I'm concerned, there are two great decision points that 
> > could be made early on && made public for perl's design: 
> > 
> >     (1) that perl is a 'micro-architecture' where the perl runtime 
> 
> This is RFC 315.
>  
> >         (2) that the perl parser is pluggable
> 
> This is RFCs 314 and 329.
> 
> I wonder what foresighted individual came up with them. :)

Great - then they are the perfect three RFC's to make an announcement with on
the start of the 'approved' design list.  They are like meta-genes in DNA - 
genes which influence the behaviour of multiple 'sub' genes. 

Larry makes a detailed announcement out of them, slashdot reports it, and 
*boom* you've got a URL impressed into the community at large where they can 
go for *approved* RFCs. 

And to keep people interest from flagging, make submssions to this *approved* 
RFC list as they come in, and make it fairly often (one URL at a time). Make a 
running commentary about why a feature made it, and why a feature didn't, and
if a feature didn't make it, tell why and how one can work around it if it
didn't. Link RFC's together and make it interesting to read. Make a story out of
it, make people want to upgrade to it. etc. etc. etc. 

I keep looking on use.perl.org, and keep hoping that it becomes something like
this, but it hasn't - not yet at least.

Ed

Reply via email to