Apoc 4: The skip keyword
> Oh, one other tweak. The RFC proposes to overload next
> to mean "fall through to the next case". I don't think
> this is wise, since we'll often want to use loop controls
> within a switch statement. Instead, I think we should
> use skip to do that. (To be read as "Skip to the next
> statement.")
I would like to suggest a different keyword that does not imply some
`jumping' action. For years, I have used `nobreak' in my C code when I want
to indicate that a case fall-through is intentional:
#define nobreak
switch(...) {
case 1: ...;
nobreak; /* intentional fall-through */
case 2: ...;
break;
case 3: ...;
}
Does anyone agree that `nobreak' reads much better than `skip'?
Dave.
Perl6 -- what is in a name?
I'm going to just say this, and I ask that everyone who reads it take a deep breath, count to 10 and then respond if you wish. I was reading Apoc 4 and while marveling at the elegence of what Larry's doing to the language, I had an epiphany. Perl6 is simply not Perl. It's about as much Perl as Perl1 was AWK, C and Bourne Shell. I'm not saying that there's anything wrong with Perl6, or that it's on the wrong track. I love it, and want to start using it tomorrow. However, it is clearly a new species, and just as we do not call "Homo Sapiens Sapiens", "Homo Erectus 3", I am beginning to come around to the opinion that Perl6 is a poor choice of name for this new language. Aesthetics asside, the name implies continuity, and while that continuity is planned in terms of compatibility modes and anscestral influence, is that really sufficient? If Python X.0 included a Perl5 parser/compat mode and had many Perl features added, would *it* be Perl6? Is it Perl6 simply because Larry is its author (this makes AWK, C2 by extension)? If the language is named "Pint" (an example, not a suggestion), would this help new users to accept its features on its own terms instead of bristling over every way in which they are not Perl's? I don't know, but it seemed like a topic worthy of some discussion. What I don't want to start (and I may have done so anyway) is a simple name war. If you feel emotionally attached to "Perl", then fine, so am I. But if you feel that there is some compelling logic here that will affect the community, I would be very interested. If someone has already brought this up, I appologize. I read as much of this list as I can while still getting "real work" done ;-)
Re: Perl6 -- what is in a name?
On Mon, Jan 28, 2002 at 10:44:19AM -0500, Aaron Sherman wrote: > I'm going to just say this, and I ask that everyone who reads it take a > deep breath, count to 10 and then respond if you wish. > > I was reading Apoc 4 and while marveling at the elegence of what Larry's > doing to the language, I had an epiphany. Perl6 is simply not Perl. I remember long ago being very concerned about this very eventuality. I'm glad that it's not the case. Perl 6 is most definitely Perl. The problem is that everything you've heard about Perl 6 so far is about bits of it that are different from Perl 5. The Apocalypses tell us what's going to change is Perl 6, and the Exegeses tell us how to use all the lovely new features. They don't tell you how to use the old features, because you already know that. All in all, this obscures the fact that the vast bulk of the language is the same. I even surprised myself by how few changes were required to turn a Perl 5 tokeniser into a Perl 6 tokeniser. Or maybe that's just because I designed it so well. :) -- Hanlon's Razor: Never attribute to malice that which is adequately explained by stupidity.
Re: Perl6 -- what is in a name?
At 4:12 PM + 1/28/02, Simon Cozens wrote: >On Mon, Jan 28, 2002 at 10:44:19AM -0500, Aaron Sherman wrote: >> I'm going to just say this, and I ask that everyone who reads it take a >> deep breath, count to 10 and then respond if you wish. >> >> I was reading Apoc 4 and while marveling at the elegence of what Larry's >> doing to the language, I had an epiphany. Perl6 is simply not Perl. > >I remember long ago being very concerned about this very eventuality. I'm >glad that it's not the case. Perl 6 is most definitely Perl. And just as a data point for that... Damian snagged some code from a few of us to do a 5->6 conversion on for a TPJ article to address this very issue. The code I handed to him had exactly no changes made. None. Could've run (and probably will run) the thing as-is into perl 6 and it would've run just as well as it did under perl 5. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
FW: Perl6 -- what is in a name?
[I'm an idiot. I forgot to send this to the group, too.] Aaron Sherman: # I'm going to just say this, and I ask that everyone who reads # it take a # deep breath, count to 10 and then respond if you wish. # # I was reading Apoc 4 and while marveling at the elegence of # what Larry's # doing to the language, I had an epiphany. Perl6 is simply not # Perl. It's # about as much Perl as Perl1 was AWK, C and Bourne Shell. I'm # not saying # that there's anything wrong with Perl6, or that it's on the # wrong track. # I love it, and want to start using it tomorrow. However, it # is clearly a # new species, and just as we do not call "Homo Sapiens Sapiens", "Homo # Erectus 3", I am beginning to come around to the opinion that # Perl6 is a # poor choice of name for this new language. I'd like you to perform an exercise for me if you have a Camel III. The first thing is to open it to Chapter 4, which starts on page 111. Now, read through Apocalypse 4, highlighting everything that's changed. Not things that have been added--just things that have changed. I think you'll find that Perl 6 isn't as dissimilar to Perl 5 as you may think. --Brent Dax [EMAIL PROTECTED] Parrot Configure pumpking and regex hacker Check out the Parrot FAQ: http://www.panix.com/~ziggy/parrot.html (no, it's not mine) . hawt sysadmin chx0rs This is sad. I know of *a* hawt sysamin chx0r. I know more than a few. obra: There are two? Are you sure it's not the same one?
Re: Perl6 -- what is in a name?
> What I don't want to start (and I may have done so anyway) is a simple
> name war. If you feel emotionally attached to "Perl", then fine, so am
> I. But if you feel that there is some compelling logic here that will
> affect the community, I would be very interested.
The reason why it's still Perl is that it is a relatively small
learning effort to write Perl 6 code using Perl 5 idioms. Eg $foo{bar}
becomes %foo{bar}, '.' becomes '_' etc, but the end code is still
largely recognisably Perl.
Contrast this to an experienced Perl 5 coder trying to pick up Python
or Ruby from scratch. A different order of magnitude altogether.
Clearly there's all the optional new stuff in Perl 6 which is strange and
needs learning, but that's no different from Perl 4 coders having to
get up to speed on refs, OO, and all the other 'strange' stuff that
Perl 5 introduced. (eg think how strange $self->SUPER::bar([qw(a b)])
was to Perl 4 coders.)
So in purely technical terms, I think Perl 6 is close enough to Perl 5
to keep the name.
In marketing terms, we absolutely must keep the name. If you're a fan
of Coke, are you more likely to switch to "Cherry Coke (tm)(c)(r)(etc)",
or "new cherry fizzo drink, bottled in the same factory that makes
Coke(tm)(c)(r)(etc)" ;-)
Just MHO.
Re: Barewords and subscripts
On Sat, 2002-01-26 at 12:01, Simon Cozens wrote:
> A4 said that there were no barewords in Perl 6. Does this mean that
> $foo{bar}
> actually should be written
> %foo{"bar"}
Hmm... I'm curious, has anyone yet tackled printf("%d{x}",%d{x})? Is
that a bug or does it produce "n{x}" where n is the value of %d{x} as an
integer?
RE: Perl6 -- what is in a name?
Aaron Sherman: # On Mon, 2002-01-28 at 11:17, Brent Dax wrote: # # > I'd like you to perform an exercise for me if you have a Camel III. # # I have a Camel 1 (pink) and 2, but not 3. However, I follow # you. You are # (as everyone else has fallen into the trap of) thinking of only what # hurdles a Perl programmer has in tackling Perl6. # # I ask you to think in terms of a Perl programmer tackling # maintenance of # a program written by someone who has never seen "old Perl". # Look at C++. # I can write a C++ program easily if I'm a C programmer. # However, trying # to maintain a native C++ program as a C programmer would be impossible # without a good chunk of re-education. C9x, on the other hand would be # easy for an old-school K&R C programmer to understand (even if the # parameter passing is very different). # # Here's the scary part... C++'s syntax is more like C's than # Perl6's will # be like Perl5's. Really. Mostly C++ just adds new operators and leaves # the rest of the language alone. "." becoming "_", "->" becoming ".", # "=>" becoming a tuple constructor, "%" and "@" becoming... something # new. These are the hurdles that C programmers never had to # deal with in # going to C++, but Perl programmers will have to. *THEN* # there's the new # syntax. Imagine trying to understand code that actually uses Perl6. # # > I think you'll find that Perl 6 isn't as dissimilar to Perl # 5 as you may # > think. # # I think the first guy that gets hired to maintain Perl6 code, # and think # "hey, I know Perl, no sweat" will disagree with you. I disagree. He'll see stuff he doesn't understand and try to consult perldoc on it, at which point he'll realize that he's working with Perl 6. Then he'll run out, get Camel IV, read it, and go back to work. Programmer is working with a better version of language, program is fixed, and ORA made fifty bucks. Everybody's happy. :^) --Brent Dax [EMAIL PROTECTED] Parrot Configure pumpking and regex hacker Check out the Parrot FAQ: http://www.panix.com/~ziggy/parrot.html (no, it's not mine) . hawt sysadmin chx0rs This is sad. I know of *a* hawt sysamin chx0r. I know more than a few. obra: There are two? Are you sure it's not the same one?
RE: Barewords and subscripts
Aaron Sherman:
# On Sat, 2002-01-26 at 12:01, Simon Cozens wrote:
# > A4 said that there were no barewords in Perl 6. Does this mean that
# > $foo{bar}
# > actually should be written
# > %foo{"bar"}
#
# Hmm... I'm curious, has anyone yet tackled printf("%d{x}",%d{x})? Is
# that a bug or does it produce "n{x}" where n is the value of
# %d{x} as an
# integer?
It produces something pretty weird. Just single-quote the format string
instead of double-quoting it.
--Brent Dax
[EMAIL PROTECTED]
Parrot Configure pumpking and regex hacker
Check out the Parrot FAQ: http://www.panix.com/~ziggy/parrot.html (no,
it's not mine)
. hawt sysadmin chx0rs
This is sad. I know of *a* hawt sysamin chx0r.
I know more than a few.
obra: There are two? Are you sure it's not the same one?
Re: Apoc4: The loop keyword
On Sun, Jan 27, 2002 at 10:43:08PM -, Rafael Garcia-Suarez wrote:
> Melvin Smith wrote in perl6-language:
> >>
> >>Besides no one has commented on Steve Fink's (I think it was him) idea
> >>to store the result of the most recently executed conditional in $?. I
> >>kinda like that idea myself. It makes mnemonic sense.
> >
> > I like the $? idea, and it could probably be optimized away.
>
> And $? should probably be automatically temporarized to the current
> block (a bit like $^H in Perl 5) :
>
> if foo() {
> if bar() {
> # $? is bar() here
> frob(); # let's call a function that may contain
> # if statements
> }
> # but $? is foo() here
> }
>
> (is "temporarized" the correct word, now that local() goes away?)
No, certainly not. It should be lexically scoped.
do { my $a = 3; do { my $a = 4; }; print $a };
prints 3 (you don't need to do anything fancy like temping to make the
outer $a's scope extend past the end of nested blocks.) But we do not want
sub p { print $? }
if ($x == 3) { p() }
to print 3. That introduces the same headaches as the non-lexical $_ does now.
Re: Apoc4: The loop keyword
On Mon, Jan 28, 2002 at 09:56:03AM -0800, Steve Fink wrote: > Allowing $? would eliminate having any different behavior from boolean > vs scalar context, and that seems like a potentially bad idea. (And I > really don't like the idea of behavior changing based on the addition > of a $? way down within the if block.) Nah, we just use contextual superpositions to get at the proper evaluation that we need for $? ;-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Apoc4: The loop keyword
On Fri, Jan 25, 2002 at 11:31:13PM -0500, Melvin Smith wrote: > At 11:40 AM 1/25/2002 -0600, Jonathan Scott Duff wrote: > >On Fri, Jan 25, 2002 at 11:57:25AM +0100, Bart Lateur wrote: > >> On Mon, 21 Jan 2002 15:43:07 -0500, Damian Conway wrote: > >> > >> >What we're cleaning up is the ickiness of having things declared outside > >> >the braces be lexical to the braces. *That's* hard to explain to > >beginners. > >> > >> But it's handy. And that was, until now, what mattered with Perl. > > > >No, handiness still matters with Perl. It's just that the balance has > >tipped a wee bit towards the consistency/regularity/simplicity/whatever > >side of the scale. > > > >Besides no one has commented on Steve Fink's (I think it was him) idea > >to store the result of the most recently executed conditional in $?. I > >kinda like that idea myself. It makes mnemonic sense. > > I like the $? idea, and it could probably be optimized away. Optimization reminds me of the one thing about $? that bugs me. if (foo) # evaluates foo in boolean context if ($x = foo) # evaluates foo in scalar context, ($x=foo) aka $x in boolean context Allowing $? would eliminate having any different behavior from boolean vs scalar context, and that seems like a potentially bad idea. (And I really don't like the idea of behavior changing based on the addition of a $? way down within the if block.)
Re: What can be hyperoperated?
[EMAIL PROTECTED] writes:
: Simon wrote:
:
: > Given hyperoperators, I wonder if we can actually drop map.
:
: So:
:
: @result = map { block } @data;
:
: becomes:
:
: @result = {block}^.(@data);
:
: Hmmm.
Some people might think of it more like this:
@result = @data ^. {block};
except that {block} would be parsed as a subscript, and you want
argument binding, so it starts looking more like:
@result = @data ^-> $a {block};
But -> really is a term-forcer, so that means we're really talking
about the bare ^ operator:
@result = @data ^ $subref;
That's gettin' kinda scary.
Larry
Re: What can be hyperoperated?
On Mon, Jan 28, 2002 at 11:30:41AM -0800, Larry Wall wrote: > @result = @data ^ $subref; > > That's gettin' kinda scary. Hence the original question. :) -- Sendmail may be safely run set-user-id to root. -- Eric Allman, "Sendmail Installation Guide"
RE: Perl6 -- what is in a name?
From: Brent Dax [mailto:[EMAIL PROTECTED]] > Aaron Sherman: > # > # I think the first guy that gets hired to maintain Perl6 code, > # and think "hey, I know Perl, no sweat" will disagree with > # you. > > I disagree. He'll see stuff he doesn't understand and try to > consult perldoc on it, at which point he'll realize that he's > working with Perl 6. Then he'll run out, get Camel IV, read > it, and go back to work. Programmer is working with a better > version of language, program is fixed, and ORA made fifty > bucks. Everybody's happy. :^) Perhaps. Or perhaps he'll be like our company's lead C++ developers. They liked Perl4 well enough for a certain problem domain, saw some Perl5 code... and have tried to stay away from it ever since. Perl6 isn't going to make everyone happy.
Re: Perl6 -- what is in a name?
On Mon, Jan 28, 2002 at 01:52:13PM -0600, Garrett Goebel wrote: : :From: Brent Dax [mailto:[EMAIL PROTECTED]] :> Aaron Sherman: :> # :> # I think the first guy that gets hired to maintain Perl6 code, :> # and think "hey, I know Perl, no sweat" will disagree with :> # you. :> :> I disagree. He'll see stuff he doesn't understand and try to :> consult perldoc on it, at which point he'll realize that he's :> working with Perl 6. Then he'll run out, get Camel IV, read :> it, and go back to work. Programmer is working with a better :> version of language, program is fixed, and ORA made fifty :> bucks. Everybody's happy. :^) : :Perhaps. Or perhaps he'll be like our company's lead C++ developers. They :liked Perl4 well enough for a certain problem domain, saw some Perl5 code... :and have tried to stay away from it ever since. : :Perl6 isn't going to make everyone happy. Until you start running their code on parrot, or compile it to Perl bytecode. :-) Darn, nasty thoughts out loud again. Casey West -- "Louis Pasteur's theory of germs is ridiculous fiction". -- Pierre Pachet, Professor of Physiology at Toulouse, 1872
Re: Perl6 -- what is in a name?
On Mon, 28 Jan 2002, Garrett Goebel wrote:
> From: Brent Dax [mailto:[EMAIL PROTECTED]]
> > Aaron Sherman:
> > #
> > # I think the first guy that gets hired to maintain Perl6 code,
> > # and think "hey, I know Perl, no sweat" will disagree with
> > # you.
> >
> > I disagree. He'll see stuff he doesn't understand and try to
> > consult perldoc on it, at which point he'll realize that he's
> > working with Perl 6. Then he'll run out, get Camel IV, read
> > it, and go back to work. Programmer is working with a better
> > version of language, program is fixed, and ORA made fifty
> > bucks. Everybody's happy. :^)
>
> Perhaps. Or perhaps he'll be like our company's lead C++ developers. They
> liked Perl4 well enough for a certain problem domain, saw some Perl5 code
> and have tried to stay away from it ever since.
Pretty odd, I think that C++ is to C, what perl5 to perl4 except
they forgot about the backcompatibility thing. So, in a sense, C++
developper should like perl5.
I see Python and Ruby as cleant-up but incompatible perl5 just like
Java or C# are cleant-up C++.
Perl6 will be cleant-up perl5 with a bunch of new features that will make
more expressive than ever.
>
> Perl6 isn't going to make everyone happy.
I joked that java lover will just corps-dump (choke) when seeing:
@dirpath ^=~ s{([^/])$}{$1/};
I love it.
--
Stéphane Payrard -- s.payrard@@wanadoo.fr
# mailstat
Most people don't type their own logfiles; but, what do I care?
RE: What can be hyperoperated?
Larry Wall:
# Some people might think of it more like this:
#
# @result = @data ^. {block};
#
# except that {block} would be parsed as a subscript, and you want
# argument binding, so it starts looking more like:
#
# @result = @data ^-> $a {block};
#
# But -> really is a term-forcer, so that means we're really talking
# about the bare ^ operator:
#
# @result = @data ^ $subref;
#
# That's gettin' kinda scary.
Then maybe we require (or at least request) a do:
@result = @data ^do $subref;
Is that a little closer to the comfort zone?
However, note that that still leaves grep as-is, with the old format.
Perhaps that's a clue that we should leave this alone, though perhaps
with the args to map and grep rearranged.
--Brent Dax
[EMAIL PROTECTED]
Parrot Configure pumpking and regex hacker
Check out the Parrot FAQ: http://www.panix.com/~ziggy/parrot.html (no,
it's not mine)
. hawt sysadmin chx0rs
This is sad. I know of *a* hawt sysamin chx0r.
I know more than a few.
obra: There are two? Are you sure it's not the same one?
Re: What can be hyperoperated?
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Simon Cozens) wrote:
>
> On Sat, Jan 26, 2002 at 04:52:53PM -0800, Larry Wall wrote:
> > Perhaps we shouldn't be using ; for this.
>
> Given hyperoperators, I wonder if we can actually drop map.
Something like
@res = ^{ DoSomething($a) }, @source -> $a;
?
But that's put the block first again...
--
[EMAIL PROTECTED]
Re: What can be hyperoperated?
Simon Cozens writes: : Given hyperoperators, I wonder if we can actually drop map. Before someone panics completely, I suppose I should point out that I'm not terribly interested in dropping the current C syntax. It's essentially a method on a closure in its current form, which doesn't rule out reversing it and having a C method on a list that takes a closure as an argument. Nor does it rule out turning C inside out into some fandangled hyperoperator that people will be looked at funny for using anywhere except in an obfuscated Perl code contest. Part of the idea of relaxing what's a keyword and what's just a global subroutine or a universal method is that we can do TMTOWTDI even better. Our quest is not to reinvent a certain constrictive snake, poorly or otherwise. Larry
Re: What can be hyperoperated?
[EMAIL PROTECTED] writes:
: On Fri, Jan 25, 2002 at 06:03:55PM -0800, Larry Wall wrote:
: > Do they need to? In the simple case, the hyperoperator provides list
: > context to its arguments, but just calls the scalar operation repeatedly
: > to fake up the list operation. Any operator
: >
: > @result = @a ^op @b
: >
: > is really just something like
: >
: > @result = for @a; @b -> $a, $b { $a op $b }
:
: Just to make sure I'm not confused, the for loop above should really
: look like this:
:
: @result = for @a; @b -> $a; $b { $a op $b }
:
: right? I re-read the Apocalypse and it says that both of these would
: be the same, but if that's the case, then I don't understand how you
: would take items two at a time across multiple streams.
Good question. Maybe we'll just have to require the semicolon. That
would make one less exception, and allow your two-at-a-time-alternately
to work. Though if that's not what they intended, it'd be a subtle bug...
Larry
RE: Perl6 -- what is in a name?
At 01:52 PM 1/28/2002 -0600, Garrett Goebel wrote: >From: Brent Dax [mailto:[EMAIL PROTECTED]] > > Aaron Sherman: > > # > > # I think the first guy that gets hired to maintain Perl6 code, > > # and think "hey, I know Perl, no sweat" will disagree with > > # you. > > > > I disagree. He'll see stuff he doesn't understand and try to > > consult perldoc on it, at which point he'll realize that he's > > working with Perl 6. Then he'll run out, get Camel IV, read > > it, and go back to work. Programmer is working with a better > > version of language, program is fixed, and ORA made fifty > > bucks. Everybody's happy. :^) > >Perhaps. Or perhaps he'll be like our company's lead C++ developers. They >liked Perl4 well enough for a certain problem domain, saw some Perl5 code... >and have tried to stay away from it ever since. > >Perl6 isn't going to make everyone happy. I have a hard time believing those C++ guys are really Perl lovers; I'ver never spoken to a Perl fan that didn't have dreams of a making the language even better than it already is; better OO in Perl, etc. Maybe they just have a huge unwieldy Perl4 app they don't wish to port. -Melvin
Re: Perl6 -- what is in a name?
Melvin Smith writes: : Maybe they just have a huge unwieldy Perl4 app they don't wish to port. The perl5-to-perl6 translator should handle Perl 4 as well. It might even handle Perls 3, 2, and 1. :-) Larry
Re: Apoc4: The loop keyword
Buddha Buck writes:
: We have
: while (foo()) -> $a {...}
: doing the right thing.
Well, C does that currently, not C, but...
: Why can't
:
: if foo() -> $a { ... }
:
: take the place of the perl5
:
: if (my $a = foo()) {...}
I'd do something explicit like ->$a before I'd do some implicit $?
variable, which is gonna give the compiler fits trying to decide if
it has to remember the value or not.
On the other hand, we already have to do something like that for
currying, so if you really want to do that, it's likely that this would
have a similar meaning:
if foo() { print $^a }
In either case, the tricky thing is to pass the value returned by
foo(), not the value returned by foo().true, or whatever the internal
boolean method is.
: Too bad we can't do
:
: while (foo() -> $a) && ($b < 4) { ... }
: and have it do the right thing.
Hey, C still has to be useful for something...
Larry
Re: Perl6 -- what is in a name?
> Perl6 isn't going to make everyone happy. That's right, it isn't. Nor should it strive to. First off, there are the folks who've no clue what Perl even is. Perl 6 won't make them happy. On the other hand, they won't really be disappointed with it, either. But that's a rather silly demographic to use as an illustration. The second group are those that weren't happy with Perl 5. Or Perl 4. Or Perl 3. Perl 6 isn't going to win them over. Sorry. (This may also seem like a silly demographic, but in truth, it's not. People who don't like Perl 5 won't like Perl 6, which kind of demonstrates how similar the two really are.) The third group that won't be happy with Perl 6 are those who program in a limited subset of Perl - so limited, in fact, that they will most likely be bitten by minor changes in the language, without the benefit of experiencing the major improvements that those changes allowed. These people are, by and large, not professional programmers, but folks for whom Perl is a simple and powerful tool in their jobs, and it will drive them crazy when their toolkits and recipes stop working. I should know, I support multitudes of these people. The fourth group will, we should hope, be happy with Perl 6. These are the folks who do program in Perl, and are constantly fighting against limitations, either real or perceived. Some may be happier than others, of course. It all depends on what you consider to be important to you. I do very little structured OO programming, for instance, so a lot of the improvements in that area I will undoubtedly be oblivious to. But as long as I can continue slinging my one- to ten-liners, I'll be content. The final group, those that have yet to discover Perl, are a toss-up. Many of them will hate Perl 6, no matter what name it was called by. But others... they will learn and love Perl 6 the way some of learned and loved Perl 5... or Perl 4... or even Perl 1. So, what *is* in a name? If a rose by any other name would smell just as sweet, why continue to call it a rose? Because identifiers are a proxy for what they represent - an evocation of the object without benefit of having one. Calling them roses allows you to share the sight and smell (and touch!) of the flower, along with the emotions that are inevitably coupled with it. Calling Perl 6 Perl allows those who dislike the thorns to beware, and those that appreciate the beauty to properly care for it. The only people who will probably care - not just comment on it, but truly care - about the name are the people in the third group. But for them, it's usually necessary only to stress the version number as a part of the name. For these people, it isn't just Perl - it's Perl 5. Which Perl 6 is not. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Re: Perl6 -- what is in a name?
[EMAIL PROTECTED] wrote: > The third group that won't be happy with Perl 6 are those who program > in a limited subset of Perl - so limited, in fact, that they will > most likely be bitten by minor changes in the language, without the > benefit of experiencing the major improvements that those changes > allowed. These people are, by and large, not professional > programmers, but folks for whom Perl is a simple and powerful tool in > their jobs, and it will drive them crazy when their toolkits and > recipes stop working. I should know, I support multitudes of these > people. Just out of curiosity, what percentage of Perl users would you say fall into this category? And should follow-ups to this go, perhaps, to [EMAIL PROTECTED]? John A
Re: Perl6 -- what is in a name?
On 1/28/02 9:43 PM, Bryan C. Warnock wrote:
> So, what *is* in a name? If a rose by any other name would smell just as
> sweet, why continue to call it a rose? Because identifiers are a proxy for
> what they represent - an evocation of the object without benefit of having
> one.
Heh, "programmer prose"... ;)
(sub AUTOLOAD { if($AUTOLOAD =~ /::rose/) { ... } })
-John
Re: Re: Perl6 -- what is in a name?
On Monday 28 January 2002 21:54, [EMAIL PROTECTED] wrote: > [EMAIL PROTECTED] wrote: > > The third group that won't be happy with Perl 6 are those who program > > in a limited subset of Perl - so limited, in fact, that they will > > most likely be bitten by minor changes in the language, without the > > benefit of experiencing the major improvements that those changes > > allowed. These people are, by and large, not professional > > programmers, but folks for whom Perl is a simple and powerful tool in > > their jobs, and it will drive them crazy when their toolkits and > > recipes stop working. I should know, I support multitudes of these > > people. > > Just out of curiosity, what percentage of Perl users would you say fall > into this category? I wouldn't. :-) If there's one thing that I have learned in my "travels" throughout the technical world, it's that Perl can and does show up in the strangest of places. And for every use that I've seen, there are probably a hundred more. Another thing that is difficult in classifying the third group is the delineation between Perl and the problem domain. If you use all of the core Perl features strictly to do web page generation, are you using a small or large subset of Perl? From a practical perspective, very little of a computer language is the language itself. I would, however, be so bold to say that these mailing lists are a poor representation of the Perl community at large, and of the group in question specifically. But even if they are a silent majority, do we need to cater to their unspoken requirements? That, ultimately, is *the* question. And the answer already lies within the Perl philosophy of making the hard things easy without making the easy things hard. Most of the minor changes that will affect the casual camel jockey are a change from the simple to the simple. They'll make the occasional mistake. And they'll get frustrated. But the changes won't be difficult to learn. In the meantime, many folks who have struggled to do wondrously difficult things in Perl will now do even more wondrously difficult things - and, what is more, those wondrously difficult things will make what was previously unaccessable available.Or so the theory goes. Of course, then there's Damian, who will reach the point of doing everything that's impossible simultaneously... and in constant time. > > And should follow-ups to this go, perhaps, to [EMAIL PROTECTED]? If we were to discuss *why* it's good for non-professional folks, probably. I'll let someone else cross-post if they feel it's necessary. -- Bryan C. Warnock [EMAIL PROTECTED]
