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 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. -- You are in a maze of little twisting passages, all alike.
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 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. 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. 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. 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. [...] 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 emphatically not a series of RFCs. We made mistakes with the RFC process and don't want to repeat them. 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. 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. So I ask you - *why* make an artificial deadline? What's the point? The deadline was not artificial. It was by design. Do you really think that RFC's as they stand equal all the large issues that are going to be faced with perl6? No, and there's nothing wrong with that. 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. All the more reason to focus on building the future, not polishing the past. 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? If you want to contribute, patch bleadperl, or make a contribution on what we're doing today. Z.
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...)
At 01:41 PM 2/22/2001 -0800, Edward Peschko wrote: On Thu, Feb 22, 2001 at 04:04:31PM -0500, Adam Turoff wrote: 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. PDDs are for internals pretty much exclusively. If it doesn't involve the implementation or design of the low-level guts of perl, it doesn't belong in a PDD. Which isn't to say it has to all be C and bit-level things--the parser wedges that can be written in perl would be specified in perl, of course. Some random stranger should be able to take all the 'standard' PDDs (however they're marked) and build a perl interpreter/compiler. That's the plan, at least. 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? Well, I think Nat's planning on switching over a different name and restarting the numbering scheme, so that's something. The bigger thing is that the new proposals will be based on the perl we produce from Larry's design. They'll be (mostly) incremental changes, rather than wildly radical ones, since they'll start from a fixed base. I hope. :) 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. Yes it was, and no it wasn't. At some point you need to retreat, take the brainstorming, and produce a spec then an implementation. We've left the brainstorming stage and are waiting for Larry to get the spec together. (More or less) Once we've got an implementation, then it'll be time to start brainstorming in earnest again, though I fully expect there to be a batch of RFCs and PDDs for the things that didn't make the first cut for whatever reason. (Time, personnel, my sanity... :) That's OK too. 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. No, it's appropriate. Whether the delay between the cutoff and the spec is appropriate is what's really the issue. I'm not going to go there, though. 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. Nah, p5p was something else entirely. I do think things'll go better for perl 6. 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. Well, the RFC library (the real one the IETF has) is a lot like that, but the internet hasn't collapsed yet, Infinite Monkeys protocol or not. 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? No. Please don't, and save me the trouble of having to reject them. I'd rather not do that. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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...)
On Thursday 22 February 2001 17:12, Dan Sugalski wrote:
PDDs are for internals pretty much exclusively. If it doesn't involve the
implementation or design of the low-level guts of perl, it doesn't belong
in a PDD. Which isn't to say it has to all be C and bit-level things--the
parser wedges that can be written in perl would be specified in perl, of
course.
Some random stranger should be able to take all the 'standard' PDDs
(however they're marked) and build a perl interpreter/compiler. That's
the
plan, at least.
I still think it's possible (and desirable) to have PDD that handles
language issues. We should certainly scope out beforehand exactly what the
semantics of construct foo should be, even if it's just a BNC description
and a quick explanation of how it behaves in void, scalar, and list context.
A lot of times this doesn't necessarily condense to the necessary bit
twiddles. Much of what Larry delivers, I imagine, will be of this scope.
A PDD like this a) provides an upfront idea of what the internals guys are
supposed to produce. ("I didn't know that foo could take a block") and b)
provide a jumpstart to the perl6 deliverable documentation.
I think this is what Nathan was labelling a PLD, but I said in my other
thread, I think a single vehicle can (and should) handle them both.
Then again, you may be considering that as internals anyway.
Many of the meta- items that will be Informational probably won't be
internally-oriented, either, but I don't think that should stop us from
documenting them. IMO, the decision is how deliberate the segregation of
the different areas. Internals, language, and meta PDDs, while curently in
a single PDD bucket, are sub-classed as such. This allows both a
comprehensive list (of PDD 0 - PDD X) as well as secondary collation by
groups. We could just as easily create PDDs, PLDs, PMDs, as well, but
it's harder to handle a comprehensive list that way. You either have
independent numbering schemes, which could lead to confusion, or a single
numbering scheme, which begs the question of why seperate them in the first
place.
--
Bryan C. Warnock
[EMAIL PROTECTED]
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: Not revisiting the RFC process (was: RFC 362...)
Simon Cozens [EMAIL PROTECTED] 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. Estimating before specifications are recieved is insane. What was the question? p
Re: Not revisiting the RFC process (was: RFC 362...)
On Thu, Feb 22, 2001 at 05:17:10PM +, David Grove wrote: Do you currently believe we're all sufficiently focused on getting the job done? What was the question? Do you currently believe we're all sufficiently focused on getting the job done? -- Do you associate ST JOHN'S with addiction to ASIA FILE? - Henry Braun is Oxford Zippy
