Re: [Boston.pm] Perl 6 has become too complex
On Monday, March 17, 2003 16:32 -0500 Dan Sugalski <[EMAIL PROTECTED]> wrote: At 4:24 PM -0500 3/17/03, [EMAIL PROTECTED] wrote: Just because they're putting something into perl 6 that doesn't help you get your job done, doesn't mean that they're doing it simply for an ego trip. For the record, redesigning an existing product lots of people both love and hate has been about as good for my ego as, say, swimsuit modelling would be. Unless Larry or Damian are closet masochists, I expect it's been about as much of an ego stroke for them, too. -- Woudl now be a good time for all those of us who think you're doing a great job - or at least don't think you're as unto the barbarians sacking Rome - to gather round and stroke your collective egos? I used to be a naysayer until Damian talked about things at YAPC::E and cleared up a lot of misconceptions I had. OK, so I'm not about to become a perl6 fanboy, but I am at least willing to withhold my criticisms until there's something to criticise! And if, once it's out, I decide that perl6 sucks syphilitic donkey nads, I'll still have perl5. Hell, I'll still have perl4 for some things. And awk. -- David Cantrell ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
At 01:29 PM 3/18/2003 -0600, Elaine -HFB- Ashton wrote: And if it's any comfort to you I hear they have a special cousel in an grumpy 80 year-old man :) I feel better already, Thanks. Is it Mel Brooks or Carl Reiner? I think I'll have a nectarine ... Charlie ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
RE: [Boston.pm] Perl 6 has become too complex
OK, I'll bite. Who? > -Original Message- > From: Elaine -HFB- Ashton [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 18, 2003 2:30 PM ... > And if it's any comfort to you I hear they have a special cousel in an > grumpy 80 year-old man :) Hopefully helpfully yours, Steve -- Steven Tolkin [EMAIL PROTECTED] 617-563-0516 Fidelity Investments 82 Devonshire St. V4D Boston MA 02109 There is nothing so practical as a good theory. Comments are by me, not Fidelity Investments, its subsidiaries or affiliates. ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
Charles Reitzel [EMAIL PROTECTED] quoth: *> *>Due to it's single implementation, Perl should be spared the worst. But, *>for that same reason, the advanced features could well weigh down the *>language as a whole in both interpretation and execution speed. Perl 4 people said the same thing many moons ago :) *>Complexity is easy. Simplicity is damned difficult. I know and trust that *>the Perl language designers and developers all know this fact very *>well. But it doesn't hurt to remind them sometimes. My guess is that the *>kind of nattering that bothers you so much is exactly why Larry _does_ *>publish the "Apocalypsos". That, and he probably is sincere in his desire *>for a transparent process. Reminding them is one thing but I've watched the years of people 'reminding' them take their toll and it impedes progress. I'd like to see something I can work with before getting my panties in a twist as beta-testing an idea is hard and tends to add complexity rather than winnow out the bugs and fluff. It is the perl motto that 'no good deed shall go unpunished' that bothers me, not the process, as many seem to forget that much of it is unhelpful and does nothing for the morale of those who are far, far more masochistic than is really healthy. :) And if it's any comfort to you I hear they have a special cousel in an grumpy 80 year-old man :) e. ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
At 01:03 AM 3/18/2003 -0600, Elaine -HFB- Ashton wrote: Joe Johnston [EMAIL PROTECTED] quoth: *> *>Do you trust Larry and Damain? I wish they'd just stop circulating the Apocs so widely as every time Larry emits one there is a rash of people who think the world has needed to know or cares that it's not what they wanted or needed to use. It's the typical egocentric universe that tends to plague us even now in the dot.bomb. It's less about trust than of wanking. I hope that you are right. But, if the history of C++ is any guide, it is better to holler early and often in favor of simplicity. The C++ committee clearly suffered what I call "rapture of the deep" and foisted many complex and not particularly useful features on an unwitting C++ community. The result: there are almost no conforming compilers available. Sophisticated features are still best avoided due to portability problems. The C++ committee has, in fact, done a lot to deprecate C++ use and bring about a renaissance, of sorts, in C development. I am not making this up. Due to it's single implementation, Perl should be spared the worst. But, for that same reason, the advanced features could well weigh down the language as a whole in both interpretation and execution speed. Reliability is also an important issue. Perl is used in a great many production systems. Perl is already a bit crufty in the sense that there are many "accidental features". If the degrees-of-freedom supported by the language grows significantly, you can bet there will be many new and interesting side effects that will appear in the language. This may be a good thing, depending on your POV. But, to me, it is a source of fragility, both in the language itself and in programs written in it. Complexity is easy. Simplicity is damned difficult. I know and trust that the Perl language designers and developers all know this fact very well. But it doesn't hurt to remind them sometimes. My guess is that the kind of nattering that bothers you so much is exactly why Larry _does_ publish the "Apocalypsos". That, and he probably is sincere in his desire for a transparent process. take it easy, Charlie ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
Dan Sugalski wrote: > > At 10:30 AM -0500 3/18/03, [EMAIL PROTECTED] wrote: > >Erik Price wrote: > >> linguistic scholars have noticed that > >> throughout human history, there has > >> always been a trend of languages > >> diverging, rather than converging > > > >awk, sed, and a mish-mash of useful > >functionality converging into Perl > >would be a counter-example. > > While computer and human languages share many traits, > they aren't the same thing by any means. they (computer and human languages) are considered fairly equally in the eyes of the law. both allow expressions that qualify for copyright protection. They are different in that while a human expression can only describe patentable functionality, a computer program can both describe and implement the functionality. Human languages can give purely functional expressions too. Food recipes can't be copyrighted because they're considered purely functional. (You can copyright a cookbook if you put in cutesy little stories that go with the recipes.) But it takes a human to parse, compile, and execute the recipe "program". Generally, the argument used to defend software cracks is that code is protected by freedom of speech, whereas execution of said code to spread a computer virus is illegal. This is the same argument that protects the Anarchist's Cookbook as freedom of speech, separating the difference between expressing knowledge about a topic and using that knowledge to perform illegal acts. Greg ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
At 10:30 AM -0500 3/18/03, [EMAIL PROTECTED] wrote: Erik Price wrote: linguistic scholars have noticed that throughout human history, there has always been a trend of languages diverging, rather than converging awk, sed, and a mish-mash of useful functionality converging into Perl would be a counter-example. I don't know that it's safe to make that counter-example. While computer and human languages share many traits, they aren't the same thing by any means. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
Erik Price wrote: > linguistic scholars have noticed that > throughout human history, there has > always been a trend of languages > diverging, rather than converging awk, sed, and a mish-mash of useful functionality converging into Perl would be a counter-example. The fear seems to be that Perl 6 will FORK from Perl 5 (diverge). I think that Perl 6 will EXPAND perl 5. Sure, you'll have to learn some new syntactical stuff, but Perl 5 will only have a subset of the functionality that will be in perl 6. Greg I hate war as only a soldier who has lived it can, only as one who has seen its brutality, its futility, its stupidity. -- Dwight D. Eisenhower ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
Erik Price [EMAIL PROTECTED] quoth: *> *>I'm not a linguistic scholar, but I read once that linguistic scholars *>have noticed that throughout human history, there has always been a *>trend of languages diverging, rather than converging (as one might *>expect). As the amount of widespread-edness* of a language grows, the *>more likely that subgroups using the language are to evolve with their *>own dialects of that language, separating from the main "trunk" as it *>were. I wonder sometimes about the grammars that people use to write *>software and how closely or not so closely it relates. I'm merely an armchair linguist and enthusiast but my point was as far from the technical as you can get without coming back round the backside. Imagine yourself arriving somewhere your native language and any other language you may speak/read with any efficiency are mostly, if not completely, useless. Convergence, divergence, liguistic highbrow are of little use in this context as your goal is to communicate not to compare. Finnish is radically different than the I-E family of languages so until you know both of them comparison is simply not possible. Neither English nor Finnish were consciously designed by one or more people looking for the most efficient method of communicating meaning which can be seen as a bug or a feature depending on your perspective. Yet in spite of their complexity millions of people use and change the languages daily. People spend far too much angst on comparing perl5 to what is emerging in the perl6 apocalypses as it isn't very productive to find meaning in one language by looking through another especially when the new language has yet to be in use. Finnish has no gender, no future tense, no articles, and a host of locative cases and postpositions which make translation a source of frustration as communicating something in Finnish is quite a different construct than its English equivalent. When you accept rather than compare it becomes far easier to see the logic and get on with it. P6 is circumventing the slower method of natural change in language but, look on the bright side, it's not going to be Finnish :) As far as human and computer language grammars go you should read Larry's natural language bits; http://www.wall.org/~larry/natural.html and http://www.techgnosis.com/wall1.html e. ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
On Tuesday, March 18, 2003, at 02:03 AM, Elaine -HFB- Ashton wrote: 400 hundred years ago Agricola codified Finnish yet today there are more than 80 dialects not to mention the huge variation between the written and spoken forms. I'm not a linguistic scholar, but I read once that linguistic scholars have noticed that throughout human history, there has always been a trend of languages diverging, rather than converging (as one might expect). As the amount of widespread-edness* of a language grows, the more likely that subgroups using the language are to evolve with their own dialects of that language, separating from the main "trunk" as it were. I wonder sometimes about the grammars that people use to write software and how closely or not so closely it relates. * case in point Erik -- Erik Price email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
Joe Johnston [EMAIL PROTECTED] quoth: *> *>Do you trust Larry and Damain? I wish they'd just stop circulating the Apocs so widely as every time Larry emits one there is a rash of people who think the world has needed to know or cares that it's not what they wanted or needed to use. It's the typical egocentric universe that tends to plague us even now in the dot.bomb. It's less about trust than of wanking. 400 hundred years ago Agricola codified Finnish yet today there are more than 80 dialects not to mention the huge variation between the written and spoken forms. The consonant gradation makes words look unrecognisable from one case to the next and "K" is sublime which, if Finnish ever makes it to redesign, I'm going to suggest the entire language be done using more "K" and be renameed to "lang". I think of Larry often in my Finnish class as it tells me that noone could have possibly designed this language intentionally but it gets a lot of use, much more than English over here, and that tagmemics has a lot less validity when you're sitting in a class trying to learn vocabulary and grammar from a woman waving her arms around and saying a stream of sounds which have utterly no meaning at all, not the slightest. e. ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
Dear Dan, Be of good cheer. If you build it, they will come. > been about as good for my ego as, say, swimsuit > modelling would be. Most everyone would agree we'd rather see Dan (or Damian or even Larry) in a swimsuit than Uri (unless there is a bullseye near the bench he's preched on; how much for 3 pitches?). > Unless Larry or Damian are closet masochists, I > expect it's been about as much of an ego stroke for them, too. "They say? What say they? Let them say." -- Olde Scots motto. The ubuiquitous "they" said Perl 5 would fail too. The stream of critiquies of the Apocalypse before the Exegisis is amusing. Folks who have no use for academic featuers are engaging in academic masturbation buy criticising the design documents. The Apocalypsos are the design spec for the implementors, the Exegesexen are the preview of the 6-legged Camel books for the rest of us. Lighten up guys, let's see what Damian makes of it. If Perl 6 will run my Perl5 scripts faster with no change (or a simple conversions), will I switch? In a minute. Will I adopt the new features? Some of them quickly, some more slowly ... same as Perl 5. == Bill [EMAIL PROTECTED] / n1vux ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
At 16:30 -0500 2003.03.17, Joe Johnston wrote: >I rather wish this entire Boston.pm thread had been devoted to the >last episdoe of Farscape showing this Friday on SciFi. Farscape's >untimely cancellation is indeed worthy of lamentation and tears. Dude, I am sitting on pins and needles over it! Not because I am nervous or anything, but because that seems like the sort of thing that is appropriate for Farscape. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/ ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
At 4:24 PM -0500 3/17/03, [EMAIL PROTECTED] wrote: Mikey Smelto wrote: "I use a computer to accomplish tasks, > not to accomplish using the computer." Just because they're putting something into perl 6 that doesn't help you get your job done, doesn't mean that they're doing it simply for an ego trip. For the record, redesigning an existing product lots of people both love and hate has been about as good for my ego as, say, swimsuit modelling would be. Unless Larry or Damian are closet masochists, I expect it's been about as much of an ego stroke for them, too. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
* Mikey Smelto <[EMAIL PROTECTED]> [03-03-17 15:59]: > > "I stopped caring about perl 6 because I use a computer to accomplish > tasks, not to accomplish using the computer." Giddy with having just filed my taxes, I'd like to add a little something to this worried discussion about Perl 6 and the Dreaded Second System Sydrome. Do you trust Larry and Damain? There's lots of hard evidence to suggest that these guys 'n' gals (and the rest of the Perl 6 Simpaticos) will Do The Right Thing. I've read the Apocalypses and skimed the Exegeseseseses (or something), but I regard these documents as poetry of a more technical bent. In others, something very close to fiction. The time to worry is when the *code* for Perl 6 ships. If Perl 6 becomes Java with dollar signs, then I suspect it will fail. It won't be the end of the world if Perl 6 becomes tomorrow's Ada, because then we know what *not* to do for Perl 7. As the N.A.N.D.O.R. pointed out, no one is erasing Perl 5 from your non-volitile storage devices. Observe that the Linux Router Project has a package for Perl 4! Morbidly, I want to close by noting that "language-specific" communities grow and shrink like living organisms (not too surprising given their composition). Is this the twilight of Perl? Who can say so with authority? I'm still making money with Perl. Perl still pulls my butt out of the fire every day. However, if the day comes that I can't do what I need to with Perl, there will be other tools available. I rather wish this entire Boston.pm thread had been devoted to the last episdoe of Farscape showing this Friday on SciFi. Farscape's untimely cancellation is indeed worthy of lamentation and tears. Perl 6 will be fine. Just fine. ;-) -- Joe Johnston -- http://taskboy.com Software Consultant: Web - Database - Perl "...our power is in argument and persuasion." --Chinua Achebe ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
Mikey Smelto wrote: > "I use a computer to accomplish tasks, > not to accomplish using the computer." I get your point, but you're using perl. USING perl is about getting your job done. DESIGNING perl is about getting everyone's job done. Just because they're putting something into perl 6 that doesn't help you get your job done, doesn't mean that they're doing it simply for an ego trip. Greg ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
At 8:54 PM + 3/17/03, Mikey Smelto wrote: I don't know if I can agree with that statement. As I paraphrase an anonymous co-worker at an anonymous workplace. "I stopped caring about perl 6 because I use a computer to accomplish tasks, not to accomplish using the computer." Good grief, the amount of handwringing over the impending "Perl 6 Cataclysm" is pretty phenomenal. For an awful lot of tasks, the only difference between perl 5 and perl 6 is you write: @foo[12] instead of $foo[12] and you may throw a use re qw(perl5); at the top of your program. I mean, come *on* people, we're not stupid. Yeah, the wacky modules that intercept method dispatch to inspect the caller's context and do delegated multimethod dispatch quantumly across multiple threads simultaneously may change, but how many people write stuff like that? I sure don't. The second biggest difference is you might write: sub foo ($bar, $baz) { } instead of sub foo { my ($bar, $baz) = @_; } But it's not like *that* is a bad thing either. perl 6 will be more complex than perl 5, but I think the philosophy is still the same, "perl is for getting your job done". I don't think anything's getting added unless it'll make it easier for someone to get their job done. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
I don't know if I can agree with that statement. As I paraphrase an anonymous co-worker at an anonymous workplace. "I stopped caring about perl 6 because I use a computer to accomplish tasks, not to accomplish using the computer." perl 6 will be more complex than perl 5, but I think the philosophy is still the same, "perl is for getting your job done". I don't think anything's getting added unless it'll make it easier for someone to get their job done. _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
> Apocalyse 6 included almost > 30 pages discussing the new ==> > and <== operators! This is not a good sign. The apocalypses read like the tome of an advanced wizard making notes for himself in preparation for casting some earth-altering spell. And ya know, that's kind of what it is... But I assume that there will be room for apprentice wizards of varying degrees of skill to traffic in the tools of Perl 6 and get stuff done. *>I learned Perl 4 from its man page -- yes there *>was one long man page that completely described the entire language. Great, you read the man page, and you became a level 4 perl apprentice. Have you learned anything since reading that man page? Are you using perl 5? could you put everything you know about perl 5 into an equally sized man page document? perl 6 will be more complex than perl 5, but I think the philosophy is still the same, "perl is for getting your job done". I don't think anything's getting added unless it'll make it easier for someone to get their job done. It's just that some people need threads, types, class contracts, and multimethods to get their job done. Greg ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
I would like to take this chance to also mention that Steve posted a similar discussion node on the Perl Monks website, and I mentioned this thread to TheDamian, and he asked that I post the link to that thread. http://www.perlmonks.org/index.pl?node_id=243089 Thomas Stanley aka TStanley on PerlMonks - Original Message - From: Elaine -HFB- Ashton Sent: Saturday, March 15, 2003 2:23 AM To: Tolkin, Steve Cc: [EMAIL PROTECTED] Subject: Re: [Boston.pm] Perl 6 has become too complex Tolkin, Steve [EMAIL PROTECTED] quoth:*>I think I am in the same camp as Chris Nandor and John Tobey.*>They, and I, have just given up on Perl 6.*>*>But there is a problem in staying with Perl 5.*>Due to Perl 6 the Perl 5 community is deprived of the *>resources of several key people, e.g. Larry, and also "Good Damian".My problem with perl6 is several more years of having to endure hearingpeople grump about that which does not exist. I feel badly for thoseseveral key people, as you call them, as it seems like freaks just can'tresist the urge to voice discontent. You are all like children who cry atchristmastime because santa brought something you didn't ask for. *>The original design of perl was simple. *>I learned Perl 4 from its man page -- yes there*>was one long man page that completely described the entire language. *>Apocalyse 6 included almost 30 pages discussing the new ==>*>and <== operators! This is not a good sign.I don't think perl5 is going anywhere Steve, so get your pants out of atwist. I have it on very good authority that p6 was the best thing thatever happened to p5p as it drew the whiners and the talkers all over tothe p6 lists leaving the doers to get down to business. P6 may never cometo fruition but for that one particular benefit I am particularlygrateful as it made Jarkko's job much much easier.I will suggest you read "The Power of Babel" as it's an excellent story onthe development of language which you may or may not appreciate in thiscontext.e.___Boston-pm mailing list[EMAIL PROTECTED]http://mail.pm.org/mailman/listinfo/boston-pmGet more from the Web. FREE MSN Explorer download : http://explorer.msn.com
Re: [Boston.pm] Perl 6 has become too complex
On Sat, Mar 15, 2003 at 10:53:53AM -0500, Andrew Pimlott wrote: > On Fri, Mar 14, 2003 at 09:59:42PM -0500, Uri Guttman wrote: > > well, this is what will be supported which is named nested subs. > > it looks to be compiled but callable only from within the outer sub and > > it has access to the outer subs vars. > > > > my $c; > > sub foo() { > > my $a; > > my $b; > > > > my sub bar() { > > $b = $a + $c; > > } > > > > bar(); > > } > > > > is that close enough? > > I think it's absolutely fine, assuming that &bar is a real closure > that can be returned or passed to other functions. I think nested > subs should default to "my", since there's no other point in using > them, but if Larry likes the "my", it can stay. I agree with your preference, but I wish it worked without the "my". See Apache::Registry. (I hope that's the one I mean.) It packages a whole CGI script in a sub by textually inserting it in "sub {" "}". This trick would be quite useful if not for the "will not stay shared" issue, aka the "all named subs are global" problem. See Scheme do it right: http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-8.html#%_sec_5.2.2 Personally, I would never intentionally write a nested sub in current versions of Perl. Apart from having global subs pasted into an outer block by something like Apache::Registry, what good does the current nested sub feature do? Of course, some code somewhere relies on them being global, but not Apache::Registry, which I believe also pastes a generated package declaration around its scripts in order to defeat the global-ness. Share and share alike! :~) -- John Tobey <[EMAIL PROTECTED]> \^-^ /\ /\ ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
On Sat, Mar 15, 2003 at 12:19:18PM -0500, Uri Guttman wrote: > > "AP" == Andrew Pimlott <[EMAIL PROTECTED]> writes: > > AP> On Fri, Mar 14, 2003 at 09:59:42PM -0500, Uri Guttman wrote: > >> > >> my $c; > >> sub foo() { > >> my $a; > >> my $b; > >> > >> my sub bar() { > >> $b = $a + $c; > >> } > >> > >> bar(); > >> } > >> > >> is that close enough? > > AP> I think it's absolutely fine, assuming that &bar is a real closure > AP> that can be returned or passed to other functions. I think nested > AP> subs should default to "my", since there's no other point in using > AP> them, but if Larry likes the "my", it can stay. > > i don't see why you would want to return a named closure when you can > return an anon one. Well, why not? What if I want to call it and return/pass it? I guess that's not all that common, though. > the implication (to me) of a named one is that it > can be called inside foo() directly and it has access to foo() variables > on the stack. those vars are not copied to a private pad for bar() like > a anon closure would do. they are different animals IMO. Suppose I do return/pass it, what will it do? It has to have some behavior, and the only alternatives I see to closure are utterly confusing and error-prone. If perl6diag contains the text "will not stay shared", I will be quite sad. The very idea of "two kinds of closure" seems confusing. If you are worried about efficiency, there is a simple optimization: If no reference is ever taken to the named lexical sub, it doesn't need it's own copy of the pad. > AP> ... well, just to be sure, here are a couple test cases: > > AP> my foo() { > AP> my sub helper1() { ... helper2() ... $a ...} > AP> my sub helper2() { ... helper1() ... $a ...} > AP> my $a; > AP> helper1(); > AP> } > > AP> helper1 and helper2 should be mutually recursive and enclose $a, ie > AP> when compiling helper1 it shouldn't bind helper2() and $a to > AP> whatever's in the outer/global scope. > > you don't return a sub there rather you made a call to it. so it is not > the same as p5 closures. that should work fine but it doesn't need pads > and local copies of $a in helper1/2(). ok. > also that can be done with a plain block surrounding two subs. no need for > nesting subs there. show me a case where you need named nesting subs and > you return one of them to the outside. > > AP> my foo() { > AP> ... helper() ... > AP> my $a; > AP> my sub helper { ... $a ... } > AP> } > > AP> The call to helper() should work and $a should be enclosed (of > AP> course, it will be undef when helper() is called, but helper can set > AP> it). It's often nice to put the helpers at the end--and note that > AP> this cannot be achieved with the Perl 5 glob trick. > > this is a compiler issue as to whether it can handle foward > references. if you declared helper with a signature first (of course > inside foo()), it would work for sure. i am not sure otherwise. Right. I just think that since Perl can normally handle forward references, it should be able to do so in this case. > my point is that nested named subs are supported but they are not the > same as anon closures returned from an outer sub. but who knows what > larry would want there. i will ask on p6l. Thanks. Andrew ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
> "AP" == Andrew Pimlott <[EMAIL PROTECTED]> writes: AP> On Fri, Mar 14, 2003 at 09:59:42PM -0500, Uri Guttman wrote: >> >> my $c; >> sub foo() { >> my $a; >> my $b; >> >> my sub bar() { >> $b = $a + $c; >> } >> >> bar(); >> } >> >> is that close enough? AP> I think it's absolutely fine, assuming that &bar is a real closure AP> that can be returned or passed to other functions. I think nested AP> subs should default to "my", since there's no other point in using AP> them, but if Larry likes the "my", it can stay. i don't see why you would want to return a named closure when you can return an anon one. the implication (to me) of a named one is that it can be called inside foo() directly and it has access to foo() variables on the stack. those vars are not copied to a private pad for bar() like a anon closure would do. they are different animals IMO. AP> ... well, just to be sure, here are a couple test cases: AP> my foo() { AP> my sub helper1() { ... helper2() ... $a ...} AP> my sub helper2() { ... helper1() ... $a ...} AP> my $a; AP> helper1(); AP> } AP> helper1 and helper2 should be mutually recursive and enclose $a, ie AP> when compiling helper1 it shouldn't bind helper2() and $a to AP> whatever's in the outer/global scope. you don't return a sub there rather you made a call to it. so it is not the same as p5 closures. that should work fine but it doesn't need pads and local copies of $a in helper1/2(). also that can be done with a plain block surrounding two subs. no need for nesting subs there. show me a case where you need named nesting subs and you return one of them to the outside. AP> my foo() { AP> ... helper() ... AP> my $a; AP> my sub helper { ... $a ... } AP> } AP> The call to helper() should work and $a should be enclosed (of AP> course, it will be undef when helper() is called, but helper can set AP> it). It's often nice to put the helpers at the end--and note that AP> this cannot be achieved with the Perl 5 glob trick. this is a compiler issue as to whether it can handle foward references. if you declared helper with a signature first (of course inside foo()), it would work for sure. i am not sure otherwise. my point is that nested named subs are supported but they are not the same as anon closures returned from an outer sub. but who knows what larry would want there. i will ask on p6l. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
RE: [Boston.pm] Perl 6 has become too complex
At 11:53 -0500 2003.03.15, Wizard wrote: >I don't view it as a problem, and I didn't mean to imply that I thought >Perl5 would be any sort of second-string language, only that it may very >well become relegated to tasks other than a production language. OK, you and I must have very different definitions of "second-string language," because you appear to have defined it as exactly that. Either way, its adherents will not see it as you describe, and asserting views like this will only serve to damage the community. Keep it up if you will. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/ ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
RE: [Boston.pm] Perl 6 has become too complex
> This somewhat misses my point. The lack of migration of many users should > not be viewed as a problem, necessarily, but as a difference of opinion, a > choice. The widespread view that people who stick with Perl 5 will be > sticking with an old, crufty, slow, backward, legacy language is the very > sort of thing that will help to ruin the Perl community. I don't view it as a problem, and I didn't mean to imply that I thought Perl5 would be any sort of second-string language, only that it may very well become relegated to tasks other than a production language. This might be along the same lines as C in comparison to C++. I still use C and suspect that I will still use Perl5. I also use much of the supported C 'subset' when using C++, and suspect that the same will hold true of the Perl5 'subset' (Yes, I know that neither is truly a subset, but for lack of a better term). Grant M. ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
On Fri, Mar 14, 2003 at 09:59:42PM -0500, Uri Guttman wrote: > well, this is what will be supported which is named nested subs. > it looks to be compiled but callable only from within the outer sub and > it has access to the outer subs vars. > > my $c; > sub foo() { > my $a; > my $b; > > my sub bar() { > $b = $a + $c; > } > > bar(); > } > > is that close enough? I think it's absolutely fine, assuming that &bar is a real closure that can be returned or passed to other functions. I think nested subs should default to "my", since there's no other point in using them, but if Larry likes the "my", it can stay. A6 implied to me that this would not be the case, because it only used the word "closure" in connection with anonymous subs. But if you can assure me that the above will work, I can sleep peacefully. ... well, just to be sure, here are a couple test cases: my foo() { my sub helper1() { ... helper2() ... $a ...} my sub helper2() { ... helper1() ... $a ...} my $a; helper1(); } helper1 and helper2 should be mutually recursive and enclose $a, ie when compiling helper1 it shouldn't bind helper2() and $a to whatever's in the outer/global scope. my foo() { ... helper() ... my $a; my sub helper { ... $a ... } } The call to helper() should work and $a should be enclosed (of course, it will be undef when helper() is called, but helper can set it). It's often nice to put the helpers at the end--and note that this cannot be achieved with the Perl 5 glob trick. Andrew ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
RE: [Boston.pm] Perl 6 has become too complex
At 08:35 -0500 2003.03.15, Wizard wrote: >This is a similar problem to what Apache2 has had. Apache2 is definitely a >superior product, but is so different from 1 that the adoption rate has been >somewhat slow. What the Perl6 developers need to do is to make sure that the >migration is as simple as possible, with tools, tutorials and hand-holding. >Like any other new product, it has to be sold. Just remember, there are >still large numbers of entities still happily using Cobol (a legacy language >when I was a lad in the early 80s ;-). This somewhat misses my point. The lack of migration of many users should not be viewed as a problem, necessarily, but as a difference of opinion, a choice. The widespread view that people who stick with Perl 5 will be sticking with an old, crufty, slow, backward, legacy language is the very sort of thing that will help to ruin the Perl community. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/ ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
On Saturday, March 15, 2003, at 10:11 AM, Mikey Smelto wrote: You forgot to mention that we will all have to deal with suggesting perl5 to project managers/decision makers(read: people who don't understand anything) as a language of choice for projects of the future, and explain to them why we don't want to use the newest version of the language, and having the perl5 solution rejected because the company doesn't want to use old||legacy||non-cutting-edge software going forward. Hm. I think this can't be generalized upon. Where I work, they are still using Perl 5.005 on the production servers (for our internal site) Erik -- Erik Price email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
You forgot to mention that we will all have to deal with suggesting perl5 to project managers/decision makers(read: people who don't understand anything) as a language of choice for projects of the future, and explain to them why we don't want to use the newest version of the language, and having the perl5 solution rejected because the company doesn't want to use old||legacy||non-cutting-edge software going forward. My only real concern is that when Perl 6 comes out, the community will be fractured, and we -- you, me, Larry, Damian -- will need to work to minimize the damage, for the benefit of Perl 5 and Perl 6 users. We will need to deal with CPAN/PAUSE/RT/search, we will need to deal with IRC and PerlMonks and use Perl; we will need to deal with Usenet; we will need to deal with TPJ and TPR and YAPC and TPC and Perl Mongers. I see the users of both -- and make no mistake, Perl 5 will retain a large user base for a long time, composed of people who have no intention of using Perl 6 -- only being harmed by significant fracturing of the "Perl community." _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
RE: [Boston.pm] Perl 6 has become too complex
> My only real concern is that when Perl 6 comes out, the community will be > fractured, and we -- you, me, Larry, Damian -- will need to work to > minimize the damage, for the benefit of Perl 5 and Perl 6 users. We will > need to deal with CPAN/PAUSE/RT/search, we will need to deal with IRC and > PerlMonks and use Perl; we will need to deal with Usenet; we will need to > deal with TPJ and TPR and YAPC and TPC and Perl Mongers. I see the users > of both -- and make no mistake, Perl 5 will retain a large user base for a > long time, composed of people who have no intention of using Perl > 6 -- only > being harmed by significant fracturing of the "Perl community." This is a similar problem to what Apache2 has had. Apache2 is definitely a superior product, but is so different from 1 that the adoption rate has been somewhat slow. What the Perl6 developers need to do is to make sure that the migration is as simple as possible, with tools, tutorials and hand-holding. Like any other new product, it has to be sold. Just remember, there are still large numbers of entities still happily using Cobol (a legacy language when I was a lad in the early 80s ;-). Grant M. ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
At 18:36 -0500 2003.03.14, Andrew Pimlott wrote: >On Fri, Mar 14, 2003 at 06:00:59PM -0500, Tolkin, Steve wrote: >> I think I am in the same camp as Chris Nandor and John Tobey. >> They, and I, have just given up on Perl 6. > >I would say don't give up. Unless you need it within the next >couple years, in which case, ok, give up. But if you're thinking >long term, have some faith in Larry, Damian, and the other guys who >are smart, creative, and apparently working together really well >together (unusual in Perl's history!). I would agree in that I would not say I have given up; I have merely stopped caring. I reserve the right to care again some day, but I lack optimism. And since I hate being pessimistic, rather than optimistic, I choose to note care, instead. :) Also, despite my distaste for much of what is being said about what Perl 6 will be, I do not wish to discourage anyone else, including and especially the people designing it, and those who wish to help them. I only say I have distaste for it to encourage those who feel similarly, to let them know it is OK to not like it. But really, Elaine is right IMO: dislike it if you wish -- Larry is certainly mature and smart enough to know that people have preferences and that all the Perl users won't like Perl 6 by default! -- but don't gripe. At the very least, realize that if you love Perl 5, it isn't going away. It might lose Larry and Damian, but honestly, Larry has not not done a lot for the design or maintenance of the Perl 5 language in years, and Damian -- while making cool stuff -- contributed more in his ideas than in any other way, and those ideas will still be coming, I guarantee, only to be implemented in Perl 5 for those who want it. That is to say, I am influenced more by Damian's ideas than I use his actual code. Yes, Perl 5 has and will lose people. But it also has a lot of good people that it won't likely lose, and it will probably gain more "key" people as others step up to the plate. I am not trying to dismiss all the other "key" people like Larry and Damian have done, but just trying to keep things in perspective. My only real concern is that when Perl 6 comes out, the community will be fractured, and we -- you, me, Larry, Damian -- will need to work to minimize the damage, for the benefit of Perl 5 and Perl 6 users. We will need to deal with CPAN/PAUSE/RT/search, we will need to deal with IRC and PerlMonks and use Perl; we will need to deal with Usenet; we will need to deal with TPJ and TPR and YAPC and TPC and Perl Mongers. I see the users of both -- and make no mistake, Perl 5 will retain a large user base for a long time, composed of people who have no intention of using Perl 6 -- only being harmed by significant fracturing of the "Perl community." But, that is some time off, so I won't dwell on it; I just like to point this problem out so people can think about it a bit now, to try to lessen the problem later. Prophecy is not meant to make people panic, but to help them see the future signs that they might respond more appropriately, with a greater sense of understanding, when the time comes. ;-) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/ ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
Tolkin, Steve [EMAIL PROTECTED] quoth: *>I think I am in the same camp as Chris Nandor and John Tobey. *>They, and I, have just given up on Perl 6. *> *>But there is a problem in staying with Perl 5. *>Due to Perl 6 the Perl 5 community is deprived of the *>resources of several key people, e.g. Larry, and also "Good Damian". My problem with perl6 is several more years of having to endure hearing people grump about that which does not exist. I feel badly for those several key people, as you call them, as it seems like freaks just can't resist the urge to voice discontent. You are all like children who cry at christmastime because santa brought something you didn't ask for. *>The original design of perl was simple. *>I learned Perl 4 from its man page -- yes there *>was one long man page that completely described the entire language. *>Apocalyse 6 included almost 30 pages discussing the new ==> *>and <== operators! This is not a good sign. I don't think perl5 is going anywhere Steve, so get your pants out of a twist. I have it on very good authority that p6 was the best thing that ever happened to p5p as it drew the whiners and the talkers all over to the p6 lists leaving the doers to get down to business. P6 may never come to fruition but for that one particular benefit I am particularly grateful as it made Jarkko's job much much easier. I will suggest you read "The Power of Babel" as it's an excellent story on the development of language which you may or may not appreciate in this context. e. ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
On Friday, March 14, 2003, at 09:59 PM, Uri Guttman wrote: well, this is what will be supported which is named nested subs. Why not make all named nested subs 'my'? Is there any valid reason to have a non-'my' (that is, globally scoped) nested sub? ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
> "JT" == John Tobey <[EMAIL PROTECTED]> writes: JT> On Fri, Mar 14, 2003 at 03:49:21PM -0500, Dan Sugalski wrote: >> At 10:14 AM -0500 3/14/03, Andrew Pimlott wrote: >> > >> >A6 says that, as in Perl 5, only anonymous subs are closures. I've >> >always thought of the fact that Perl 5 named subs are not closures >> >as a bug kept for compatibility. >> >> Well... there's always the issue that closures are done by >> instantiating the sub at runtime, while named subs are instantiated >> at compile time, which causes some difficulties. (As the enclosing >> sub's lexicals instantiate at runtime, thus giving the contained sub >> nothing to close over) >> >> Now, if the named lexically scoped sub actually got re-instantiated >> every time, *that* would be different. JT> YES. That's what we want. That is how Scheme and Common Lisp work. JT> That would make for cleaner code. well, this is what will be supported which is named nested subs. it looks to be compiled but callable only from within the outer sub and it has access to the outer subs vars. my $c; sub foo() { my $a; my $b; my sub bar() { $b = $a + $c; } bar(); } is that close enough? uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
Since I appear to have contributed to the problem ... :-) On Fri, Mar 14, 2003 at 06:00:59PM -0500, Tolkin, Steve wrote: > I think I am in the same camp as Chris Nandor and John Tobey. > They, and I, have just given up on Perl 6. I would say don't give up. Unless you need it within the next couple years, in which case, ok, give up. But if you're thinking long term, have some faith in Larry, Damian, and the other guys who are smart, creative, and apparently working together really well together (unusual in Perl's history!). Yes, Perl 6 will be enormous. But the new ideas have come from (at least) dozens of minds and hundreds of man-years' experience with Perl; they have been scrutinized and discussed in public; they are being carefully weighed and assimilated by a proven language designer; and they will be implemented by top-notch hackers like Dan. I'm not guaranteeing that Perl 6 won't be a second-system flop, but I give it good odds. Don't forget, each Apocalypse seems less daunting and more appealing after the accompanying Exigesis, so at least wait for Damian to chime in and balance things out! > I think it is telling that most of the responses to my email > are a technical discussion, e.g. how to make Perl more > like Scheme. But Scheme, while elegant, is still > a "boutique" langue whereas Perl is widely used. Perl has picked up lots of ideas from lots of languages. Where do you think closures came from in the first place? Probably also the general list-orientation. And the fact that this thread has zoned in on Scheme doesn't mean that Larry is focused in this direction. I haven't seen any evidence of that at all. He's incorporating a staggering number of new concepts, but he seems to be getting them from all corners of the universe. > As we know, when Larry designed Perl he took the best parts > of awk, VC, sh, etc., plus added a few excellent new ideas, > and produced a language that was a mixture -- but a mix > based on features that had been proven to be good. > > In contrast Perl 6 is a mixture of a variety of theoretically > desireable features, e.g. multimethods, functional programming, > logic programming, aspect oriented programming, > design by contract, etc. that have not been proven in > widely used languages. I would say that (most of) these ideas are more widely used and proven--in some circle--than you give them credit for. Also, I wasn't around for the early evolution of Perl either, but bet some of Perl's features were similarly "academic" to the Perl community when they were introduced. Frankly, I commend Larry for his effort to pull them into a popular, approachable language. Maybe I have an ax to grind (functional programming not proven!?), so don't listen to me; but Larry doesn't--that's one of his most remarkable features--and I think he may still have a few gems to give us. Andrew ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
RE: [Boston.pm] Perl 6 has become too complex
First, I have to (sheepishly) stand up on the side of Perl6 (ok, so maybe one foot is across the line). I like the fact that perl6-language is at least making an effort to fix the things that we don't like in Perl5. There are things in it that concern me some, but I can't try it so I don't know if I should be concerned. I believe that one of the first Apocalypses did state something to the effect that some of the things in Perl5 would get broken, but that there would be a defined migration path. There shouldn't be any surprises here. I also have been very impressed with Parrot (although I haven't seen it recently). Second, I personally would like to see a Perl5 on Parrot. I don't see any reason why the Perl5 folks can't continue to develop it by migrating to Parrot. Who knows, perhaps Perl5 and Perl6 will become different products. Maybe Perl5 could be for admins and quick scripts, and Perl6 for more complex projects. That's my 2 bits, Grant M. ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
On Friday, March 14, 2003, at 09:13 AM, Tolkin, Steve wrote: "When one is designing the successor to a relatively small, elegant, and successful system, there is a tendency to become grandiose in one's success and design an elephantine feature-laden monstrosity." I know too little about Perl 6 to make any comment on this, but I had a similar feeling that you do when Wu-Tang Clan released "Wu-Tang Forever" -- I waited a couple /years/ for the new Wu-Tang album, and when it finally came, inside the jewel case there were ads for both "Wu-Wear" (Wu-Tang Clan official clothing) and America Online! Not exactly the same, but ... well, anyway. Erik -- Erik Price email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
On Fri, Mar 14, 2003 at 04:31:06PM -0500, Andrew Pimlott wrote: > On Fri, Mar 14, 2003 at 04:32:17PM -0500, John Tobey wrote: > > > > YES. That's what we want. That is how Scheme and Common Lisp work. > > That would make for cleaner code. > > Well, Common Lisp and Scheme don't work quite the same. Thanks for the correction. -- John Tobey <[EMAIL PROTECTED]> \^-^ /\ /\ ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
RE: [Boston.pm] Perl 6 has become too complex
I think I am in the same camp as Chris Nandor and John Tobey. They, and I, have just given up on Perl 6. But there is a problem in staying with Perl 5. Due to Perl 6 the Perl 5 community is deprived of the resources of several key people, e.g. Larry, and also "Good Damian". Also, like John, I am interested in Parrot, but wonder if Parrot will be further delayed due to the need to support Perl 6, when a Perl 5 oriented Parrot might be done much sooner. Ruby holds little appeal for me, and Python even less. I think it is telling that most of the responses to my email are a technical discussion, e.g. how to make Perl more like Scheme. But Scheme, while elegant, is still a "boutique" langue whereas Perl is widely used. As we know, when Larry designed Perl he took the best parts of awk, VC, sh, etc., plus added a few excellent new ideas, and produced a language that was a mixture -- but a mix based on features that had been proven to be good. In contrast Perl 6 is a mixture of a variety of theoretically desireable features, e.g. multimethods, functional programming, logic programming, aspect oriented programming, design by contract, etc. that have not been proven in widely used languages. I agree that these features are theoretically desirable. But that does not mean they should all be put into one language. The thrust of the second system syndrome is the temptation to add all those other truly good features that the first system did not have. The claim that people will still be able to program in Perl 6 using a Perl 5 like subset is disingenuous. Most people read as much code as they write. The new language is much larger, and much harder to understand. It is likely to produce odd error messages, at least odd to people who have not taken courses in formal program language semantics. The original design of perl was simple. I learned Perl 4 from its man page -- yes there was one long man page that completely described the entire language. Apocalyse 6 included almost 30 pages discussing the new ==> and <== operators! This is not a good sign. Hopefully helpfully yours, Steve -- Steven Tolkin [EMAIL PROTECTED] 617-563-0516 Fidelity Investments 82 Devonshire St. V4D Boston MA 02109 There is nothing so practical as a good theory. Comments are by me, not Fidelity Investments, its subsidiaries or affiliates. > -Original Message- > From: John Tobey [mailto:[EMAIL PROTECTED] > Sent: Friday, March 14, 2003 4:51 PM > To: Dan Sugalski > Cc: Andrew Pimlott; [EMAIL PROTECTED] > Subject: Re: [Boston.pm] Perl 6 has become too complex > > > On Fri, Mar 14, 2003 at 04:35:07PM -0500, Dan Sugalski wrote: > > > > > >YES. That's what we want. That is how Scheme and Common > Lisp work. > > >That would make for cleaner code. > > > > Well, if that's what you want... :) > > > > I'm OK with that. Convince Larry and I'll make it happen. > > Thanks but I'll pass. I've given up on Perl 6 (but not on Parrot). > > -- > John Tobey <[EMAIL PROTECTED]> > \^-^ > /\ /\ > ___ > Boston-pm mailing list > [EMAIL PROTECTED] > http://mail.pm.org/mailman/listinfo/boston-pm > ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
On Fri, Mar 14, 2003 at 04:17:08PM -0500, Andrew Pimlott wrote: > > bar() -> undef > > foo("a") > > bar() -> "a" > > foo("b") > > bar() -> "b" Um, the last one is -> "a". Andrew ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
At 4:17 PM -0500 3/14/03, Andrew Pimlott wrote: On Fri, Mar 14, 2003 at 03:49:21PM -0500, Dan Sugalski wrote: At 10:14 AM -0500 3/14/03, Andrew Pimlott wrote: >A6 says that, as in Perl 5, only anonymous subs are closures. I've >always thought of the fact that Perl 5 named subs are not closures >as a bug kept for compatibility. Well... there's always the issue that closures are done by instantiating the sub at runtime, while named subs are instantiated at compile time, which causes some difficulties. (As the enclosing sub's lexicals instantiate at runtime, thus giving the contained sub nothing to close over) I don't understand exactly what you mean, because perl's behaviour is rather strange and I don't know how it's implemented. Currently, named subs close over _something_, because they get the value of lexicals from the first time the enclosing code is run. Yeah, the current behavior's kind of odd, and arguably broken. (And I'd not argue against that too hard) At any rate, you're right that the fact that Perl 5 nested subs are visible globally means that talking about closure is basically nonsense. In my view, this is part of the bug. Nested subs should be visible only within their scope (or at least, there should be a way to declare them so that they are), in which case they would have to be instantiated at run-time (right?), and there should be no problem binding the current lexical variables. Well, the "Named subs are always global" rule isn't a bad one, and is pretty common on top of that. Most of the used languages (C, COBOL, Fortran, BASIC, and a few others), at least at the time perl was getting built, did it that way if they even let you play nesting games. Yeah, I know, Pascal and its descendants didn't do it that way, but Pascal wasn't particularly mainstream in the large computer realm as anything other than a teaching language people hated because it was limited enough to be generally useless. > Now, if the named lexically scoped sub actually got re-instantiated every time, *that* would be different. Am I correct that Perl 6 lexical subs would have to get re-instantiated every time, or could you implement them such that they are not? The subs themselves won't get re-instantiated--one compilation per customer--but you'd get a new set of metadata (scratchpads and such) each time through. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
On Fri, Mar 14, 2003 at 04:32:17PM -0500, John Tobey wrote: > On Fri, Mar 14, 2003 at 03:49:21PM -0500, Dan Sugalski wrote: > > At 10:14 AM -0500 3/14/03, Andrew Pimlott wrote: > > > > > >A6 says that, as in Perl 5, only anonymous subs are closures. I've > > >always thought of the fact that Perl 5 named subs are not closures > > >as a bug kept for compatibility. > > > > Well... there's always the issue that closures are done by > > instantiating the sub at runtime, while named subs are instantiated > > at compile time, which causes some difficulties. (As the enclosing > > sub's lexicals instantiate at runtime, thus giving the contained sub > > nothing to close over) > > > > Now, if the named lexically scoped sub actually got re-instantiated > > every time, *that* would be different. > > YES. That's what we want. That is how Scheme and Common Lisp work. > That would make for cleaner code. Well, Common Lisp and Scheme don't work quite the same. (define (f n) (define (g) n)) in Scheme creates a lexically scoped function g. If it is called within the body of f, it uses the current (lexical) value of n. (defun f (n) (defun g () n)) in Common Lisp greates a globally visible function g when f is run, and re-defines it every time f is run. So wherever you run it, you get n from the most recent call to f. If we have (defun f (n) (defun g () n) (if (> n 0) (f (1- n))) (g)) then (f 4) returns 0. To get Scheme behaviour in Lisp, you have to use a different function: (defun f (n) (labels ((g () n)) (if (> n 0) (f (1- n))) (g))) Now (f 4) return 4. I wouldn't recommend the Lisp behavior. I'm sure the Lisp people would get rid of it if they didn't have bigger compatibility issues than Perl. :-) Andrew ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
On Fri, Mar 14, 2003 at 04:35:07PM -0500, Dan Sugalski wrote: > > > >YES. That's what we want. That is how Scheme and Common Lisp work. > >That would make for cleaner code. > > Well, if that's what you want... :) > > I'm OK with that. Convince Larry and I'll make it happen. Thanks but I'll pass. I've given up on Perl 6 (but not on Parrot). -- John Tobey <[EMAIL PROTECTED]> \^-^ /\ /\ ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
At 4:32 PM -0500 3/14/03, John Tobey wrote: On Fri, Mar 14, 2003 at 03:49:21PM -0500, Dan Sugalski wrote: At 10:14 AM -0500 3/14/03, Andrew Pimlott wrote: > >A6 says that, as in Perl 5, only anonymous subs are closures. I've >always thought of the fact that Perl 5 named subs are not closures >as a bug kept for compatibility. Well... there's always the issue that closures are done by instantiating the sub at runtime, while named subs are instantiated at compile time, which causes some difficulties. (As the enclosing sub's lexicals instantiate at runtime, thus giving the contained sub nothing to close over) Now, if the named lexically scoped sub actually got re-instantiated every time, *that* would be different. YES. That's what we want. That is how Scheme and Common Lisp work. That would make for cleaner code. Well, if that's what you want... :) I'm OK with that. Convince Larry and I'll make it happen. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
On Fri, Mar 14, 2003 at 03:49:21PM -0500, Dan Sugalski wrote: > At 10:14 AM -0500 3/14/03, Andrew Pimlott wrote: > > >A6 says that, as in Perl 5, only anonymous subs are closures. I've > >always thought of the fact that Perl 5 named subs are not closures > >as a bug kept for compatibility. > > Well... there's always the issue that closures are done by > instantiating the sub at runtime, while named subs are instantiated > at compile time, which causes some difficulties. (As the enclosing > sub's lexicals instantiate at runtime, thus giving the contained sub > nothing to close over) I don't understand exactly what you mean, because perl's behaviour is rather strange and I don't know how it's implemented. Currently, named subs close over _something_, because they get the value of lexicals from the first time the enclosing code is run. sub foo { my ($x) = @_; sub bar { print ">> $x\n"; } } > bar() -> undef > foo("a") > bar() -> "a" > foo("b") > bar() -> "b" Which is perfectly useless. :-) At any rate, you're right that the fact that Perl 5 nested subs are visible globally means that talking about closure is basically nonsense. In my view, this is part of the bug. Nested subs should be visible only within their scope (or at least, there should be a way to declare them so that they are), in which case they would have to be instantiated at run-time (right?), and there should be no problem binding the current lexical variables. > Now, if the named lexically scoped sub actually got re-instantiated > every time, *that* would be different. Am I correct that Perl 6 lexical subs would have to get re-instantiated every time, or could you implement them such that they are not? Andrew ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
On Fri, Mar 14, 2003 at 03:49:21PM -0500, Dan Sugalski wrote: > At 10:14 AM -0500 3/14/03, Andrew Pimlott wrote: > > > >A6 says that, as in Perl 5, only anonymous subs are closures. I've > >always thought of the fact that Perl 5 named subs are not closures > >as a bug kept for compatibility. > > Well... there's always the issue that closures are done by > instantiating the sub at runtime, while named subs are instantiated > at compile time, which causes some difficulties. (As the enclosing > sub's lexicals instantiate at runtime, thus giving the contained sub > nothing to close over) > > Now, if the named lexically scoped sub actually got re-instantiated > every time, *that* would be different. YES. That's what we want. That is how Scheme and Common Lisp work. That would make for cleaner code. -- John Tobey <[EMAIL PROTECTED]> \^-^ /\ /\ ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
At 10:14 AM -0500 3/14/03, Andrew Pimlott wrote: On Fri, Mar 14, 2003 at 09:30:06AM -0500, Dan Sugalski wrote: Still... What exactly about A6 did you dislike? It's a bit big, but there's nothing in it that seemed particularly controversial or foolish to me, and I tend to get cranky with the new features. How 'bout this one. (I mean to bring it up on perl6-langage or somewhere, but I haven't done my homework yet, so I'll float it here.) A6 says that, as in Perl 5, only anonymous subs are closures. I've always thought of the fact that Perl 5 named subs are not closures as a bug kept for compatibility. Well... there's always the issue that closures are done by instantiating the sub at runtime, while named subs are instantiated at compile time, which causes some difficulties. (As the enclosing sub's lexicals instantiate at runtime, thus giving the contained sub nothing to close over) Now, if the named lexically scoped sub actually got re-instantiated every time, *that* would be different. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
"Tolkin, Steve" wrote: > I think the language design shows > too much influence of "Evil Damian". Dude, you're creeping me out. The way I see it is this: Perl 5 is cool in that it hides a lot of the details under the hood, and has a rich set of DWIM capabilities. But, really, it doesn't have the capacities of some of the languages developed almost 2 decades ago, specifically Ada. I'd like to be able to declare an overloaded subroutine called Iterate, have different versions of Iterate for each TYPE of variable I want to Iterate upon, and then just call Iterate(@arr) or Iterate(%hash). And OO perl was kind of a cool idea, but when you get into the nitty gritty of it, there are some things that make you go, "Ouch!" The @ISA array was a nice idea, but when you start using SUPER:: you see serious limitations. DESTROY is another one. And again, you need one of Evil Damian's perl packages if you want a multiple methods of the same name to be called determined by the TYPE of the two objects it is called upon. So, the biggest thing I see missing in perl 5 is the concept of TYPES. Ada has types and has a rich support for overloading and even multi-methods if I remember correctly. (the next biggest thing missing in perl 5 is really good OO) The problem with Ada is that EVERYTHING is typed. You can't even go to the bathroom without declaring a variable of type 'Urinal'. If Perl 6 can add the concepts of TYPES but still be able to Do What I Mean when the user doesn't declare a type, then everything should work out fine. I haven't combed the Apocalypses, but what I get from a quick scan here and there is that perl 6 will still have a simple, DWIM interface when all you want to do is print "hello world", but when you're ready to go to Overloaded Subroutines and MultiMethods, it'll be built into the language as well. Greg ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
Andrew Pimlott wrote: > sub foo > { > my ($x, $y, $z) = @_; > sub helper > { > ... $x $y $z ... > } > ... > ... helper() ... > ... helper() ... > ... > } > > In Perl 5 you can get around this by assigning > an anon sub to a glob ref (ugh) hm, well, you can get around glob refs as shown below. (haven't checked for typos, etc) #!/user/local/bin/perl use Symbol::Table; my $symbol=Symbol::Table->new('CODE'); sub foo { my ($x,$y,$z)[EMAIL PROTECTED]; # Look Ma! No typeglobs! $symbol->{helper}=sub { $x++;$y+=2;$z*=2; } helper(); helper(); } Symbol::Table is a module I just released to CPAN expressly for fiddling with the symbol table without the user having to do eval() or fiddle with *type_globs. all that nastyness is hidden in the module. $symbol is a reference to a tied hash, the keys are the names of the symbols, the values are references to the symbols. make sure you get Symbol-Table-1.01.tar.gz SymbolTable-* is scheduled for deletion. Oh, just a warning, read the POD, but dont look at the code in the module, it's the work of a madman. ;) Enjoy, Greg London ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
At 09:30 -0500 2003.03.14, Dan Sugalski wrote: >At 9:13 AM -0500 3/14/03, Tolkin, Steve wrote: >>I want "good Damian" to work with Larry el al. to reduce the >>complexity of the language. Or (shudder) a subset of the language to >>be defined. >> >>Please advise me as to how to proceed. > >Ruby and Python seem to be the standard choices. What's wrong with Perl (the one that actually exists)? It's not going away ... Perl 6 won't be here for a long time, and even when it does arrive, many people will continue to use Perl 5. I don't like the Perl 6 language, in many ways. I stopped caring; why should I worry about something I don't like that I can't change, when I have something I do like already? -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/ ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
I've never understood why nested Perl subs weren't closures from the very beginning. I consider this a BUG and I'd like to see it fixed in Perl 6 (if not earlier!) What possible utility is there in the current semantics? ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
On Fri, Mar 14, 2003 at 09:30:06AM -0500, Dan Sugalski wrote: > Still... What exactly about A6 did you dislike? It's a bit big, but > there's nothing in it that seemed particularly controversial or > foolish to me, and I tend to get cranky with the new features. How 'bout this one. (I mean to bring it up on perl6-langage or somewhere, but I haven't done my homework yet, so I'll float it here.) A6 says that, as in Perl 5, only anonymous subs are closures. I've always thought of the fact that Perl 5 named subs are not closures as a bug kept for compatibility. It prevents this nice programming style (example in Perl 5 because I'm sure I would botch Perl 6): sub foo { my ($x, $y, $z) = @_; sub helper { ... $x $y $z ... } ... ... helper() ... ... helper() ... ... } In Perl 5 you can get around this by assigning an anon sub to a glob ref (ugh), and in Perl 6 it appears you will be able to assign it to a normal lexical variable (better), but neither is as nice as just declaring a sub. Given that Perl 6 will even have lexically scoped subs, it's seems perverse that they would not also be closures. Besides, if such subs aren't closures, what is the semantics of accessing a lexical variable from the outer scope? It seems that the only alternatives to closure are Perl 5 "variable will not stay shared"--which is unspeakably ugly and the source of much confusion--or error. So, why aren't all subs, or at least lexical subs, closures? Andrew ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
At 9:13 AM -0500 3/14/03, Tolkin, Steve wrote: In Apocalyse 6 http://www.perl.com/pub/a/2003/03/07/apocalypse6.html Larry Wall explains how subroutines are going to work in Perl 6. I think this is the straw that broke the camel's back. I think this is the worst case of "second system syndrome" I have ever seen (See Jargon file e.g. at http://info.astrian.net/jargon/terms/s/second-system_effect.html ) and I quote: "When one is designing the successor to a relatively small, elegant, and successful system, there is a tendency to become grandiose in one's success and design an elephantine feature-laden monstrosity." I think the language design shows too much influence of "Evil Damian". I want "good Damian" to work with Larry el al. to reduce the complexity of the language. Or (shudder) a subset of the language to be defined. Please advise me as to how to proceed. Ruby and Python seem to be the standard choices. Still... What exactly about A6 did you dislike? It's a bit big, but there's nothing in it that seemed particularly controversial or foolish to me, and I tend to get cranky with the new features. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
hi ( 03.03.14 09:13 -0500 ) Tolkin, Steve: > Please advise me as to how to proceed. i think you can email either damian or larry [psuedo-] directly. or post something on perlmonks.org. or you can start your own fork of the perl code- that's one of the benefits of open source. -- .--- ... [ x ] ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
[Boston.pm] Perl 6 has become too complex
In Apocalyse 6 http://www.perl.com/pub/a/2003/03/07/apocalypse6.html Larry Wall explains how subroutines are going to work in Perl 6. I think this is the straw that broke the camel's back. I think this is the worst case of "second system syndrome" I have ever seen (See Jargon file e.g. at http://info.astrian.net/jargon/terms/s/second-system_effect.html ) and I quote: "When one is designing the successor to a relatively small, elegant, and successful system, there is a tendency to become grandiose in one's success and design an elephantine feature-laden monstrosity." I think the language design shows too much influence of "Evil Damian". I want "good Damian" to work with Larry el al. to reduce the complexity of the language. Or (shudder) a subset of the language to be defined. Please advise me as to how to proceed. Hopefully helpfully yours, Steve -- Steven Tolkin steve . tolkin at fmr dot com 617-563-0516 Fidelity Investments 82 Devonshire St. V8D Boston MA 02109 There is nothing so practical as a good theory. Comments are by me, not Fidelity Investments, its subsidiaries or affiliates. ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm