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
Lightning flashed, thunder crashed and Simon Cozens [EMAIL PROTECTED] whispere d: | 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. Not to mention "revisionist history". There were any number of uncourteous voices during the RFC process. -spp
Re: Critique available
Comparing the perl6-language and the perl5-porters simply doesn't fly. It's not even comparing apples and oranges, it's like comparing a busy market place and a faculty lunch. In the first case we are talking about a crowd of people most of which do not know each other, do not know what the people how to offer, do not not whether to trust the snake oil dealer, whether the pumpkins being sold are fresh or rotten, whether the trinkets of the eloquent short brawny fellow with pieces of cork hanging from his hat really are gold, whether to avoid the two people bargaining over the price camel hot dog or to join them, and so on. A busy mayhem, lost of people hawking their wares, lots of people buying them, haggling over them, laughing at false premises, lots of fun. There maybe a lot noise but it's undirected and can be safely ignored for the most part. In the second case we are talking about people that have been doing together the same thing for a long time. They know what has been attempted in the past, they know the existing art, they each know their each own piece of the lore. But they also know each other well, maybe too well, how to tick each other off, resulting in some megaton class lambasting once in a while. They have developed strong opinions over the years and they have their own agendas, and things they care deeply about. Now, could we please move on with more constructive discussion of what to do in the futurepas Nat requested? -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Critique available
Ok, Iv'e seen this debate - I will try to put something constructive:- Richard =Head1 My opinions of the Perl6 RFC process =head2 Where do I come from this? I am an amauteur perl user who uses it on web sites and for other admin tasks. Have I looked at the code? - Yes. Do I know the insides well? - No. Do I know anything about brainstorming? - Yes (I do a lot). Do I know anything about regexes? (the topic of most of my RFCs) - Yes when at University (admittadly years ago) I did some cutting edge work in this area - so I think I new what I was doing. I do lurk p5p but have only posted a few times. I look after the [EMAIL PROTECTED] mailing list and I am just in the process of slowly taking over the pumpkin for the riscos port. I do however take part in many standards activities in the realm of telecoms (my day job). =head2 Brainstorming - The first part of any brainstorming is to let any and all ideas flow - without lots of argument. By all means ask people what they meant, or point out other ways to achieve the same, but always allow ideas however silly to be suggested. Then, but only after the ideas have flowed some filtering is important, some ideas will be good, some will be good but difficult, some might have some good points but also some bad. Seriously consider each suggestion and categorise the results to "Yes", "Probably", "Yes but not this way", etc. Publish those simple results, and if time allows permit a second round (or more) of discussion. Brainstorming groups must not need chairs who dictate, but rather moderators to give every one a chance to speak and maintain momentum. each group possibly needs a "Scribe" who sits outside the discusions to note anything of importance that might get missed. This second role is perhaps less important with email based brainstorming. First one needs ideas Then, they are checked for "Can this be done" Then, prioitise and / or find volunteers It is totally wrong in a brainstorm about the perl6 language to initially be concerned with implementation. The second stage of filtering should be very aware of implementation, but not the first. =head2 What went wrong with the RFC process? Too much led by the existing perl5 gurus, rather than people who are good at managing brainstorming. (The Gurus should be there as part of the discussion but they are not the best moderators). To little of Larry. The process has ground to a halt, it needs to keep up some momentum, with interim conclusions and areas still open regualarly posted. The interpretation of the meaning of the status was at best variable, and there was no defined process to make RFCs frozen. The definitions and the process should have been defined CLEARLY. The process needs to continue in the future so that ideas for perlN.M can all be submitted by anyone with a good idea, to be incorperated as and when time and effort are available. The person with the idea, is unlikely to have the knowledge and time to push the idea through a p5p swamp - I know I have given up in the past. If the groups were in a position to make decisions, they should be formally proposed, and then formally voted. The process needs in advance to decide what constitutes agreement. Concencus (as at the ITU), Rough concencus (as in the IETF), 2/3 (as in many standards bodies), 50%+1 (as in a many things)? I hope we do not have to go to this. Discuss and build ideas - dont argue. Peace. Richard -- [EMAIL PROTECTED]
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."
Critique available
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
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
On Thu, Nov 02, 2000 at 10:11:56AM -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 Agree 100% to every point. -- "The best index to a person's character is a) how he treats people who can't do him any good and b) how he treats people who can't fight back." -- Abigail Van Buren
Re: Critique available
At http://www.perl.com/pub/2000/11/perl6rfc.html, Mark-Jason Dominus wrote: There are a lot of people around who do have some understanding of the Perl internals. An RFC author who knows that he does not understand the internals should not have a lot of trouble finding someone to consult with, to ask basic questions like ``Do you think this could be made to work?'' As regex group chair, I offered more than once to hook up RFC authors with experienced Perl developers. As an RFC author and persistent discutant, I always assumed that all/most/many of such qualified internals folks would be reading the perl6 lists, and would squawk when appropriate. Translation issues were frequently ignored. Larry has promised that 80% of Perl 5 programs would be translatable to Perl 6 with 100% compatibility, and 95% with 95% compatibility. Wadr to Larry, those numbers are meaningless at this stage, let alone when he said it. I don't think Hitler was invoked at any point in the discussion. Well, you invoke Hitler when you're talking about people; you invoke Java when you're talking about programming languages. And IIRC, Java was invoked several times. :-) -- John Porter
Re: Critique available
On Thu, Nov 02, 2000 at 11:12:50AM -0500, John Porter wrote: As an RFC author and persistent discutant, I always assumed that all/most/many of such qualified internals folks would be reading the perl6 lists, and would squawk when appropriate. On the whole, driving a spike between language and internals by giving them separate lists was not a good idea. -- Almost any animal is capable learning a stimulus/response association, given enough repetition. Experimental observation suggests that this isn't true if double-clicking is involved. - Lionel, Malcolm Ray, asr.
Re: Critique available
Simon Cozens wrote: On the whole, driving a spike between language and internals by giving them separate lists was not a good idea. Nominally. But how many internals experts actually subscribed to the one and not the other? -- John Porter
Re: Critique available
I agree partly, but not fully. Where I agree is that we did a lousy job in having tighter control by not requiring authors to record the opposing opinions or pointed out deficiencies, not requiring more work on the implementation side, not bestowing more power to the chairs/moderators, and so on. The whole term RFC might have been a bad move. But I certainly don't agree on that the whole process was a fiasco. 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. (On the other hand, we need shark tanks. If an idea wasn't solid enough to survive the p5p ordeal by fire, it probably wasn't solid enough to begin with. In p5p you also ultimately had to have the code to prove your point, re the puny IMPLEMENTATION sections.) Secondly, what was -- and still is -- sorely missing form the p5p process is writing things down, dammit. The first round of the Perl 6 RFCs certainly weren't shining examples of how RFCs should be written, but at least they were written down. Unless an idea is written down, it is close to impossible to discuss it in any serious terms in the email media. Thirdly, to continue on the first point, now we have a record of the kind of things people want. Not perhaps a well-thought out list, quite often suggested in a much too detailed way, trying to shoehorn new un-Perlish ways into Perl, suggesting things that clearly do not belong to a langugage core, breaking backward compatibility, and other evil things. But now we have an idea of the kind of things (both language-wise and application/ata-wise) people want to do in Perl, or don't like about Perl. Based on that feedback we (errr, Larry) can design Perl 6 to be more flexible, to accommodate as many of those requests in some way. Not all of them, and most of them will probably be implemented in some more Perlish way than suggested, and I guess often in some much more lower level way than the RFC submitter thought it should be done. Without the RFC process we wouldn't have had that feedback. I vehemently disagree with the quip that we would have been better off by everybody just sending Larry their suggestions. Now we did have a process: it was public, it was announced, it began, we had rules, we had discussions, it had a definite deadline. We certainly expected (I certainly expected) RFCs of deeper technical level, with more implementation plands or details, or with more background research on existing practices in other languagesor application areas. But obviously our expectations were wrong, and we will have to work what we got. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Critique available
Your critique is related to an issue that I have thought about for a while: what exactly was the RFC process to accomplish. If one views the RFC process as "brainstorming", then the RFC process unfortunately rolled two entirely separate functions, the process of brainstorming and the process of analyzing the results into one difficult and complex process - it is analogous to making a method or a class do too many things. Brainstorming is simply to generate a list of ideas and they can be completely crazy or on the other hand brilliant; ene does not think about implementation issues, prior art issues etc. It is an exercise in creativity - free association - it is even fun. The idea is to do it quickly without a lot of thinking. Thinking comes later! I submit that no matter what the originators of the RFC process originally proposed, the process was implicitly a brainstorming process. I say this because if the entire Perl community could participate then necessarily that means anyone with an idea ought to submit her idea regardless of her technical knowledge. So, implementation issues be damned. Separate mailing lists be damned. Here is a rough outline showing how I would **now** suggest a process for generating ideas for Perl 6. I think points 1), and 2) are the important 1)Brainstorm 2)Discuss the ideas for a brief time to get a sense of how the community feels about the proposed feature. 3)People who are internals and language experts do some initial sorting - the obviously crazy ideas go - those that can't be implemented for technical reasons or those that don't work from experience with other languages etc. Further, ideas such as Mr. Cozens RFC called "Perl should stay Perl" or something like that would stay in some pile. 4)Mr. Wall takes a look at ALL the piles in 3) and does further sorting as he deems necessary into categories. 5)The collective expertise of the World discusses further technical impediments if any remain - implications etc. according to whatever criteria the experts decide are necessary (eg: - backward compatability etc. and also from RFC generated criteria. Note that the ideas/RFCs are in categories which enables an easier discussion format. It is here that issues of implemenation are hashed out - and where neophyte developer wannabees learn something about why X cannot be done or why X is done this way or why X is brilliant. 6)Refine the process further if necessary. 7)Mr. Wall develops the specification 8)Develop testing strategies QA/QC etc 9)Review etc. I agree with Mr. Dominus and Mr. Cozens that the process as implemented was difficult and frustrating. I commend the efforts of Mr. Torkington and others to try to establish a process. I would even go so far as to say that perhaps you all should even consider placing the RFCs aside temporarily and going through a limited application of the first few steps of the above-described process. Then go back and see how many of the RFCs and the more recently generated ideas overlap. A constructive critique that outlines what can be learned about an experience many have shared can be very positive. Finesse, diplomacy, decorum and humility also have their place. It wasn't until I observed the RFC process start to fly apart a bit that I realized there was a flaw. That is, the RFC process, as handled by the managers seemed initially like it would be fine (at least OK) and only from observation did I learn otherwise. (There are probably many who thought that it would not work at all. But perhaps I am atypically humble?) The RFC process was set up to do too much, something I argue that (only?) in hindsight is crystal clear. - Original Message - From: Mark-Jason Dominus [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, November 02, 2000 9:11 AM Subject: Critique available 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
- Original Message - From: "Nathan Torkington" [EMAIL PROTECTED] 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". That may be understating the case. I'm currently working on (with?) a product that relies heavily on perl (5.005), both as a support language and an embedded language. It's not a perfect fit, but it was the best fit at the time. With mixed messages about 5.6, an ultimate migration to 6 which may scare away extended development with perl 5.8, and a indefinite development period on 6 itself, how many people are going to start hedging their bets and investigating other non-perl solutions to their problems? Perl 6, if the general direction of the RFCs hold true, will be a much better fit for this company and their product. Can they wait? *Will* they wait? I know they've already started some migration to Java and Python. I'm all for the truth - nothing worse than a room full of "our shit don't stink" marketers - but let's not scare folks away, either.
Re: Critique available
We threw the floodgates open and a lot of stuff washed in. The overall
odor and consistency of the stuff wasn't that great, and the number of
real gems mixed in was kind of low. 'Nuff said. What's the point in a
purely retrospective analysis? We do need to take the lessons learned,
but only in order to apply them to what's coming next. To put my money
where my mouth is (always a strange image), I'll evaluate the process
along a couple of dimensions:
Generating complaints about the current capabilities of Perl5:
-
We did ok here, but much worse than I'd hoped. Part of the problem is
that many people feel that this was not what the RFCs were for (maybe
correctly, maybe not). So the voices of people with a dislike for what
they have to do in order to accomplish something were lost if they
didn't have a firm idea of how to fix it. Which is too bad, because
that's the most valuable asset to a language redesigner: a clear view of
the scope, magnitude, and nature of all the perceived problems, real and
imaginary. He needn't fix all of them, but knowing them will make it
much easier to firmly ground his solutions, to make sure that they're
alleviating actual user pain and not just twiddling things.
Conclusion: we need to permanently prop the doors open wider for
complaints. The initial RFC process opened them much wider than they'd
been, but we need to be better about eliciting complaints and keeping
track of them. The overhead is too high for most complainants to bother.
To me, this means having another type or status of RFC -- more of a bug
report/feature request, really. You know -- those things that on p5p are
met with "ok, so come up with a solution and implement it so we can
argue over the performance implications of your patch on a CDC-6600."
That, or "if you want Java, you know where to find it."
Generating ideas for new capabilities of Perl6:
---
I think we did well here, though I'm biased by thinking that there's
nothing wrong with the capabilities of Perl5; they just need to be more
accessible. On the other hand, we probably would have gotten 80% of the
benefit from this category even without the RFC process -- Damian
wouldn't sit still, right? :-) To break this category down, I think we
did well on the generation of ideas (though not as well as with a more
focussed forum), ok on figuring out Perlish ways of accomplishing those
ideas, and pretty badly on figuring out how to implement them.
Conclusion: Pat yourselves on the back, and start seriously thinking
about how this is all going to work. ("use Python;" is *hard* to do
right!)
Getting more people usefully involved in perl/Perl development:
--
Unclear. A few new good voices are being heard, but we can't really tell
yet how long anyone will stick around. The number of people who bowed
out of the process in disgust was encouragingly low. :-)
Conclusion: none
Recording complaints, suggestions, and conversations for future
reference:
-
At least an order of magnitude improvement over the status quo, but in
the end, not that well. We have the RFCs, but they don't capture the
conversations all that well (although being able to search the archives
by RFC number is _nice_!). And it's tough to find anything you're
looking for without doing a linear scan through the whole 360.
Conclusion: we still need to work on archiving, filtering, and rating. A
link from an RFC to all spawned threads would help. Community ratings of
RFCs on different dimensions would help (eg feasibility,
interestingness, generality). Having working group chairs or some other
independent person/group attach a note to each RFC might help.
Designing Perl6:
---
The stated goal, no? I'm not too sure about this one. It's an unfair
test, because it's up to Larry, but I was hoping that some aspects of
the design would emerge from the discussion. Not much did, at least not
the sort I'd notice. I was hoping for at least one Grand Unifying Idea
that would pull together disparate pieces of the language and the whole
Perl experience, making it clear what irregularities to discard and what
things can be thought of and done differently and more easily.
Fun:
---
I didn't think the RFC process was much fun. Too much worry and
indecision over what the final goal was. Too time consuming to come up
with an RFC, point out the flaws in responders' spurious arguments,
update the RFC in response to people pointing out the flaws in mine,
etc. There were many things to balance -- premature detail vs too little
discussion of implementation, theory vs practice, And multiple
people complained no matter where you drew the line.
Conclusion: sorry, none.
Reforming the Perl community and processes:
--
Seems like we're
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
I'll make this short. Here is what I see as the root cause of the perl6-* lists errr, hubbub. I think the biggest lesson learned here should be to have more than "days" between the decision to open it to The World, and announcing that it would be opened to The World. It doesn't take a rocket scientist to expect lots and lots o' traffic/interest in such an exciting thing as Perl 6. But "days" left no time to think about/plan how to deal with the expected crushing volume (and varied experience levels) that was sure to be coming. The announcement was made, and within days, the lists were alive. Crushing volume (of poorer than hoped for quality) commenced. Folks were so busy pumping that they didn't have time to stop up the leak itself. Things settled out with about ^ | v That much clearance between the gunnel and the waterline. (with which is gunnel and which is waterline open to debate, it appears :-) Poor planning. Let's not do that again. -- Tad McClellan SGML consulting [EMAIL PROTECTED] Perl programming Fort Worth, Texas
Re: Critique available
On Thu, 2 Nov 2000, Nathan Torkington wrote: 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? To strive for balance, I think perl.com's home page should also have the links to Larry's ALS talk and slides. I know they are not a polished collection of web pages, but they are still quite readable. They also give a different perspective to the RFC collection. An article emphasizing positive aspects of the process so far would also seem like a nice idea, but somebody'd have to write it :-). -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Critique available
On Thu, Nov 02, 2000 at 03:42:41PM -0500, Andy Dougherty wrote: On Thu, 2 Nov 2000, Nathan Torkington wrote: When an article in perl.com is so overwhelmingly negative about the work so far, do Yup. I can't see www.sun.com carrying an editorial saying effectively "Java: we are all going to hell in a handbasket". Well, maybe they are, precisely because of Java, but that's not the point here... you think that stirs confidence in what we're doing? To strive for balance, I think perl.com's home page should also have the links to Larry's ALS talk and slides. I know they are not a polished Definitely. collection of web pages, but they are still quite readable. They also give a different perspective to the RFC collection. An article emphasizing positive aspects of the process so far would also seem like a nice idea, but somebody'd have to write it :-). I think I will try my hand at this. -- Andy Dougherty[EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042 -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Critique available
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. a good choice when you want or expect your project to fail and you are hunting for a way to have someone else to blame for it. Perl is _lousy_ for those tasks. I disagree. The vendor can *always* be blamed. :-) -- John Porter
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.
Re: Critique available
David Grove wrote: Ok, Visual Basic then. Really? Let's see: If [Visual Basic] is well-suited to their needs, as they see those needs, then [migrating to it from perl] is a good thing. Specifically anybody whose needs could be adequately met by [Visual Basic] would certainly be seriously dissatisfied with perl, they're as close to opposite languages as I can think of, in many ways. Nope, not quite the same. -- John Porter
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
