Nice perl 6 article
http://www.unixreview.com/documents/s=1780/urm0111h/0111h.htm Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Second public parrot demo
Hey, folks. I'm going to be giving the world's second public parrot demo at this month's Boston.pm meeting. It's Tuesday the 11th at 7 PM, give or take, at the Boston.com building in (who'd've thought) Boston. :) If you're interested in coming, make sure to RSVP to Ronald Kimball, [EMAIL PROTECTED]. (Don't RSVP me! I'll lose the note!) Directions at http://boston.pm.org/where.html, or http://maps.yahoo.com/py/maps.py?Pyt=Tmapaddr=320+Congress+Stcity=Bostonstate=MAzip=02210-1238country=usslt=42.351300sln=-71.049600mag=9cs=9name=Boston.com (barring word-wrap) And yes, we'll have details of how to get the current parrot source yourself next monday, so you can play along at home! :) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: You will not have to rewrite your Perl 5 programs!
At 10:06 PM 5/10/2001 +0100, Michael G Schwern wrote: I'd just like to make this abundantly clear, since there seems to be some confusion (and hopefully I'm not the one confused). *** You will NOT have to rewrite your Perl 5 programs *** Perl 6 *will* provide a backwards compatible Perl 5 parser. The details are not nailed down, but this definately will happen. Damn straight. One way or another, perl 6 will eat perl 5 code close to painlessly. (Typeglobs, perhaps, aside) 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...)
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: State of PDD 0
At 04:43 PM 2/20/2001 -0600, Jarkko Hietaniemi wrote: On Tue, Feb 20, 2001 at 02:43:14PM -0800, Peter Scott wrote: At 05:30 PM 2/20/01 -0500, Dan Sugalski wrote: At 02:15 PM 2/20/2001 -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? 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,... I suggest that we clearly delineate the RFCs which were pre-deadline from the ones that are post-deadline. The advantage to having the original deadline was that it motivated many of us to get off our butts and fish or cut bait. If we're going to continue this process now, I move that: New RFCs be numbered starting from 1000 (easiest way to denote the difference); Old RFCs are frozen, and that means frozen. I have no idea how far Larry's got on digesting them and I really don't want to try and interfere with something that could be making its way down his small intestine. People should be free to write new RFCs that contradict older ones, or head off on some tangent, but please let's not keep refining the old ones, enough is enough. Strongly agreed. That works for me--we could increment the thousands number by one each time we open things up for a new RFC period. Once we have a working perl 6 of some sort we can kick in with RFC 1000, and once perl 6.1 is done we can go with 2000, and so on. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
A moment about software quality...
http://www.salon.com/tech/feature/2000/12/06/bad_computers/index.html And no, open source software is *not* immune. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Guidelines for internals proposals and documentation
At 07:35 AM 11/15/00 +, Mike Lacey wrote: - Original Message - From: "Dan Sugalski" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; "Nathan Torkington" [EMAIL PROTECTED] Sent: Tuesday, November 14, 2000 10:59 PM Subject: Guidelines for internals proposals and documentation Here are some guidelines for the design process for internals-level docs. (good stuff ommitted) 7) These are *not* brainstorming documents! These are solid, concrete proposals for either the design or implementation of perl 6. If you have a brainstorm but don't currently have the skillset (or requisite brain damage... :) to make a concrete proposal, get in touch with either the correct WG chair or Nat or me, and we'll do our best to hook you up with someone in a position to make your ideas concrete. Dan, Shouldn't there be another stage (that other people could contribute to) before you pass a wild-but-maybe-useful idea to someone? Yup. That's what the lists are for. If the split list format doesn't work (and it might) it'll be on perl6-internals, otherwise it'll be on the appropriate sub-list. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: The new api groups
At 03:34 AM 11/15/00 +, David Grove wrote: I'm on announce, I believe... I didn't get anything. (Internals seems like a poor place to make than announcement.) How do I check to see that ezmlm hasn't unsubscribed me from announce when my server was down last week for a couple of days? It's read-only, so I can't test-post to it, and I'm not up on ezmlm grammar. Just [EMAIL PROTECTED] with a help/help? It's always safe to resubscribe. You'll get an error message if you're on already. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Guidelines for internals proposals and documentation
At 12:38 PM 11/15/00 -0500, Adam Turoff wrote: On Wed, Nov 15, 2000 at 04:42:58PM +, Nicholas Clark wrote: On Wed, Nov 15, 2000 at 11:35:56AM -0500, Adam Turoff wrote: All PDDs (like RFCs) need to start with 'Status: Developing' by default. Since statuses like 'Standard', 'Rejected', etc. have Real Meaning (tm), there should be some review in place (by a WGC, principal, etc.). Statuses like 'Withdrawn' and 'Superceded' should be accepted from PDD authors/teams. They don't need to start with "Developing" if they start with status "Experimental" or "Proposed" The real issue is that there needs to be at least one default status that the author can assign. With RFCs, Developing referred to the RFC, and with PDDs, they refer to the underlying design/interface/implementation. I think I misread Dan's re-interpretation of 'Developing'. Probably. I don't think I was clear enough the first time around. This is a community process. I'm uncomfortable leaving such decisions to such a small number of people. How about nominating/electing a If PDDs start as "Proposed" without needing any approval does this remove the problem of a small group having a stranglehold? No, because Dan has proposed a 'core team' of sorts, where any one of the (at least) three team members cast a final vote (towards 'standard' or 'rejected'). Yup. Keep in mind that this isn't "Dan's Perl API" (or Nat's, or Larry's), but "Our Perl API". I'd be more comfortable if at least two people (from a group of 4) were involved in making any decision that carries weight, or if there were a process of rotating the WGC as necessary to avoid Pumpking Burnout (tm). This only holds while the primary design takes place--what happens when perl 6 hits maintenance/extended development is still up in the air. (read: That's *not* my problem... :) I want perl 6's internal API to have the same sort of artistic integrity that the language has. That's not, unfortunately, possible with everyone having equal say. I'd like it to be otherwise, but that's just not possible with people involved. The point is definitely *not* to do any sort of consolidation of power. Anyone reasonably sane, capable, and interested is welcome to chair any of the internals design lists and/or be responsible for shepherding a PDD to solidity. That's fine with me. (In fact I'd be thrilled if the design was handled by a host of folks that weren't me) My job is to play the Larry role for the backstage stuff. Luckily for me the task is reasonably partitionable, so I don't have nearly the burden of consolidating things that Larry does at the language level, and what I'm trying (perhaps clumsily) to do is farm out pieces to people while making sure we don't start with the sort of mess we have now with perl 5. Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Fwd: new lists. perl6-internals-api-*
At 12:10 PM 11/14/00 +, David Grove wrote: I think these questions have been answered already, but just in case they haven't it doesn't hurt to re-iterate. Sorry for the crosspost (the information was requested). This is where I got the information on the new api groups. I've subscribed to the groups but haven't seen any traffic on them yet. I don't see any reason to believe that this wouldn't be authentic, but if it is, then if I'm not missing some huge discussion somewhere, then somebody's got the cart before the horse... The groups generally are independent of Larry's work, and if it turns out that the RFCs they produce need changing when he's done, well, that's OK. They're started because I want to get *something* done, and they're in the area where we don't have to wait for Larry to at least get starte. You know anything about this Nat? Nat, this also brings up another issue I hadn't foreseen. If one person (Dan, Sarathy, or whoever, not picking on anybody) leads so many working groups, how can that work into the fairness system that we banged our heads together to eek out? Kudos to Dan for (trying to) take on so much, but the wisdom of this is questionable, even if he can handle all the work. I'm in as chair only because I didn't think quite enough to call for volunteers first. (I've got something mono-ish--go easy on me :) I'm all for changing the chairs, as well as the target date. In fact, an announcement to that effect will go out in a bit. The frustrating part is that I actually want to participate in the parser group. I think I have some to add. The problem is we don't have any language definition from Larry yet, so figuring out a parser seems wy premature. We don't even know what's desired in the core, since we're looking toward a minimal core. The parser group is for the parser *API*, not the parser itself. It's supposed to design the calls inside the parser for wedges written in perl or C and suchlike things, so when it's done we can start writing a skeleton parser piece. The calls won't change much, I think--what token boundaries are doesn't matter if we're only defining the format for the function that'll be calld when one's seen. That the language isn't fully defined doesn't mean we can't start parsing with perl 5 and go from there, but that's a separate issue for a separate group that's not started yet. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Guidelines for internals proposals and documentation
Here are some guidelines for the design process for internals-level docs. 1) The damn things will be called PDD, or Perl Design Documents. Calling them RFCs was getting confusing for those of us dealing with IETF RFCs, especially as we're edging in towards the active RFC range. 2) We start counting from 2. (RFCs 0 and 1 are reserved, in case anyone beats me to them) 3) The format of the previous RFCs will be followed. The implementation section is optional, though strongly encouraged where appropriate. The status field is mandatory--PDDs submitted without one get a status of "Informational". 4) The PDDs are real documentation. When one goes to status:Standard, it *will* describe reality. If, when reality materializes, it doesn't then it needs to be updated. Someone should, for example, be able to take the PDD on vtables and write their own perl datatype without needing to refer to the source. 5) The stauses for PDDs are: proposed: Someone's putting forth a concrete proposal developing: The PDD is in active development and considered a real part of perl 6. standard: The PDD's done. (Well, for now at least) superceded: The PDD's been replaced by another. informational: The PDD is merely informational, and not a standard experimental: The PDD describes an experimental thing, and isn't a standard. 6) Only a WG chair, pumpking, or one of the principals (i.e. Me, Nat, or Larry, or our replacements) can mark a PDD as developing, standard, or superceded. 7) These are *not* brainstorming documents! These are solid, concrete proposals for either the design or implementation of perl 6. If you have a brainstorm but don't currently have the skillset (or requisite brain damage... :) to make a concrete proposal, get in touch with either the correct WG chair or Nat or me, and we'll do our best to hook you up with someone in a position to make your ideas concrete. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Critique available
At 10:42 AM 11/3/00 +, Simon Cozens wrote: On Thu, Nov 02, 2000 at 10:14:25PM -0500, Dan Sugalski wrote: Not in the p5p sense, at least. Regardless of the levels of disapproval, generally the disapproval was voiced with at least some courtesy. p5p is rather less polite about things. I think that's what they call a "false memory". There's been one acrimonious thread in the past six months or so. Well, things have been rather more pleasant since Tom and Ilya stopped posting much, that's for sure. I suppose it is less of a shark tank than it used to be. (Now the only thing that eats people is the actual source...) Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Critique available
At 10:11 AM 11/2/00 -0500, Mark-Jason Dominus wrote: My critique of the Perl 6 RFC process and following discussion is now available at http://www.perl.com/pub/2000/11/perl6rfc.html The biggest issue I have with this (and had the first time around) is the complaint about the IMPLEMENTATION section. Bluntly, I would really rather there have been none included in the language RFCs and, for the ones that had them, I rather liked Damian's "this space intentionally left blank" ones. We have no infrastructure to build on. Whinging about a lack of implementation details seems rather inappropriate. Ideas are nice, but I expect most of the recommended implementations (if we got them) would've been tossed out or wildly modified anyway, and it just annoys folks to ignore things we've asked for. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Critique available
At 06:08 PM 11/2/00 +, Simon Cozens wrote: On Thu, Nov 02, 2000 at 11:44:50AM -0600, Jarkko Hietaniemi wrote: Firstly, now, for the first time in the Perl history, we opened up the floodgates, so the speak, and had at least some sort of (admittedly) weakly formalized protocol of submitting ideas for enhancement, instead of the shark tank known as perl5-porters. perl6-language was not a shark tank? Not in the p5p sense, at least. Regardless of the levels of disapproval, generally the disapproval was voiced with at least some courtesy. p5p is rather less polite about things. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: compile-time taint checking and the halting problem
At 09:44 AM 10/23/00 -0700, Larry Wall wrote: David L. Nicol writes: : Steve Fink wrote (and I edited slightly): : : groan I can't figure out why so many people misinterpret my RFC12 : as requiring a solution to the halting problem. : : a large class of incompletely expressed : suggestions appear to get grouped into : : "This requires solving the halting problem!" : : without providing further explanation. Well, in my case, I wasn't actually meaning it strictly. Sorry for the imprecision--it's hard to squeeze everything into a talk. To me the saying is just shorthand for "potentially sufficiently computationally expensive that I don't want to worry about it for the default case". In other words, I was lumping polynomial in with exponential, and RFC12 feels polynomial to me. And it's not that I'm against the availability of polynomial algorithms in the parser, or the use of polynomial algorithms in general--I just think the default compile-and-run parser should avoid them. I'm really hoping to make allowances for a variety of optional optimizations. We can save the nastier things (and with perl's active data, a lot of stuff could reasonably be classed as difficult--good optimization's going to need fairly complex flow analysis, I think) for explicit requests, possibly with different default optimization levels for parse-and-go perl and compile-to-bytecode perl. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: My reading list
At 12:49 AM 10/24/00 +0100, Simon Cozens wrote: On Mon, Oct 23, 2000 at 04:11:34PM -0600, Nathan Torkington wrote: I'd just like to stoke the latent paranoia. Latent? What, there's some that *hasn't* come out yet? Damn, I bet it's too late to be afraid... Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Transcription of Larry's talk
At 07:39 PM 10/18/00 +0100, Simon Cozens wrote: On Wed, Oct 18, 2000 at 02:37:16PM -0400, John Porter wrote: http://www.mail-archive.com/perl6-language@perl.org/msg00517.html No, and no, and no. Of course not. That'd make perl look like Intercal, which would be silly. Since it's going to be our implementation language, there wouldn't be much point in writing perl code, now would there? :-P Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: C Sharp?
At 10:30 PM 10/18/00 -0500, David Grove wrote: Isn't C# (C Sharp) a Microsoft-owned language that is (currently) available only on Win2k (though apparently targeted for crossplatform)? After Larry said he was thinking of making parts of Perl 6 in C#, Perl's not going to be written in C#. What it's probably going to do (or at least have the potential to do) is emit C# code the same way it'll be able to emit Java bytecode. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Reading list
At 09:06 AM 10/12/00 -0400, Clayton Scott wrote: Carlos Ramirez wrote: Here's a listing of 'recommended reading' gathered from this list (provided by Nat). I'm not sure if this will be a permanent place for this link, but for now you can get it here. If i left out a book or if you have a new suggestion you can contact me or post it here and I will add them as soon as i can. http://www.perldoc.com/readinglist.pl Introduction to Algorithms By: Cormen, Thomas H. / Leiserson, Charles E. / Et Al. / McGraw-Hill ISBN: 0070131430 Fatbrain says they cannot get this book but to see at ISBN 0262031418 It seems to be the same book but has a higher price and (Mit Electrical Engineering and Computer Science Series) appended to the title. That second ISBN is the one off the copy I got a month or so ago. Ran ~$80 US, IIRC. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Reading list
At 03:56 AM 10/11/00 -0700, Carlos Ramirez wrote: Here's a listing of 'recommended reading' gathered from this list (provided by Nat). I'm not sure if this will be a permanent place for this link, but for now you can get it here. If i left out a book or if you have a new suggestion you can contact me or post it here and I will add them as soon as i can. http://www.perldoc.com/readinglist.pl This is nicely done, and thanks. There are two things I was hoping to add to the list: short reasons as to *why* a particular book is on the p6 reading list (The ones on for distinct reasons, like Understanding Comics or Garbage Collection, I'd like differentiated from general CS texts), and categories of books so we can separate the project management from the theory from the general background texts, and suchlike. Doable? Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Continued RFC process
At 02:11 PM 10/10/00 -0500, David Grove wrote: However what I was responding to was the shutting out of anyone who doesn't agree with the politics of the perl elite, and wants to mouth off from time to time (me). You sort of have to read between the lines on this one, Peter, because this is an old argument. Nobody's actually saying what they mean, and I think we prefer it that way. We don't prefer it that way, honestly. This dancing around the issue is damned annoying. Let's be blunt here. Your two big beefs seem to be that WinXX gets shorted in the development process, and that ActiveState is doing Evil Things. (That ActiveState has been responsible for 90% of the WinXX code in perl seems to not have made a difference, but we shan't go there right now) I don't much care about the latter problem--Larry feels he's resolved it and I'm fine with that. This is, as far as I'm concerned, his baby. As for the former Y'know what? That's probably not going to change. Perl lives and grows based entirely on contributions of source from the world. I don't have a Windows development system, I'm not at all familiar with developing on Windows, and I'm not *going* to develop on Windows. Period. You want Windows support? Great. Write the code and send it in. Don't like the install system? Go build one you do. I, for one, won't refuse code from anyone for personal reasons--if the code's solid (or there's no alternative) I'll take it no matter how much I might dislike someone. (Though it never helps to come across as a paranoid nutcase) I'll reject it on technical grounds, of course, but that's a separate matter. The problem with this is the assumption. There is _no_ assumption possible that the developers will read a free list, or care what it says. You're being too specific. There is no assumption possible that perl developers will do *anything*. Ever. This is a volunteer community. Any other assumption you might make is unfounded. There is no central authority. There is no guaranteed management control. There is no *nothing*. Perl is an open source project whose development is currently run by a group of interested parties. Don't like the way it's run? Fork the source and go for it. Dan, I don't know you. I've never had any problem with you or your leadership. That's fine. I fully expect that someone (and this is a generic someone here--I have no names in mind) will by the time this is all done. I'm not at all thrilled at the prospect, but it's one of the first things I came to terms with after volunteering. I don't believe that you'll head us into a mess, because I've no reason to believe it. You are also not technopolitically inclined in the same direction as your predecessor. I should point out two things: 1) Sarathy isn't technopolitically inclined in the way you think 2) My technopolitical leanings are likely not to your (or some other people's) tastes I have no arguments with you. However, the possibility still exists, and always will, unless some kind of check/balance system is in place. What you want isn't currently possible. Period. The only way to make it even remotely possible is to entrust perl development to some sort of entity akin to the Apache Software Foundation, and if we do that we will undoubtedly piss of yet another group of people. (And you'll likely be in that group too) Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continued RFC process
At 10:48 PM 10/10/00 +0100, Simon Cozens wrote: On Tue, Oct 10, 2000 at 05:40:04PM -0400, Dan Sugalski wrote: You're being too specific. There is no assumption possible that perl developers will do *anything*. Ever. This is a volunteer community. Any other assumption you might make is unfounded. David also seems to miss the irony that the people who *can* be expected to work on Perl because they being paid to do so are probably employed by... I know, I know! Compaq, right? :) Anyway, this is generating light. Could someone start generating heat, please? Sure. This does bring up one important point, though it's getting lost in everyone jumping on Dave for being a paranoid loony. Under what circumstances, and with what procedures, do we 'officially' remove folks from their positions? I know that I, for one, will step down if either Nat or Larry asks, but what happens if for some reason I turn into a raving nutter and won't go? Or if someone just disappears and we need a new person in the position? "General consensus" is best, but that can't be guaranteed. "Consensus of the ruling council" is more attainable, but there's that whole "ruling council" thing to contend with. "What Larry says" is best, but what happens if he doesn't, or gets hit by a bus at some point? It's not a pleasant thing to deal with, and hopefully not ever needed, but it's better to deal with now when we don't have to than later when we do... Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Continued RFC process
At 05:59 PM 10/10/00 -0500, David Grove wrote: On Tuesday, October 10, 2000 3:27 PM, Simon Cozens [SMTP:[EMAIL PROTECTED]] wrote: Consider: "Public Opinion": Hey, we need Perl 6 stable in three weeks. Coders: But, uhm, we haven't started coding yet. Consider: Microsoft: We need Perl by April 15th Head Cheese: Ok, sure P5P: HuH??? "Public Opinion": HuH??? [Result: Perl 5.6 chaos] No, M$ didn't have much to do with it. You can yell at Larry and Camel deadlines if you like, but that's wrong too. 5.6 was released because it was mostly done, more stable than 5.005 for the bits it had in common, and because of general apathy in the developer realm for the bits that were unfinished. Like, for example, Unicode. No, offense, Dan. This isn't targeting you. I think you're starting to realize this now. At first, I think you thought I was. No, I never thought you were. Or, more specifically, I never really gave it much thought and didn't care if you were or not. You mistook courtesy, lack of time, and a desire to not appear domineering for offense. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continued RFC process
At 04:51 PM 10/10/00 -0700, Daniel Chetlin wrote: On Tue, Oct 10, 2000 at 08:23:07PM +0100, Nicholas Clark wrote: Having had cause to root around in the archives of perl6 and perl5 lists, can I suggest that we use the system that perl5-porters is archived on in preference to the system that the perl6 lists use (MHonArc, apparently). Personally I found the threaded summaries and search facility on the perl5 archive much more effective. What do other people think? Er, compared to what the perl6 lists are doing right now anything is preferable. But xray _sucks_! Given the choice between searching xray and chewing tinfoil, I might choose the tinfoil. I'm trying to get them on a regular crawl schedule at work (I work for Northern Light, one of the search engines) but that's a spotty thing at the moment. (Soon, though, I hope... :) Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Continued RFC process
At 09:04 PM 10/10/00 -0400, Bryan C. Warnock wrote: On Mon, 9 Oct 2000, Nathan Torkington wrote: Closed-for-posting mailing lists that are publically readable is the best suggestion we've had to meet these ends so far. Anyone have better suggestions? Instead of group-writable and world-readable, how about group-writable and world-moderated? (Or just plain moderated, with the flavor o' the day being autohandled...) It's more work, which I am not a fan of, but I'm not a fan of everybody having a say, nor a select few workers having a say. I rather like it. Russ did have a point earlier, and I'm tempted to leave things open at the moment, or go the dual-subscription route and automoderate everything as OK until a problem arises. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continued RFC process
At 06:38 PM 10/8/00 -0400, Uri Guttman wrote: the second part is internals. not to take anything from dan, but i see a bottom up approach being very useful here. I disagree. This is too big a project to manage that way. If we do it we're setting ourselves up for an enormous amount of trouble later on. (And not that much later at that) The various pieces *must* have well-defined interfaces and behaviours, and that absolutely has to be specified before work begins on any particular piece. hammer out some working/prototype vtable code, work on the new I/O subsystems (this is a big project in its own right), work on byte code and related design issues, etc. again, these teams should be led and staffed by people with real experience in those areas. this should not be a public exercise (again read only should apply to any outsiders). Sure, as long as the behaviours of the individual pieces are known when work starts. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continued RFC process
At 10:36 PM 10/9/00 -0500, J. David Blackstone wrote:
J. David Blackstone wrote:
When they drafted the U.S. constitution, there was
a huge debate over whether to base congressional representation on
population per state or make each state equal. Both sides had a good
claim to the other being unfair; giving a smaller state (Rhode Island,
or Mac users) equal say with a larger one can seem unfair to the
larger segment, and I think in this case it would be. ("No,
seriously, guys, I think we should move the epoch to 1904.")
I agree with jdb. One equivalent vote per person opens the possibility
that some company in Redmond could assign 250 of its employees to
"go vote in that Perl thing and make it ours".
Ouch. Didn't even think of that.
Or, just as bad, the vote hits slashdot and we have a half-zillion frothing
slashdotties descend on us and either vote their bigotries on us or just
screw around for fun.
Also, I'd point out a weakness in the presidential analogy for Larry.
The President of the U.S. can only veto; any legislation he ignores
passes by default. Also, the President cannot introduce legislation.
Rather, Larry is like a king; and we are his ministers, courtiers, and
noblemen. We can argue til we're blue, debate, resolve, and vote; but
in the end, it's Larry who makes the decision.
Yes, although Larry is kind of like a king after the signing of the
Magna Carta. There's no divine right, here; if Larry decides we're
going to eliminate dollar signs for scalars and optimize the core for
a Cuse Python; module, most of us will jump ship. (Though not
without tears of regret.)
I'll point out a bigger failing in the analogy. The US isn't a democracy,
none of the states are (except for the odd dabbling in, usually badly, it
with ballot initiatives), and very few municipalities are.
A better analogy is that Larry's the Bishop and Chief Architect, while the
rest of us are engineers, sectional architects, artisans, craftsmen,
journeymen, and apprentices, working to build up a cathedral. (And yes, I
do mean this analogy in the way you likely think I do, amongst other ways)
Regardless, a "design decision by majority vote" just isn't going to fly in
a mostly-volunteer effort, and it rarely does in a commercial effort.
(Whether it results in a working system is a separate matter) If you need
an example, we have Unicode staring us straight in the face. It was put on
the table both out of general need and directly to serve a large part of
the perl userbase (i.e. Windows), and look how far it got us. Heck, 5.6 was
released as tatty as it was *because* people weren't working on the things
that were unfinished.
If a proposal is put forth to handle personnel issues via some sort of
community decision, that's great. If it gets Larry's approval I'm all for
it and will follow the decisions it makes. (Even if, or especially if, the
result is I take my leave) The one thing we should *not* do, though, is
make design decisions by vote. It's worse than decisions via committee--at
least those have some hope of being technically sound.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Update on the RFC Process
At 04:13 PM 10/3/00 +0100, Simon Cozens wrote: On Tue, Oct 03, 2000 at 04:06:00PM +0100, Piers Cawley wrote: Personally I'm betting that the volume we've seen on -language will pale into tiny insignificance compared to the volume on -internals once Larry has made his announcement. I doubt it; I think we've a lot of people who want to talk about how Perl should be. I don't think we'll have *that* many people when it comes to actually trying to implement those ideas. I'm with Simon on this. The set of people with the skills and time to design or implement the core is significantly smaller than the set of folks who think they can redesign some (or all) of the language. The discussion's also likely to be more focused and less grumpy. I hope... :) If we look at p5p, most of the traffic at any one time revolves around design issues, not implementation. (Barring the runup to a release, when the volume's more in OK/NOK messages) I expect the same will be true for us, though I expect the volume of internals design traffic to be smaller than that for language design. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
At 05:30 PM 9/11/00 -0400, Chaim Frenkel wrote: Up until that point, it is wasted energy. At this point, without code there is nothing locked down, no cost in changing. (Yes, even though they are bits, changing software, changing architecture has major costs.) Don't forget that changing architecture has costs, even without code backing it yet. There's still the mental costs of refiguring how it all fits together. (And it does all need to fit together--if the mental model's a kludged up hack, the implementation will be too) This isn't to argue against making changes and reworking things, mind. Just pointing out that all changes have a cost. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: code repository
Bennett, Perforce is a better source code control system than the source alternatives, and certainly better for the task we face than CVS. You're certainly not forced to use it. You can, if you rather, grab snapshot archives, rsync from the repository directory, or even grab a copy of the source from the proposed anon CVS mirror. If you've got a better alternative with a proven track record (and the only alternatives I know of that rival it all cost) put it on the table, please. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: code repository
At 09:29 AM 9/4/00 -0400, Bradley M. Kuhn wrote: Ask Bjoern Hansen wrote: the perl-qa people have some code they need to manage in a repository of some kind. For now I have directed them to SourceForge, but I have a 100 users license for perforce I got for perl, so if we can get a quick consensus that we might want to make a perl6 code infrastructure around perforce then I'll go ahead and set it up. I would like to vote against perforce, because it is not free (as in freedom) software, and CVS is. I don't think it's a good idea to build Perl6 development infrastructure around non-free software. I don't think we should make decisions about the software we use for development based on political views. The decisions should be based on technical merit and general availability. On a personal note, I would not be able to participate in Perl6 development if doing so required that I use perforce, because I have personal ethical beliefs that prohibit me from using free software. I may not be the only one. The only requirements for perl 6 development above and beyond normal perl building should be a unix-style diff creator. All the rest is a goodie, but shouldn't be necessary. I realize that perforce has possible technical benefits, but I think it's better to (a) stick with CVS or (b) wait for Simon's perforce-on-CVS hack or (c) start with CVS, and add Simon's hack when it's available. I'd rather not bet the development farm on any untested software. (Well, besides perl 6... :) This isn't any judgement on Simon's abilities, I just don't want to be debugging (and possibly regularly rebuilding) the source repository at the same time we're trying to figure out where we whacked perl. One wildly variable variable at a time, please... :) Perforce is nice, works very well, is liked by a lot of folks doing perl development now, and generally meets our needs. I don't see any reason why we shouldn't use it. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
