RE: perl5 to perl6
-Original Message- From: Nathan Torkington [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 10:20 AM To: Chaim Frenkel Cc: [EMAIL PROTECTED] Subject: Re: perl5 to perl6 Chaim Frenkel writes: Those are all major typo inducing changes. You'll need alternative micro-code loads for your fingers, when switching between clients and when editing scripts that pre-date Perl 6. So we can't change Perl, because changes have to be learned? So now the changes are too SMALL, and we should have a language that is completely different so that you won't be confused when you edit different scripts? I don't see the inevitable typos as a problem. They're quite temporary anyways, even for people who have Perl 4 habits still. As long as the concepts make sense, which they do, the brain should adjust in short order. (Said by a person who still writes 1991 on checks.) Programmer efficiency IMO is secondary (as long as it's fun) to any requirement of abyssmal maintenance or conversion. So, I'm happy with it. The books will be off for a while, but they need to be rewritten anyways. (Said by a person who still refers to the pink camel when the blue one is under the bed hiding.) David T. Grove Blue Square Group [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: Perl, the new generation
I've been wondering for quite some time whether we were creating a Perl for the purpose of cleaning up the ridiculously rigged Perl 5 internals, or creating a Perl for the simple enjoyment of creating a new programming language. Certainly, recent discussions would point to the latter; as we move farther and farther away from Perl 5 syntax, we move dangerously close to completely closing Perl as a viable tool for the gazillions of users who have the misfortune of legacy. This legacy isn't just a website or a utility here and there anymore, but often an entire suite of software, or tools integrated into operating systems, some or much of which the user may not even be aware of. Translating is not an option for these people. A slow transition may be a catchphrase nowadays, but with Perl 5 stagnant, 5.6 accepted on only two systems that I'm aware of (SuSE and Win32/AS; rejected everywhere else), and PHP/Python/.NET ready to swollow up anyone who would believe anything, I'm concerned that this transition may not exist. So, I'll go you one farther. What about creating a cleaned up perl, and letting those who want to play with a new language entirely do so in the form of a true fork. Certainly, Perl 6 is coming to resemble Perl 5 little more than PHP and resembles Perl 5 and Perl 5 resembles C. We haven't even started writing the actual tool(s): we haven't even completed planning without coming up with a tool that only resembles Perl due to a use of $@%, as an offspring rather than a serious hot bath. If we keep this up, Larry's 95% mark will end up going to 90%, 85%, and then who knows. I DO NOT DISLIKE the changes that I'm seeing. However, their coolness ends when it comes time to trace through my entire operating system(s) and change every perl file that exists here; and the thought of a mass exodous to Python/PHP because we've made Perl 5 obsolete and scared off the rest of our community, especially corporate members, is completely unappealing. Corporate users do not think in terms of neat and novel, they think in terms of how much work it's going to be to keep up with the complete overhaul of a language versus moving to a language with a stable syntax once and not having to deal with it again. We will not soon rise above that kind of bad opinion. FUD? Perhaps. Reality? Definitely. Python books are already full of FUD, and I've had to stop reading .NET books because just holding the books in my hand makes my blood pressure rise 90 points. Imagine what will happen when that FUD turns serious and actually costs Perl users a great deal of money? Unless Perl 6 is capable of parsing and running that 99.9% (or higher) of Perl 5 scripts originally foretold, I foresee a far worse outcome for Perl 6 than has happened for an almost universally rejected 5.6 and 5.6.1. Fun is fun. But work costs money, guys. And if you cost people money with a free tool, repercussions could be bad not just for Perl but for free languages, among which Perl has heretofore been the leader of the pack. Actually, Peter, I was getting very, very close to writing this anyway. David T. Grove Blue Square Group [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: Peter Scott [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 10, 2001 12:20 PM To: [EMAIL PROTECTED] Subject: Perl, the new generation This is a long shot, but here goes. I was thinking about Perl 6 this morning while jogging (blithely ignoring the forest scenery). It occurred to me that what appears to be emerging as the new language embodies bigger changes than I ever anticipated - which is great, software should improve with time. And so I found myself wondering whether the title does it justice. Perl 6 is looking to me almost like an entirely new language. The change from Perl 5 to Perl 6 is much, much larger than the change from Perl 4 to Perl 5 (virtually all Perl 4 code ran unmodified under Perl 5). So, I wonder aloud, do we want to signify that degree of change with a more dramatic change in the name? Still Perl, but maybe Perl 7, Perl 10, Perl 2001, Perl NG, Perl* - heck, I don't know, I'm just trying to get the creative juices flowing. I do believe that the tremendous effort that is going into Perl 6 deserves more attention than I think it will get with that title. At some point, the Perl 6 cognomen will have attracted enough inertia that we couldn't reasonably change it even if we wanted to. Maybe that time has already come. Maybe not. Can't hurt to raise the question. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
RE: Perl, the new generation
Incompatible continuity. Sounds like Microsoft marketing. We're strongly considering keeping compatibility, and rejecting it wherever we can insert something that looks momentarily cool. Of course your Perl 5 programs will still work, as long as you convert them to Perl 6. We'll have a parser that will be able to do this. Of course, you will have to write it yourself. Perl 6 will still be perl, because the name won't change... the language is a different matter entirely. Doesn't wash... A non-MS-microweenie can only digest a limited number of oxymora at a time. David T. Grove Blue Square Group [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: Larry Wall [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 10, 2001 12:44 PM To: Peter Scott Cc: [EMAIL PROTECTED] Subject: Re: Perl, the new generation Peter Scott writes: : So, I wonder aloud, do we want to signify that degree of change with a more : dramatic change in the name? I'm inclined to think that people will be more likely to migrate if they subconsciously think we're taking continuity into consideration. Which we are, albeit not at a syntactic compatibility level. Larry
RE: Perl, the new generation
Perl 5 is far from stagnant--please don't bend the truth to fit your points. My impression is that there's quite a bit more constructive activity on p5p than there was a year ago. I've stopped paying attention to P5P except for keeping an eye on the possibility of a new surprise upgrade from Microsoft. However, the attitude of the P5P is irrlevant to the user base. : Unless Perl 6 is capable of parsing and running that 99.9% (or higher) of : Perl 5 scripts originally foretold, I foresee a far worse outcome for Perl 6 : than has happened for an almost universally rejected 5.6 and 5.6.1. There you go again, as Uncle Ronnie used to say. Excessive hyperbole will cost you sympathetic readership. Shall I list them again? Dude, it's been 13 months since 5.6 was released, and two commercial entities have so far accepted it: ActiveState and SuSE. Speaking with SuSE around October (7.0), the rep's answer getting back to me was simply we don't consider it to be stable enough yet to include it in our distribution. If Perl 5.6 hasn't caught on after a year, God help us trying to pass Perl 6 off as still Perl sometime this decade. Nobody ever foretold 99.9%, as far as I recall. I surely didn't. I was quoting you from about 5 messages ago... larryquote If 99.99% of scripts translate, that's good enough for me. :-) Actually, if 95% of Perl 5 scripts translate, I'll be overjoyed. /larryquote That's where it came from. The issue on the table is the magnitude of the diversion from Perl 5 to Perl 6, and my issue is its effect on the user base, especially commercial users and their legacy. I have to be concerned for these people: they're my customers and my peers. Perl 4 - Perl 5 happened at a time when perl wasn't considered THE scripting language. Entire commercial systems weren't widely written in it. Python, PHP, ASP, VBS, Ruby, and .NET weren't hot on it's tail spreading FUD to mezmerize users with transparent and ephemeral fancies. The effect on Win32 alone could be disastrous, so consider what would happen on systems where parts of the system itself were Perl 5 (some Linux distros lean heavily on Perl). p
RE: Perl, the new generation
On Thu, May 10, 2001 at 03:58:41PM -0400, David Grove wrote: it's been 13 months since 5.6 was released, and two commercial entities have so far accepted it: ActiveState and SuSE. a complete, barefaced lie. To be a lie, it must be purposeful. I am not above error, however. Who do you get your Perl from? I build my own. It's (historically speaking) the only way to get a reliable Perl on Win32, though some module still don't compile without proprietary hacks. Redhat? They ship 5.6.0 in RH7.0 Mandrake? Hrm, perl-5.600-30mdk.i586.rpm. Yep, that'd be 5.6.0 My information on this comes from discussion (asking directly) in undernet #linux. If this is in error, tell it to them. My stating this comes from actual research short of purchasing every linux on the planet just to see if they have Perl. The research took place specifically to see whether 5.6 was appropriate for PerlMagic, and it was place in 5.6 only because Win32 users thought they needed it, though several of the P5P some months ago suggested a strong warning to my users. Solaris? Talk to Alan - Perl 5.6.1 going into Solaris 9. Somebody said it was and described why. Debian? They're not commercial, but they're still a pretty big OS distro; let's have a look in the next release: (the testing distro - Debian release very infrequently.) http://packages.debian.org/testing/interpreters/perl-5.6.html shows me they're going to be shipping - oh, Perl 5.6.1. Even better. What? You mean they're actually accepting it a year and a half later in a testing version? I'm not sure you made a point here. Anywhere else? :) FreeBSD comes to mind, among others. Can we get back to the subject now? p
RE: Perl, the new generation
On Thu, May 10, 2001 at 10:00:13PM +0100, Michael G Schwern wrote: On Thu, May 10, 2001 at 01:49:30PM -0700, Edward Peschko wrote: We need to keep syntactic compatibility, which means we need to keep the ability for perl6 to USE PERL5. I think you're in violent agreement here. This has been declared a goal of Perl 6 from almost day one. Ok, fair enough, but until just a little bit ago I was hearing stuff different from Dan. That has been changed, apparently recently If this is an actively pursued goal, I consider the issue dead, with one remark: use Perl5 or anything else that has to appear in legacy code thereby forcing hunting and changing all perl programs will likely cause it to reappear, unless we can find a way to default to both. On UN*X this is symlinks (let's not reopen it, just suffice to say that /something/ needs to prevent this requirement), and on Win32 and other systems without symlinks, a separate executable. Since the executable is so small on both (all?) systems, it's not much of an addition. Win32 already has perl5.6.0(-win32-multi-thread-morestuff).exe and perl.exe. This is an old argument, and one I don't wish to reopen, as long as /something/ along this order can provide for a painless migration. With that in place, let's change whatever syntax gets annoying. p
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: ANNOUNCE: smokers@perl.org Discussion of perl's daily build and smoke test
"H.Merijn Brand" [EMAIL PROTECTED] wrote: On Mon, 19 Feb 2001 08:49:04 -0600, Jarkko Hietaniemi [EMAIL PROTECTED] wrote: On Mon, Feb 19, 2001 at 03:47:12PM +0100, Johan Vromans wrote: As an active non-smoker, I'd appreciate a different name. Likewise. What's wrong with builders? Because "PerlBuilder" is a commercial product. It's a poor quality competitor that I wouldn't recommend to anybody. If you put the words together like this, you'll create an accidental association. p
Re: Tech documentation (Re: Perl Apprenticeship Program)
Kirrily Skud Robert [EMAIL PROTECTED] wrote: On Tue, Dec 05, 2000 at 11:28:31AM -0800, Nathan Wiger wrote: Anyways, that's just one suggestion. Do I have any idea where to find these mythical people? No, unfortunately. Perhaps some feelers on newsgroups might be a good place to start. Personal experience shows that this could be a win, though. Open Source Writers Group (http://oswg.org/) is a good starting point. I'm subscribed to their mailing list. I can think of a couple of other good places to try, too, but they're a bit politically incorrect to mention in this context :-/ K. Apologies to this author. I didn't know he was a she, and I mean no offense at my guess at what group was politically incorrect. It just looked like Dan had seen the link and missed a bit later on. Of course realizing that documentation is good no matter where it comes from, I think we need to scour around on the inside as much as possible before looking to "outsource". Perl writing has a sort of unique humor (and odd linguistics "perlisms"), which has helped to form and identify the culture. I think it would be a shame to lose that if we pawn off too much onto people not "into" the culture. I won't discount her suggestion though. Any documentation is good documentation, especially on behalf of programmers.
Re: Tech documentation (Re: Perl Apprenticeship Program)
Nathan Wiger [EMAIL PROTECTED] wrote: Steve Fink wrote: David Grove wrote: Anyways, that's just one suggestion. Do I have any idea where to find these mythical people? No, unfortunately. Perhaps some feelers on newsgroups might be a good place to start. Personal experience shows that this could be a win, though. Maybe a big "help wanted" sign on perl.org and maybe ora if we can talk them into it. I think I've already volunteered for some of this though, in a roundabout way. Let this circulate for a bit and see what we get from our own insides.
Re: Perl Apprenticeship Program
B. The "master" / "apprentice" relationship is just that - it depends how the people in question relate. As a potential "master" I am all too aware that I am not skilled in teaching - usually because I don't know what is obvious vs what is obscure - so anyone "taught" by me has to ask questions rather than be lectured to. That you both recognize your own limitations and know at least one way how to get around them is a sign that you would be quite an _effective_ teacher, Nick. The adverse can be said for learners. Few know "how" to learn. As an adult with A.D.D., I learned how to learn when I was around 25. In high school I didn't do so well. Well, that's a bit of an understatement. But after I learned how to learn to match my needs, my college tracscript reads solid 4.0. You in particular have a great deal to teach, Nick. I really wouldn't want to see you not try to because you're afraid you might not be a good teacher. Just treat an individual as an individual, and work with him. Things sort themselves out in any kind of relationship like this. p
Re: Perl Apprenticeship Program
Kirrily Skud Robert [EMAIL PROTECTED] wrote:
On Tue, Dec 05, 2000 at 11:05:43AM -0800, Steve Fink wrote:
David Grove wrote:
Also, as far as documentation goes, I think it _should_ be written
by
apprentices, so that non-masters can understand it too. That's
always
been
a huge criticism of the perldocs. That's not grunt work. That's
proper
allocation of duties to the best suited personnel for the benefit
of
the
project.
Except it's a particular duty that nobody really likes to perform.
Which
pushes it into the realm of grunt work.
Bah. *I* like documenting.
Yeah. Haven't you noticed some of the sizes of my posts? Typing fast
helps. Not everybody hates it, especially since perl doc tends to let
people show a slight perlish 'tude... not to mention make up a word now
and then.
("whipuptitude" -- a la Larry)
;-))
I'll reiterate though. Initial documentation, be it basic notes or
whatever, have to be done by the programmer. Any technical writer (it's a
profession) will tell you that. The apprentice will only be able to
expand, and only expand within his own capabilities. Unless the skill is
already in his brain, he'll need something to work from, and the "master"
will have to do some proofreading (also tedious) no matter what. If the
skill is already in the apprentice's brain, he's not apprentice material,
and should be apprenticing someone else. The counterargument of "following
closely and paying attention will be enough" (I expect someone to say
this) works only to a point.
I'm not griping about anything. I'm just advising from the point of view
of someone who knows some of the pains of technical writing.
Re: Perl apprenticing
There is here (me). Dave Storrs [EMAIL PROTECTED] wrote: I've tried to snip as much as possible without fouling up attributions. If I failed, my apologies. On Thu, 30 Nov 2000, Dan Sugalski wrote: At 11:47 AM 11-30-2000 -0500, Bryan C. Warnock wrote: [...is there a place where Perl Apprentice-wannabes can sign up with a Perl Master...?] Not at the moment, at least not formally. Want to set something up? (And yes, I'm serious. A good master/apprentice thing would help a lot of folks, I think) I would be very interested in an apprenticeship, if such a thing were to be set up--and I'd be willing to help set up the infrastructure. However, we should move carefully, because it could be a very good thing or a very harmful thing depending on how we implement it. So, are other people actually interested in this, at least enough to open a new thread on it? Dave Storrs
Re: The new api groups
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? Philip Newton [EMAIL PROTECTED] wrote: On 14 Nov 2000, Chaim Frenkel wrote: Did I miss something? I didn't see any discussion. Was this off-line? No, on perl6-announce and perl6-internals. Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Fwd: ezmlm response
Interesting. I didn't get the announcement from there. Out of curiosity, is majordomo deprecated? --- I've been unable to carrry out your request: The address [EMAIL PROTECTED] was already on the perl6-announce mailing list when I received your request, and remains a subscriber.
Re: Critique available
Anyone think others are needed? "Myopia neither equates the absence of existence of a distant object, nor demonstrates the insanity of the non-myopic." or, roughly translated, "Issues should be faced rather than avoided by attacking the person who points them out."
Re: Critique available
If there's one thing that I know about Larry, it's that he's not stupid. Neither are the members of the perl community as silly and uninitiated as the "perl-elite" would make them out to be. I can see _much_ more information coming out of these RFC's than just the content of the RFC's in a techical sense moving toward 6.0. There's also general disgrunts, leanings of the programming community at large, and reasons why the momentum of the Perl language is falling off. For example: "Program Perl in Python" This nonsensical RFC and its kin "in Java" help to point out that our syntax is becoming obsolete. Larry picked up on that very early. It is my personal opinion that Python has nothing whatsoever to brag about in the same room with Perl, but it does have an object syntax. Ours is clumsy (or at least a bit ugly), and people want a bit of prettying. I personally objected to this RFC as a pure technical issue, but I agree with the meaning behind it. Larry appears to have done so too. None of this was intended to be highly technical, AFAIK. Logically, since only a small number of humans know perl internals well enough to express their ideas in terms of perlguts, it would be ridiculous to expect them to have an "implementation" section that said much more than "I don't know how to do it, but I'd like to see it." Logically following that, since Larry did open this up to the perl population at large, this was necessarily to be expected. Logically, getting detailed "implementation" sections could never have been a serious goal. It would appear, then, that the RFC's were intended to get a feel for where we as a community would like Perl to go. There's more to the success of a language than its syntax and internals. I'm told that Eiffel is about the truest OOP language in existence, but it has a tiny user base. We need to understand what people want, whether the desires are attainable or not. Only by paying close attention to the desires of the perl community, why our advocacy is falling off and our user base is levelling off, can we hope to please the people who are migrating to lesser languages like Java and Python. It sounds very much like you're criticizing the RFC process for not coming up with a complete 6.0 specification including all internals by the time they were done. This is very nearsighted. The RFC process was effective for more reasons than finding new implementations of good and bad ideas, it was also effective in finding out where Perl needs to grow in order to be more applicable. I see it as a first, huge step in bringing momentum back into the Perl language. Also, your comments about chairs didn't seem to comprehend their purpose. Perhaps "moderator" might have been more effective, or "mediator" as between Larry and the working group, or "translator" or whatever else. "Chair" means nothing on a resume in terms of a volunteer programming effort, except perhaps for a search of vanity. Mark-Jason Dominus [EMAIL PROTECTED] 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 Mark-Jason Dominus[EMAIL PROTECTED] I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
Re: Critique available
Absolutely and double the vulgarity. I can't imagine that the article was posted at all. Several of us (you guys) have _some_ pull at O'Reilly... please suggest that the article be pulled. For the company that backs perl the most to publish something so disgustingly myopic is unconscionable. Nathan Torkington [EMAIL PROTECTED] wrote: Simon Cozens writes: http://www.perl.com/pub/2000/11/perl6rfc.html Agree 100% to every point. I don't. A constructive critique of the Perl 6 RFC process might be useful. This onslaught of negativity is not. The Perl 6 RFC process got people talking about the future, and we have a staggeringly large number of suggestions for improvements to the language. Most of them solve real problems, some of them cause more problems than they solve. Some of the solutions are bogus, some are brilliant. So? If you want every proposal to be either perfect or knowledgably killed, you really do need to go through an IETF-like process with strong editors and a lot of time. We don't have strong editors and we didn't have the time. Right now, Larry has an idea of the kinds of things people will want to do with perl6 that are hard to do with perl5. I think it's pretty unrealistic to have come up with much more than that. And Mark's article is hardly an accurate picture. Yes, many of the implementation sections were deficient. Is this the earth-shattering catastrophe it's made out to be? No. Guess what--many were just fine. And by focussing on the people who fought opposition to their proposal, Mark completely ignored all the people who *did* modify their RFCs based on the opposition of others. But what really pisses me off is that the harshest critics are people who bowed out or were silent during the stage where we were setting up the RFC process. I'm sorry. We all did our best, and if you want to suggest ways that we could do better next time, then please do so. But squatting and taking a big steamy dump over all that we did--that's just wrong. Not only is it wrong, it's also hurting our chances. When an article in perl.com is so overwhelmingly negative about the work so far, do you think that stirs confidence in what we're doing? Do you think that people will read the article and think "yeah, I want to write code for *that* project". Will they think "I'm looking forward to perl6!" No, of course they won't. They'll think "it's a typical Perl fuckup". And that's what frustrates me. In reality, it's highly premature for people to be saying we're doomed, but the article doesn't give that impression at all. What would I have wanted to see in the article's place? One of two things. Perhaps something showing why language design is hard, of which there was a little in the article. But it was lost in the "but they were all idiots or assholes" message. Or perhaps something suggesting how to do things better next time, of which there was very little. I'd have loved to have seen either of those two articles. So, I'm disappointed and a little frustrated. But life goes on. Nat
Re: Critique available
John Porter [EMAIL PROTECTED] wrote: Bennett Todd wrote: Java is crappy engineering with superb marketing, This is so wide of reality, I conclude that you don't know the first thing about Java. Ok, Visual Basic then.
C Sharp?
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#, I went on a studying rampage. I find nothing for anything except Win2k. Can someone provide links to compilers or resources for non-Win32/Win2k C#? FWIW, although I hate Java with a passion, something about C# seems to be getting me... umm... aroused... (And I swore I'd never use another Microsoft Development Tool.)
RE: Transcription of Larry's talk
On Wednesday, October 18, 2000 12:59 PM, Larry Wall [SMTP:[EMAIL PROTECTED]]
wrote:
Simon Cozens writes:
: You're learning Japanese, right? It's gotta be "toriaezu".[1] :)
Yes, but if we go down that route, we're gonna end up with all the
verbs at the end. Instead of "print @foo", we get something like:
@foo wa kaite kudasai;
Larry
{werbeh gninrael} (ton)er'uoy-tsael::ta
but then, proper japanese is read top to bottom, right to left... sounds like
forth
RE: Now and then
On Wednesday, October 11, 2000 11:02 AM, Nathan Torkington [SMTP:[EMAIL PROTECTED]] wrote: David Grove writes: I'm wondering how different this is from the current setup. Currently there's the pumpking and the pumpking decides when to release a new version of Perl. This exposes the pumpking to all sorts of allegations, and potentially exposes Perl to being bought out. When no single person can force a release through, both problems go away. It's distributing the current pumpking's responsibility (integrating patches, quality control, communication and deadlines) to more people. This has the added benefit of hopefully avoiding pumpking burnout. Points of clarification, however. QA team determines definite preparedness for release? It's a joint decision. If QA likes it, but the code person doesn't, they have to sort that out between themselves before the release can happen. If the user liaison says "we've been promising this for the last three releases, we can't make another release without it" then the others have to listen. But nothing can be released without QA's approval. Nat Yes, that satisfies my concerns by providing "checks and balances" to the system. Bjarne Stroustroup in "The Design and Implementation of C++" talks about ANSI and the C++ committees, and how he's always tried to get real strings into the language as a basic data type, but every time he brings up the subject either Dennis Ritchie or a chinese lady whose name escapes me raises her hand and with that it's all over. The setup there is that it has to be unanymous. The need for unanymity slows down the process, but provides for a completely stable C++ implementation. I'm not sure that unanymity wouldn't be going overboard for Perl, but that would be a decision internal to the QA group, correct? Or something determined by Larry? There's definite pros and cons each way. Basically, the cons are that some things would never end up in the perl core, and the pros are that certain things would never end up in the perl core, like temporary and experimental "fixes" that don't work implemented mainly for a marketing stunt and that have the byproduct of disabling major features of the language... Have I tangented with this, or are we still making sense to each other?
RE: Now and then
On Wednesday, October 11, 2000 2:34 PM, Nathan Torkington [SMTP:[EMAIL PROTECTED]] wrote: David Grove writes: I'm not sure that unanymity wouldn't be going overboard for Perl, Except that it's not unanimity of individuals, who are cantankerous and troublesome, but unanimity of teams. Each team has the moderating influences of three people to try to reach consensus. The release manager might work with a team that can't agree to help them reach a decision, but nobody would be imposing will from above. but that would be a decision internal to the QA group, correct? The QA group ain't special. It has a role to play, but so do the code maintainers and the user liaison folks. Have I tangented with this, or are we still making sense to each other? You seem still to be making sense. Are we agreed that we have a good ongoing model to try when we get to that stage? Nat I agree that it's moving it a positive direction, yes. Especially when no two or more members from a given - company is not a right word here, Nat... - "point of view" (ActiveState, Solaris, Digital Unix - no, er, "qlique"(?)) would be on a team. How to define that would be difficult, but the effect would have to be better than before. That would almost have to be a judgement call by the team manager. If I understand correctly, large teams would have a small team of "control" (bad word, but I don't know how else to put it) with a team manager for that team, and small teams (like the ones with two or three members, that have been pointed out) would be their own "control" team, and unanymity of teams would be required for release, is that a good summation? Anyway, it's definitely moving in a good direction, and shows potential to solve a majority of problems. Yes, this is a good direction.
RE: Now and then
On Wednesday, October 11, 2000 3:45 PM, Nathan Torkington [SMTP:[EMAIL PROTECTED]] wrote: [snip[ documentation, etc. The teams will obviously work together at time. Each team has three roles identified: the person who checks in patches, the person who represents user interest in that area, and the person who QAs that area. There may be others, members of the public, but these three are the ones who must be satisfied with a release before it can go out. There is no team leader, merely the union of those three people. The release manager is there to help each team work with its team members, and to help teams work together. The system is self-balancing. The release manager cannot override a team that will not approve a release. If teams want to kick out the release manager, they can get together and do so. The release manager should be involved in intra-team disputes to ensure that booting a team member out is an action of last resort and not merely a way to force a release through over valid objections. [snip] Everything 100% A-OK, clear, agreed, and sounds wunnerful. Anyway, it's definitely moving in a good direction, and shows potential to solve a majority of problems. Yes, this is a good direction. What else is there to say? I want to get this topic dealt with so Naw, I just meant that it sounds good in theory. As you've pointed out, it just needs to be seen in actual practice. Also, IIRC, it has to be "approved". I tend to lose patience with any thread that goes on for longer than three days, so we're reaching the end of my ability to focus here :-) That's fine, you've been patient, considerate, understanding, and extremely helpful. You deserve a nap... or a beer, your choice.
RE: Continued RFC process
On Tuesday, October 10, 2000 1:26 PM, Andy Dougherty [SMTP:[EMAIL PROTECTED]] wrote: [An offlist request for clarification, though I invite you to follow-up to the perl6-meta list if you deem appropriate] Absolutely it's appropriate. They think I'm paranoid and the only one who sees the danger. Relatively few people speak openly about it for fear of getting the same beatings I get on a regular basis. Frankly I think it's important for these guys just to realize that other people are sitting back and watching, with unexpressed interests. On Tue, 10 Oct 2000, David Grove wrote: How do we allow the core developers some peace, while giving the community FREE voice? Apart from the voting idea, do you have any other specific suggestions? The dilemma you cite is indeed real. The problem with voting is indeed just as has been described. It can be faked. Who was it... deja.com... some search engine has votings on it on a regular basis. It was basically fair until a certain point. For several months, FreeBSD and Linux topped the charts, until suddenly, in about a week, NT went from the total bottom to the total top. I think the subject was something like "secure server O/S". Similar things happened to VB in different ratings... started out sucking in the majority vote (bottom of the list by a huge margin), then suddenly it sprang up. Perhaps, then, there should be one more officer, chosen by Larry himself. This person would be responsible for collecting public opinions and representing them to the developer group, who needs to follow that guidance as long as they're technically capable. (Obviously, because of my big mouth and cynical nature, I'm not qualified, so I'm not suggesting myself.) This person must be impeachable, or at least, know when to step down when the time comes, and be trusted to know when to do so and actually do it. This person should also determine the timing of releases, or agree to the timing based on public opinion. No more of this releasing versions before they're ready or withholding modules. If we can't have a stable perl, we won't have a perl at all. Don't think that our current "information officer" is capable of accurately or faithfully filling this role, you'd be off by several hundred miles.
RE: Continued RFC process
On Tuesday, October 10, 2000 1:33 PM, Jonathan Scott Duff [SMTP:[EMAIL PROTECTED]] wrote: David Grove wrote: Read-only and carefully censored lists are irrelevant to the goals of Perl 6's giving voice to the perl community. They lead us right back where we were before, with a core group free to sit back unchallenged on their complacency and let Perl go to rot. What does "unchallenged on their complacency" mean? In the world of OSS, those that have time and inclination design or code things they find interesting. If no one champions a cause, nothing happens. It sounds like you are saying that if the community wants Feature X and no one steps up to write the code to add Feature X to perl, then "the community" should somehow be able to force the developers that are already working on some aspect of perl to add Feature X. However, I don't agree that the developers should be able to ignore the community within a closed-off little clique. What community needs do you feel are being ignored? "Unchallenged on their complacency": knowing the issue and ignoring it because it doesn't affect them or their O/S, or in Tom's case, his personal workstation. Having a sudden shock of amazement, anger, and comprehension that the problem exists, then forgetting about it because they don't have to care. To those who don't know the old argument, which out of respect for the list and the listmaster I won't detail, I'm not talking about features so much as corporate collusion and corporate control. In the Win32 world, this has been very real, and very painful, but the P5P mostly ignored the issues because they were either not interested in Win32 affairs, or affected in other ways. The community need that I _know_ is being ignored is the ability to have a perl that's not taking a dive toward being slopped all over with the four-colored flag. Community interest must take a higher precedence in the development of Perl 6 than corporate interests, if Perl 6 is to be a "community project" at all. To those who do know the old argument and still think I'm paranoid, just see the logic in being _able_ to control the problem, since it is definitely at least a potential. To those who do know the old argument and don't think I'm paranoid, please speak up. Don't just private mail me. I _choose_ not to be paying for perl by 2005.
RE: RFC Process Improvements (was Re: RFC 357)
On Wednesday, October 04, 2000 4:19 PM, Nathan Wiger [SMTP:[EMAIL PROTECTED]]
wrote:
Adam Turoff wrote:
RFC Improvement #1: All updated RFCs must contain a CHANGES section.
RFC Improvement #2: All updated RFCs must contain a synopsis of
relevant discussion, including opposing views.
RFC Improvement #3: All final RFCs must contain a discussion of why
they are finalized.
RFC Improvement #4: Each working group may define more stringent
acceptance
criteria for RFCs. -licensing doesn't care
about including test plans, and -qa doesn't care about
redistribution considerations.
RFC Improvement #5: An working grouup chair can cause an RFC to be
withdrawn from condideration if it is off-topic
or simply rehashing old issues. This is to keep
the brainstorm-to-proposal ratio close to zero when
rampant brainstorming is not desired.
Excellent. Another one, which has informally been done sometimes:
RFC Improvement #2a: A link to the mail discussion archives should
be provided for each revision.
And *possibly*: Somebody should be able to pre-scan them. Not for
content ("bad idea"), but to make sure they fit the format and also
don't rehash already open or previously covered issues. This is on the
dangerous edge of being facist though, and I'm not going to press the
issue if others dislike it (I'm not sure I like it myself).
A modified RFC process should be in place for Perl6, where it fits.
And it should not be a process that generates 150+submissions/month
of wildly varying quality.
Agreed. That would make RFC's most painful, un-fun, and self-defeating.
-Nate
As long as the word "relevant" is prevalent in #2, this makes sense.
Referencing "nonsense", whose definition should be thoughtfully determined by
the individual (not just non-opposing views), would make the whole revision
irrelevant.
RE: Undermining the Perl Language
It's possible you're speaking of one or more of the working group chairs, in which case your criticism may well be valid. This, though, is one of the cases where you may need to cope (as a volunteer project one needs to work with what's available). You can also speak to folks a step or two up the ladder, such as it is--Kirrily's a sane and sensible person to deal with for any of the -language sub-groups, and if she's not, then Nat *certainly* is. And complaints about me can always go to him too. Nobody's picking on you, Dan. Honestly it looks like a good part of the problem we're having is that people are treating things that aren't particularly important to be far more important than they really are. I don't feel that this is appropriate or accurate. The emminent takeover of the perl language is _not_ a trivial matter. It is not a scare tactic to use this language, since all of the proof is in the public domain and available by simple deduction. The inappropriate action is not to act, and the inappropriate verbage and misinformation is that there is either not a problem or that nothing can be done about it. If someone else were willing to take the soapbox with different words but a similar result, the result of the protection of our language from monopolists, and positive action to move towards more positive advocacy for perl's benefit, I would be happy to step off and keep my mouth shut. This thread has been moved and re-Subjected. Please respect the listmaster's wishes and keep it in here.
