Re: Not revisiting the RFC process (was: RFC 362...)
On Thu, Feb 22, 2001 at 05:12:05PM -0500, Adam Turoff wrote: On Thu, Feb 22, 2001 at 01:41:22PM -0800, Edward Peschko wrote: On Thu, Feb 22, 2001 at 04:04:31PM -0500, Adam Turoff wrote: 1) The RFC was a free-for-all brainstorming process. Intentionally. right, and your point is that brainstorming should cease(?) Yes. Everyone (else) seems to agree that Larry has a tough enough job to do right now without increasing his workload by extending the RFC process. hey, look, I'm not saying that larry should be inundated with new RFCs. I agree that the RFCs that he has should form a 'cutoff'. And that any new design documents should form the basis of a secondary cutoff. All I'm asking for is either: a) a new mechanism for being able to express RFC-like things b) an extension of the existing mechanism. If you want to take the things that I'm writing, archive them, and then display them at some future date in RFC round 2, that's fine with me. I agree that they shouldn't be part of larry's 'task' ( although if he wants to make them part, that's an option up to him. Personally, if I was doing what he's doing, I'd want as much help as I could get.) yeah, and there are not nearly enough of these 'features', 'comments', 'what have you' available. There is a *lot more to say* in this type of forum. That's one opinion. Ok, that *is* one opinion, but you've basically limited my ability to prove this opinion by saying 'whoa.. we are not accepting any more RFCs.'. How am I supposed to prove anything if we leave it to be all academic? I say that RFCs could get better and could be a very productive part in perl design for the long haul. You say they cannot. How can we settle this? Well, give me a chance to design/implement my RFC editor. Give me my chance to post RFCs. See if it works. If it doesn't, then it doesn't. If it does, it does. Its the same as default warnings - either they will work or they will not. People will either accept them or not. But IMO its not very productive to say you *cannot* do something period. That doesn't sound like a compelling case to unlimit the process. Perl6 isn't a never-ending RFC gathering exercise. It's a community rewrite of Perl. I never said that RFCs would go on alone, devoid of any other process. I very much want them to go along in tandem with things like PDD. I want one to complement the other. That statement significantly misrepresents and underestimates the nature of Perl. Perl4 and Perl5 were not fixed in stone, and they both went into interesting unforseen directions (including tkperl/oraperl and Inline/Perligata, respectively). yeah, and all I'm asking is that there is freedom to document, to order that process. I want to have a way of making conversation 'show-stoppers', to document threads and to stop the banging of heads on the wall that was perl5-porters. And that's why I want it ongoing. And that's why I'm willing to put the effort into making it user-friendly enough to *make* it ongoing. Hell, we could call the RFC bin the 'perl suggestion box' - it could be a way for ordinary users to give the ideas they have to the perl community, to get involved. And maybe as prelude to contributing to CPAN or the core, who knows. Perl6 will not be set in stone, either, but the baseline needs to be complete enough to accomodate current needs and desires, and flexible enough to invent the rest. So you should have no problems with writing down these things in an order to give people an understanding of what's going on? Or giving people the creative outlet for suggesting their ideas? Look, I'm sick of meta-arguing. If you want to get ahold of me privately (by phone if necessary) I'm sure we can hash this out. I'll refrain from writing anything 'official looking' until we get this issue settled, but I'd appreciate the courtesy to get it settled in the first place. Ed
Re: Not revisiting the RFC process (was: RFC 362...)
On Thu, Feb 22, 2001 at 03:42:52AM -0500, Adam Turoff wrote: On Mon, Feb 19, 2001 at 07:20:33PM -0800, Edward Peschko wrote: As much as I'd like to respond to some of these points, I'll refrain from it now, I'll let my RFCs speak for themselves. Ed, The RFC process that we started this summer is formally and intentionally closed. Your post, regardless of it's formatting, naming or intent, will not be accepted into the RFC archive. Um... You haven't been following the discussion, have you? Did you read the RFC? As I stated in the original post, there is no reason *not* to keep the process open. The RFC's would be a very good tool to sift discussions, let ideas flow, and not to revisit discussions in the future. And as I stated in my original message, I was perfectly happy for my RFC to not make it into current 'cutoff'. Dan Sugalski replied that the RFC process *was* going to be ongoing, so I was willing to have it hit the next 'cutoff'. Hell, I was going to make an RFC searcher, commentor, and so forth that could be re-used for PPD. I have no interest in making such an engine if PPD only exists, because I think that PPD by itself is clearly insufficient to handle the needs of the perl community. So I ask you - *why* make an artificial deadline? What's the point? Do you really think that RFC's as they stand equal all the large issues that are going to be faced with perl6? I read all of the RFC's and there are thirty large gaps that I count and that should be filled. I'm sorry, but this pisses me off. You've got to realize that for a lot of us, our time is intermittent and our commitment can only be sporadic. I, for one, was busy in transitioning to another state when the whole perl6 design thing happened last year. So hell - I plan on giving my contribution now. What's better - that, or twiddling our thumbs? Ed
Re: Not revisiting the RFC process (was: RFC 362...)
On Thu, Feb 22, 2001 at 08:31:23PM +, Simon Cozens wrote: On Thu, Feb 22, 2001 at 12:00:45PM -0800, Edward Peschko wrote: So I ask you - *why* make an artificial deadline? What's the point? Do you currently believe we're all sufficiently focused on getting the job done? I ask merely for information. Well, no, what I'm saying is that with the lack of a formal process, people are spinning their wheels. I think the intent is there, the focus is there, but the process has sort of grinded to a halt. The current RFCs need work. There are things that could be built (like the RFC searcher) There are new RFCs that could be written. Its totally counter-productive to wait and its totally-totally-counterproductive to try to enforce some artificial deadline 4 months after it passed... -- You are in a maze of little twisting passages, all alike. wow. for a second I thought that that was part of the message itself. Although I read it as 'you *are* a maze of little twisting passages' which confused me quite a bit. I wasn't sure if it was a complement or an insult. ;-) Ed
Re: Not revisiting the RFC process (was: RFC 362...)
On Thu, Feb 22, 2001 at 04:04:31PM -0500, Adam Turoff wrote: On Thu, Feb 22, 2001 at 12:00:45PM -0800, Edward Peschko wrote: As I stated in the original post, there is no reason *not* to keep the process open. In an attempt to keep my previous message concise, I seem to have neglected a few key points: 1) The RFC was a free-for-all brainstorming process. Intentionally. right, and your point is that brainstorming should cease(?) 2) RFCs were not intended to be the basis for designing the language or describing/creating the implementation. They were intended to collect comments on the aspects of Perl5 that should/could be fixed in Perl6, or cool new features that cannot be reasonably added into Perl5 but could be integrated into Perl6. yeah, and there are not nearly enough of these 'features', 'comments', 'what have you' available. There is a *lot more to say* in this type of forum. 3) The RFC process was designed to be a limited call for ideas for Larry to consider in a language design. The deadline was integral to the process, and decided before RFC collection began. right.. and like I said, I don't understand the 'limited' part. Like I said, there are a bunch of ideas that are not formally written down that it would be criminal to ignore. What better way of keeping track of them than an RFC? The RFC's would be a very good tool to sift discussions, let ? ideas flow, and not to revisit discussions in the future. 4) The RFCs have demonstrated that they are a very poor tool for starting and continuing a productive, forward moving discussion. Many of these issues are addressed in PDD 0 and Dan's thoughts on the PDD process. sorry, but this is a bunch of BS. They are poor from the point of *implementation* but they are far from poor from the point of the brainstorming. There is an *ongoing need* for this type of brainstorming, something that mailing lists by themselves cannot tackle, and something that the PDD's should *not* tackle. PDD's can be kept free of cruft if there is this separate step of 'brainstorming'. And RFC's are a very good starting point for PDD's. [...] Dan Sugalski replied that the RFC process *was* going to be ongoing, so I was willing to have it hit the next 'cutoff'. The formal (more-formal-than-p5p) document gathering process will be ongoing. That is one reason (of many) why the PDD series is Right, but do you really want every off-the-cuff discussion/idea to make it into PDD? Or do you want to have a selection/discussion process to decide which RFCs should make it into PDD. emphatically not a series of RFCs. We made mistakes with the RFC process and don't want to repeat them. But you are making a fundamental mistake if PDDs are shoehorned to fit the entire design process. RFC's should be messy, outspoken, and they should cover the entire spectrum of what perl is about. They should then be drilled *down* into PDDs. There's nothing stopping you, but the RFC archive is closed and will likely not be reopened (save for some minor details in the queue). It's primary value is in cataloging a series of ideas of what Perl could or should become. Exactly... and your point is that 'the number of things that perl6 which Perl could or should become' is now fixed in stone? So I ask you - *why* make an artificial deadline? What's the point? The deadline was not artificial. It was by design. yes. It was 'artificial' by design. It was artificially imposed. And it was wrongfully imposed. I can see the value of having an initial 'cutoff', and then having cutoffs going on forward, but to say *whoa nelly* the only forum now for off the cuff discussion is via thread is just wrong. We've tried that before; it was called perl5-porters. It led to the same idea over and over again because there was no formal way of cataloging good ideas and bad ideas. And before you say 'this is PDD', think of exactly how badly this would dilute the PDDs. PDDs would contain everything from undigested ideas to meticulously crafted ones. It would be a mess. Or in other words, tell you what - I'll write up my 30 ideas, and I will call them PDDs. No, and there's nothing wrong with that. Of course there is. RFCs might be 60% crap (or even 70-80%) but that leaves some very good implementable ideas. There is value in putting down and cataloging brainstorms. If you want to contribute, patch bleadperl, or make a contribution on what we're doing today. Ok, you are on. I'll write up my 30 ideas, and you'll accept them as PDDs. Ok? Ed
Re: Not revisiting the RFC process (was: RFC 362...)
On Thu, Feb 22, 2001 at 09:11:03PM +, Simon Cozens wrote: On Thu, Feb 22, 2001 at 12:39:25PM -0800, Edward Peschko wrote: The current RFCs need work. Be assured that they're getting lots of top-quality work. There are new RFCs that could be written. Its totally counter-productive to ... ship a specification to a designer, and then keep adding more and more new requests to change it. Don't you just *hate* that when people change the specifications while you're half way through writing a project? Don't do it to Perl's design. No I actually don't hate it. Because if I can fit in new features based on my original design, it gives me validation that I'm going down the right path. And I don't think that the first round of perl6 will contain all of its ultimate features - you work outward from a set of central principles. If you see a cool feature that somehow modifies your original design, you make the choice whether or not its worth the effort to fit that feature in. Here for example was something that was totally missed in the RFCs and *should* be spec'd out (I believe): perl should have a mechanism for loading libraries like a '.so' ie, you should be able to install a library like: Data/Dumper.pm.1.2.4 and say 'use Data::Dumper qw(1.2.4);' or 'use Data::Dumper qw(last);' And of course it should be tied into CPAN. Now the syntax is suspect, but it allows for large applications/APIs to specify which version of a library it needs. And it guards them against breakages if somebody decides to change the API that *you* are depending on. Now of course this is debatable, but I think it should be written down, and argued about. If its found to be a good RFC, it makes it as the starting point of a PDD. If it isn't, its labeled 'retracted' and its a guidepost to not starting the same damn conversation over and over again. Like I said, you could shoehorn this into PDD, but why? Ed
Re: Not revisiting the RFC process (was: RFC 362...)
No. Please don't, and save me the trouble of having to reject them. I'd rather not do that. Exactly my point. There is no recourse that is given to me, or a lot of other people for that matter. And like I said, my time is variable, and the time that I have to devote to design/implementation of perl is limited may or may not follow Larry's schedule. So I'll leave it up to you - what venue/recourse/means do I have for submitting new ideas for review? And please don't say via mailing list because submitting new ideas via mailing list is absolutely pointless. I'd rather write them semi-formally, catalog them, get input on them while they are still hot, and have them archived somewhere. seems the most productive thing for me to do... Ed
Re: Not revisiting the RFC process (was: RFC 362...)
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
Re: State of PDD 0
On Tue, Feb 20, 2001 at 02:15:56PM -0700, Nathan Torkington wrote: Bryan C. Warnock writes: Ask, all, are we reusing perl6-rfc as the submittal address, or will there be a new one (perl-pdd)? I'm in favour of renaming to reflect the new use of the list. Dan? How about two lists? I still think that there should be a two-tiered process. I think its a mistake to have a 'one size fits all' process. See my other post on this. Ed
Re: RFC 362 - revisiting the RFC process (was Warnings, strict, and CPAN)
On Mon, Feb 19, 2001 at 11:38:03PM -0500, Dan Sugalski wrote: At 07:20 PM 2/19/2001 -0800, Edward Peschko wrote: RFC 362 --- =head1 TITLE The RFC project should be ongoing and more adaptive. It's my understanding that this is, in fact, the plan. The only reason things have paused (and it is a pause, not a stop) is that we're waiting for Larry to take what's been done so far and build something resembling a coherent base we can implement. After that's done then we'll have something to work from, which is a good thing. Ok, fair enough. I think that perl should have a two-tiered process though, and it should be ongoing and two tiered. Bryan Warnock mentioned PDD as being 'comprehensive', but I think that is a mistake. There should be a more formal process for distilling conversations, lest we repeat length(@array), '??', etc, ad-nauseum. PDD should be stuff that was decided as 'golden' and then implemented. If we don't ever stop, ponder, and implement, the RFCs will be just another go-round of intellectual masturbation. (and we *really* don't need to go there...) Yeah, it means the process will be bursty, but that's just the nature of the beast. Fair enough too, except that my time *too* is bursty, and that the time I can give may or may not correspond with community time. I'll write them down, and post them to perl6-rfc (or perl6-meta). And if they miss the 'original' pass, that's fine with me. Ed
Re: State of PDD 0
On Tue, Feb 20, 2001 at 06:17:18PM -0500, Dan Sugalski wrote: At 04:01 PM 2/20/2001 -0700, Nathan Torkington wrote: Dan Sugalski writes: I've been thinking since I sent my last mail on this that we might actually want to leave the two (PDD RFC) separate. Keep on with the RFCs for 'external' things, and PDD for the actual internals implementation of things. Ultimately, I think we're going to need at least three different types of documentation: * internals design documents (PDDs) * language design documents (PLDs?) * change requests, once we've got something to change (PCRs) That works. I rather like it, and I expect once we get a working perl 6, we probably won't need to freeze things either--worst case we mark a proposed document irrelevant or something of the sort. Well, how about calling 'Language Design Documents' "RFC's" ? After all, the term RFC is a lot more generic; it can encorporate comments on *anything* perl related. Ed
RFC 362 - revisiting the RFC process (was Warnings, strict, and CPAN)
much deleted As much as I'd like to respond to some of these points, I'll refrain from it now, I'll let my RFCs speak for themselves. Speaking of which... apologies in advance for cross-posting this, but I wanted to get the largest audience possible... I won't do it again. At least not in the forseeable future.. ;-) Ed RFC 362 --- =head1 TITLE The RFC project should be ongoing and more adaptive. =head1 VERSION Maintainer: Edward S. Peschko [EMAIL PROTECTED] Date: 19 Feb 2001 Mailing List: [EMAIL PROTECTED] Number: 362 Version: 1 Status: Developing =head1 ABSTRACT The RFC process should not have had an artificial deadline; it should be an adaptive process that should last the entire development cycle of perl6 and perhaps after. =head1 DESCRIPTION I did a brief audit of all of the RFC's, and wheras they were a good start, they are hardly the end-all-be-all for perl6. There were gaps in functionality, a variance in the quality of the RFC's, and not enough emphasis on implementation. In addition, the discussion on the list did not seem to wend its way back into the RFC's themselves. Mark Dominus went so far to post a critique of the entire process: http://www.perl.com/pub/2000/11/perl6rfc.html and to conclude that the whole "RFC's process" was pretty much a waste of time for the quality of RFC's produced. Well, that's one view - but it neglects to recognize: =item 1. that without an RFC process in place, old ideas and discussions will rehash themselves on mailing lists ad nauseum. =item 2. that RFC's are a good starting point for people unfamiliar with with discussions/issues on the mailing list. =item 3. that RFC's are a good starting point for documentation. =item 4. that this is perl's first attempt at organizing ideas like this. Hence, we are newbies at this and are bound to make mistakes the first time round. However, there is one aspect in which I agree with him. That, as it stands, the RFCs are incomplete, lack encorporation of discussion, and seem to be 'out of touch' with the rest of the RFCs (to some extent). But that just points out to me the validity of point #4 above; we are new at this. We would get better as we go along. In addition, right now (as of February), I get the sense on the mailing lists that people don't really know what to do next. 'Wait for Larry' seems to be the order of the day, and we have been waiting for a while. Instead, I think that the doors to the RFCs should be re-opened, and that they should be bulletproofed. The next four RFCs suggest methods on how to improve the RFC process and the quality of RFCs: RFC 363 - Anyone posting a new RFC should have read all of the existing RFCs first. RFC 364 - There should be a web interface for people to interactively comment on RFCs. RFC 365 - There should be a rating system for RFCs. RFC 366 - There should be a culling system for RFCs, a way to distinguish quickly between withdrawn RFCs and RFCs in process. (ps -- no, I haven't written these yet. But if this RFC is acted upon, I reserve those numbers in advance. ;-)) =head1 IMPLEMENTATION Not really an implementation thing, more of a philosophy and process. =head1 REFERENCES http://www.perl.com/pub/2000/11/perl6rfc.html http://www.perl.com/pub/2000/11/jarkko.html
Art of Unix Programming on perl
Eric Raymond's book-in-development ``The Art of Unix Programming'' says this about the future of Perl: Perl usage has grown respectably, but the language itself has been stagnant for two years or more. Bah. Looks like my Perl5-Porters summaries have been completely in vain. :) yeah, he's full of BS here.. Perl's internals are notoriously grubby; it's been understood for years that the language's implementation needs to be rewritten from scratch, but an attempt in 1999 failed and another seems presently stalled. If that other is Perl 6, I don't think we're stalled, are we? Language design is waiting on Larry to produce the spec, and internals design is going on quietly but steadily. We're in the design stage. That'll probably last a while because scripting languages and interpreters aren't easy things to design, and are even harder to get right. yeah well, sometimes I think that things *are* stalled. For example, I'm trying to both update my last book (and perhaps write a new one) and its kind of difficult to start let alone convince an editor to put the effort in if you don't even have a spec to work from. And lacking a spec, a status would be nice. Last time I heard, larry was going to be working on 'chunks of RFCs at a time' and posting the results of those for digestion. What happened to that? The last thing posted was Dec 20th on the subject. Is there a place for statuses that I'm unaware of? Ed
