[30258] in Perl-Users-Digest
Perl-Users Digest, Issue: 1501 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri May 2 00:09:42 2008
Date: Thu, 1 May 2008 21:09:08 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 1 May 2008 Volume: 11 Number: 1501
Today's topics:
Re: Frequency in large datasets <uri@stemsystems.com>
Re: Frequency in large datasets <someone@example.com>
Re: Frequency in large datasets <uri@stemsystems.com>
Re: Frequency in large datasets <XXjbhuntxx@white-star.com>
Re: Help: Replace Help <szrRE@szromanMO.comVE>
Re: Help: Replace Help (Ben Bullock)
Re: Help: Replace Help <1usa@llenroc.ude.invalid>
Re: Help: Replace Help (Ben Bullock)
Re: Help: Replace Help <1usa@llenroc.ude.invalid>
Re: Read 20 lines when pressing n for next <get@bentsys.com>
Re: Read 20 lines when pressing n for next <get@bentsys.com>
Re: Stuffing @users into $self->{'users'} <syscjm@sumire.gwu.edu>
Re: Stuffing @users into $self->{'users'} <szrRE@szromanMO.comVE>
Re: Stuffing @users into $self->{'users'} <szrRE@szromanMO.comVE>
Re: Will Perl 6 be usable as a procedure language? <cwilbur@chromatico.net>
Re: Will Perl 6 be usable as a procedure language? <usenet@larseighner.com>
Re: Will Perl 6 be usable as a procedure language? <szrRE@szromanMO.comVE>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 01 May 2008 18:38:49 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Frequency in large datasets
Message-Id: <x7wsmdyime.fsf@mail.sysarch.com>
>>>>> "ASU" == A Sinan Unur <1usa@llenroc.ude.invalid> writes:
ASU> nolo contendere <simon.chao@fmr.com> wrote in
ASU> news:1aa7f96f-7458-4d3a-9c1c-ff437dfeec41@b64g2000hsa.googlegroups.com:
>> On May 1, 7:26 am, "A. Sinan Unur" <1...@llenroc.ude.invalid> wrote:
>>> benkasminbull...@gmail.com (Ben Bullock) wrote
>>> innews:fvbj3s$l7u$1@ml.accs
>> net.ne.jp:
>>>
>>> > A. Sinan Unur <1...@llenroc.ude.invalid> wrote:
>>>
>>> Hope this helps you become more comfortable with the notion that
>>> reading a 47 GB file is a boneheaded move. It is boneheaded if I do
>>> it, if Larry Wall does it, if Superman does it ... you get the
>>> picture I hope.
>>>
>>
>> I don't think it would be boneheaded if Superman did it...I mean, he's
>> SUPERMAN.
ASU> But attempting to slurp a 47 GB files is the equivalent of having a
ASU> cryptonite slurpee in the morning.
ASU> Not good.
ASU> ;-)
and i wouldn't even recommend file::slurp for that job!! :)
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Thu, 01 May 2008 18:43:20 GMT
From: "John W. Krahn" <someone@example.com>
Subject: Re: Frequency in large datasets
Message-Id: <cboSj.3398$PM5.1321@edtnps92>
A. Sinan Unur wrote:
> nolo contendere <simon.chao@fmr.com> wrote in
> news:1aa7f96f-7458-4d3a-9c1c-ff437dfeec41@b64g2000hsa.googlegroups.com:
>
>> On May 1, 7:26 am, "A. Sinan Unur" <1...@llenroc.ude.invalid> wrote:
>>> benkasminbull...@gmail.com (Ben Bullock) wrote
>>> innews:fvbj3s$l7u$1@ml.accs
>> net.ne.jp:
>>>> A. Sinan Unur <1...@llenroc.ude.invalid> wrote:
>>> Hope this helps you become more comfortable with the notion that
>>> reading a 47 GB file is a boneheaded move. It is boneheaded if I do
>>> it, if Larry Wall does it, if Superman does it ... you get the
>>> picture I hope.
>>>
>> I don't think it would be boneheaded if Superman did it...I mean, he's
>> SUPERMAN.
>
> But attempting to slurp a 47 GB files is the equivalent of having a
> cryptonite slurpee in the morning.
s/cryptonite/kryptonite/;
John
--
Perl isn't a toolbox, but a small machine shop where you
can special-order certain sorts of tools at low cost and
in short order. -- Larry Wall
------------------------------
Date: Thu, 01 May 2008 18:44:45 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Frequency in large datasets
Message-Id: <x763txyici.fsf@mail.sysarch.com>
>>>>> "JWK" == John W Krahn <someone@example.com> writes:
JWK> A. Sinan Unur wrote:
>>> I don't think it would be boneheaded if Superman did it...I mean, he's
>>> SUPERMAN.
>> But attempting to slurp a 47 GB files is the equivalent of having a
>> cryptonite slurpee in the morning.
JWK> s/cryptonite/kryptonite/;
what if the 47 GB was enkrypted? (sic :)
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Fri, 02 May 2008 03:26:37 GMT
From: Cosmic Cruizer <XXjbhuntxx@white-star.com>
Subject: Re: Frequency in large datasets
Message-Id: <Xns9A91CFD6D5B3Dccruizermydejacom@207.115.33.102>
Cosmic Cruizer <XXjbhuntxx@white-star.com> wrote in
news:Xns9A90D0E1FD16ccruizermydejacom@207.115.17.102:
> Gunnar Hjalmarsson <noreply@gunnar.cc> wrote in
> news:67so01F2nertiU1@mid.individual.net:
>
>> Cosmic Cruizer wrote:
>>> I've been able to reduce my dataset by 75%, but it still leaves me
>>> with a file of 47 gigs. I'm trying to find the frequency of each line
>>> using:
>>>
>>> open(TEMP, "< $tempfile") || die "cannot open file
>>> $tempfile:
>>> $!";
>>> foreach (<TEMP>) {
>>> $seen{$_}++;
>>> }
>>> close(TEMP) || die "cannot close file
>>> $tempfile: $!";
>>>
>>> My program keeps aborting after a few minutes because the computer
>>> runs out of memory.
>>
>> This line:
>>
>>> foreach (<TEMP>) {
>>
>> reads the whole file into memory. You should read the file line by
>> line instead by replacing it with:
>>
>> while (<TEMP>) {
>>
>
><sigh> As both you and Sinan pointed out... I'm using foreach.
Everywhere
> else I used the while statement to get me to this point. This solves
the
> problem.
>
> Thank you.
Well... that did not make any difference at all. I still get up to about
90% of the physical ram and the job aborts within about the same
timeframe. From what I can tell, using while did not make any difference
than using foreach. I tried using the two swapfiles idea, but that is not
a viable solution. I guess the only thing to do is to break the files
down into smaller chunks of about 5 gigs each. That will give me about 3
to 4 days worth of data at a time. After that, I can look at what I have
and decide how I can optimize the data for the next run.
------------------------------
Date: Thu, 1 May 2008 18:21:47 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: Help: Replace Help
Message-Id: <fvdqbb02b1e@news4.newsguy.com>
A. Sinan Unur wrote:
[...]
> Clearly, by posting a question here, you are asking for help.
I disagree that, in general, by simply posting, one is seeking help. One
could just as well be seek a discussion, or insight on something, but
not necessarily assistance. After all, this /is/ a *discussion* group
:-)
--
szr
------------------------------
Date: Fri, 2 May 2008 01:40:04 +0000 (UTC)
From: benkasminbullock@gmail.com (Ben Bullock)
Subject: Re: Help: Replace Help
Message-Id: <fvdrdk$8la$1@ml.accsnet.ne.jp>
A. Sinan Unur <1usa@llenroc.ude.invalid> wrote:
> Ben Bullock <benkasminbullock@gmail.com> wrote
>> If the strings to swap are longer than a single character,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> s/A/unlikely/g;
>> s/C/A/g;
>> s/unlikely/C/g;
>> s/G/unlikely/g;
>> s/U/G/g;
>> s/unlikely/U/g;
>>
>> where "unlikely" is a string which is unlikely to occur in your data.
>
> A simple lookup table driven solution would obviate the need to make
> assumptions about the unlikeliness of a given character as well as
> getting rid of the multiple substitutions.
And a simple tr/// based solution would obviate the need to for you to
write a lookup table solution. But if the strings to swap are longer than
a single character, the lookup table solution is going to be somewhat
complex.
Here is an example of a badly-written lookup table solution:
#!/usr/bin/perl
use strict;
use warnings;
my %subst = qw( A C C A G U U G );
my @strings = qw( ACGU GUACCGU );
print "Before:\t@strings\n";
s/([ACGU])/$subst{$1}/g for @strings;
print "After\t@strings\n";
__END__
The problem here is that the writer has put the same data, the list of
stuff to swap, in three different places. Maybe that kind of clumsy
solution is OK for an example program, but for the real world it's
not. If one uses a lookup table, then the swapping data should only be
in exactly one place:
my %subst = qw/A C G U/; # Do not repeat this data anywhere!!!!!
%subst = (%subst, reverse %subst);
my $substkeys = join ('|',keys %subst); # We want to swap strings so use |
my @strings = qw( ACGU GUACCGU );
s/($substkeys)/$subst{$1}/g for @strings;
If one uses the original solution proposed above, as the list of data
to swap changes, (and since the strings consist of more than one
character, remember), bugs will occur if the programmer is not
extremely careful about updating both parts of the list of stuff to
swap and the left hand side of the substitution.
So I don't recommend a lookup table, unless one knows what one is doing.
------------------------------
Date: Fri, 02 May 2008 02:16:04 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Help: Replace Help
Message-Id: <Xns9A91E284D74Aasu1cornelledu@127.0.0.1>
benkasminbullock@gmail.com (Ben Bullock) wrote in
news:fvdrdk$8la$1@ml.accsnet.ne.jp:
> A. Sinan Unur <1usa@llenroc.ude.invalid> wrote:
>> Ben Bullock <benkasminbullock@gmail.com> wrote
>
>>> If the strings to swap are longer than a single character,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> s/A/unlikely/g;
>>> s/C/A/g;
>>> s/unlikely/C/g;
>>> s/G/unlikely/g;
>>> s/U/G/g;
>>> s/unlikely/U/g;
>>>
>>> where "unlikely" is a string which is unlikely to occur in your
>>> data.
>>
>> A simple lookup table driven solution would obviate the need to make
>> assumptions about the unlikeliness of a given character as well as
>> getting rid of the multiple substitutions.
>
> And a simple tr/// based solution would obviate the need to for you to
> write a lookup table solution. But if the strings to swap are longer
> than a single character, the lookup table solution is going to be
> somewhat complex.
Granted.
> Here is an example of a badly-written lookup table solution:
>
<snipped for brevity>
>
> The problem here is that the writer has put the same data, the list of
> stuff to swap, in three different places. Maybe that kind of clumsy
> solution is OK for an example program,
and that was the spirit in which those lines were written.
> but for the real world it's not. If one uses a lookup table, then the
> swapping data should only be in exactly one place:
>
> my %subst = qw/A C G U/; # Do not repeat this data anywhere!!!!!
> %subst = (%subst, reverse %subst);
> my $substkeys = join ('|',keys %subst); # We want to swap strings so use |
> my @strings = qw( ACGU GUACCGU );
> s/($substkeys)/$subst{$1}/g for @strings;
>
> If one uses the original solution proposed above, as the list of data
> to swap changes, (and since the strings consist of more than one
> character, remember), bugs will occur if the programmer is not
> extremely careful about updating both parts of the list of stuff to
> swap and the left hand side of the substitution.
>
> So I don't recommend a lookup table, unless one knows what one is
> doing.
Well, if one uses the solution you proposed above and the list of data
to swap changes to
my %subst = qw( A|C C|A G|U U|G );
there will be issues with the way you build the search string.
So:
#!/usr/bin/perl
use strict;
use warnings;
my %replace = qw( A|C C|A G|U U|G A$A Z$Z);
%replace = (%replace, reverse %replace);
my $search = join ('|', map { "(?:\Q$_\E)" } keys %replace);
my @strings = qw( A|C G|U G|UA|CC|AG|U Z$Z A$A );
print "Before:\t@strings\n";
s/($search)/$replace{$1}/g for @strings;
print "After\t@strings\n";
__END__
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Fri, 2 May 2008 02:32:15 +0000 (UTC)
From: benkasminbullock@gmail.com (Ben Bullock)
Subject: Re: Help: Replace Help
Message-Id: <fvduff$96d$1@ml.accsnet.ne.jp>
A. Sinan Unur <1usa@llenroc.ude.invalid> wrote:
> Well, if one uses the solution you proposed above and the list of data
> to swap changes to
>
> my %subst = qw( A|C C|A G|U U|G );
>
> there will be issues with the way you build the search string.
> my $search = join ('|', map { "(?:\Q$_\E)" } keys %replace);
So you agree that the lookup table driven solution isn't simple?
I think my original method of substituting in an unlikely string,
which you objected to, was fairly appropriate for this particular
question. I often use this kind of method for quick jobs.
------------------------------
Date: Fri, 02 May 2008 02:50:43 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Help: Replace Help
Message-Id: <Xns9A91E86529A73asu1cornelledu@127.0.0.1>
benkasminbullock@gmail.com (Ben Bullock) wrote in
news:fvduff$96d$1@ml.accsnet.ne.jp:
> A. Sinan Unur <1usa@llenroc.ude.invalid> wrote:
>
>> Well, if one uses the solution you proposed above and the list of
>> data to swap changes to
>>
>> my %subst = qw( A|C C|A G|U U|G );
>>
>> there will be issues with the way you build the search string.
>
>> my $search = join ('|', map { "(?:\Q$_\E)" } keys %replace);
>
> So you agree that the lookup table driven solution isn't simple?
>
> I think my original method of substituting in an unlikely string,
> which you objected to, was fairly appropriate for this particular
> question. I often use this kind of method for quick jobs.
Yes. That was the first thing in my response: 'Granted'.
OTOH, the number of repeated substitution operations which the 'unlikely
string' approach requires (especially as the number of
lookups/replacements grows) makes me think that the more complex
approach might end up being simpler to maintain for any 'durable'
program.
Thank you for your corrections.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Thu, 1 May 2008 20:25:46 -0700
From: "Gordon Etly" <get@bentsys.com>
Subject: Re: Read 20 lines when pressing n for next
Message-Id: <67vftrF2qba7rU1@mid.individual.net>
Uri Guttman wrote:
> Gordon Etly <get@bentsys.com> writes:
>
> > > > > > 1. open any text file taken the name from the command line.
> > > > > > 2. read top 20 lines and stops, then
> > > > > > 3. ask to press letter "n or p" (for next/previous) to print
> > > > > > next
> > > > > > or previous 20 lines.
> > > > > > would appreciate any kind of help.
> > > > > > 4. must have subroutine used.
>
> > Why do you all just assume it's a homework assignment? Could it
> > not just as well be a simplified work project? I would not be at
> > all surprised if this was something handed down by one's boss or
> > project manager, and written in a simplified form (which is what
> > one *should* do, no?) I really see little point to make such an
> > assumption, and I'm sure no one likes being talked down to.
>
> gack, you again? having done a bit of perl, written requirements and
> assigned tasks, i would have never said 'must use a subroutine'. that
> plus the wording of the other requirements reeks of homework.
It could be homework, just as it could be any number of things. Could
just be how the OP put together his post, listing what he wanted to do.
The point is _you_ _don't_ _know_.
--
G.Etly
------------------------------
Date: Thu, 1 May 2008 20:28:38 -0700
From: "Gordon Etly" <get@bentsys.com>
Subject: Re: Read 20 lines when pressing n for next
Message-Id: <67vg37F2qvirdU1@mid.individual.net>
Sherman Pendley wrote:
> "Gordon Etly" <get@bentsys.com> writes:
...
> > Why do you all just assume it's a homework assignment?
>
> Read step four: "Must have subroutine used."
>
> It doesn't take a psychic or a genius to identify homework when it has
> requirements like that.
>
> > Could it not just as well be a simplified work project? I
> > would not be at all surprised if this was something handed
> > down by one's boss or project manager, and written in a
> > simplified form (which is what one *should* do, no?)
>
> Uh - no. The point of hiring a professional programmer is that the
> manager should *not* have to write detailed, trivial instructions
> like "be sure to use subroutines." One gets that kind of assignment
> at school, but at work one is expected to know how to do the job
> without all the hand-holding.
You could be surprised at how clueless some mangers/bosses can be. Never
underestimate that.
--
G.Etly
------------------------------
Date: Thu, 01 May 2008 15:04:22 -0500
From: Chris Mattern <syscjm@sumire.gwu.edu>
Subject: Re: Stuffing @users into $self->{'users'}
Message-Id: <slrng1k8i5.ss8.syscjm@sumire.gwu.edu>
On 2008-05-01, J. Gleixner <glex_no-spam@qwest-spam-no.invalid> wrote:
> Philluminati wrote:
>
>> package user_management;
>
> Generally you don't want a lower case name for your package.
>
>>
>> use user;
>> #use strict;
>
> Why comment that out?
>
Dealing with errors raised by strict by commenting out "use strict;"
is like dealing with a bleeding wound by closing your eyes so you
don't have to look at the blood any more.
--
Christopher Mattern
NOTICE
Thank you for noticing this new notice
Your noticing it has been noted
And will be reported to the authorities
------------------------------
Date: Thu, 1 May 2008 20:05:29 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: Stuffing @users into $self->{'users'}
Message-Id: <fve0dp02jmc@news4.newsguy.com>
A. Sinan Unur wrote:
> Philluminati <Phillip.Ross.Taylor@gmail.com> wrote in news:661262f3-
> aea5-4734-906e-7062d77f201f@m44g2000hsc.googlegroups.com:
>
>> my @users = ref $self->{'users'}; //same message as above
>> my @users = @$self->{'users'};
>> my @users = \$self->{'users'};
>> my @users = map $self->{'users'}; //gave 500 internal server err
>> my @users = ( $self->{'users'} ); //same as original err
>> my @users = scalar $self->{'users'};
>
> You are ignoring the fact that programming is a deterministic
> endeavor. Successful programmers are not those who throw a bazillion
> variations at a wall and see what sticks.
Isn't also about trial and error? Especially, but not limited to, people
who are young in this field of study? How does one learn something if
they do not run some tests? That is more or less how I advanced so deep
into programming many moons ago, trying to see if this works, what this
that do, what happens if I do this, etc. Albeit, one should keep
documentation close by too, but trial and error *is* a as big a part as
anything IMHO.
--
szr
------------------------------
Date: Thu, 1 May 2008 20:15:13 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: Stuffing @users into $self->{'users'}
Message-Id: <fve10202ku1@news4.newsguy.com>
Chris Mattern wrote:
> On 2008-05-01, J. Gleixner <glex_no-spam@qwest-spam-no.invalid> wrote:
>> Philluminati wrote:
>>
>>> package user_management;
>>
>> Generally you don't want a lower case name for your package.
>>
>>>
>>> use user;
>>> #use strict;
>>
>> Why comment that out?
>>
> Dealing with errors raised by strict by commenting out "use strict;"
> is like dealing with a bleeding wound by closing your eyes so you
> don't have to look at the blood any more.
Maybe a better analogy would be putting tape over the warning lights
(check engine, ...) in your car.
--
szr
------------------------------
Date: Thu, 01 May 2008 16:04:41 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Will Perl 6 be usable as a procedure language?
Message-Id: <86od7p94fa.fsf@mithril.chromatico.net>
>>>>> "bb" == bugbear <bugbear@trim_papermule.co.uk_trim> writes:
bb> Peter Scott wrote:
>> Are you thinking that Perl 6 is intended to be backwards
>> compatible with Perl 5? It isn't, and it won't be.
bb> Oh. That's a bit of a surprise.
It shouldn't be -- one of the initial decisions relating to Perl 6 was
that this was a chance to fix all of the problems resulting from the
decision to make Perl 5 as backwards-compatible as possible.
It seems to me that the Perl 4 to Perl 5 decision was, after more than
a decade of distance, mostly correct. I get the sense that the Perl 5
to Perl 6 decision triggered a massive case of second system syndrome,
which is why it's taking so long; but what I've seen backported to
Perl 5 makes me think it will be a great language when it finally gets
here. It just won't be Perl 5.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Thu, 01 May 2008 16:13:58 -0500
From: Lars Eighner <usenet@larseighner.com>
Subject: Re: Will Perl 6 be usable as a procedure language?
Message-Id: <slrng1kcgd.2ofd.usenet@debranded.larseighner.com>
In our last episode,
<bb9e4723-a2d9-4517-bdfb-aa73715281ac@r66g2000hsg.googlegroups.com>, the
lovely and talented nolo contendere broadcast on comp.lang.perl.misc:
> On May 1, 1:40 pm, xhos...@gmail.com wrote:
>> nolo contendere <simon.c...@fmr.com> wrote:
>> > On May 1, 1:12=A0am, Lars Eighner <use...@larseighner.com> wrote:
>> > > Will perl 6 be usable as a procedure language?
>>
>> > What _exactly_ do you mean by 'procedure language'?
>>
>> I think he means "Not object oriented"
> But can't one author code either procedurally or OO in the same
> language?
In some languages, yes (for example perl 5). In other, e.g. Java, not in any
practical sense.
> (This may not be the authority, but):
> "The most popular programming languages usually have both OOP and
> procedural aspects."
> http://en.wikipedia.org/wiki/Procedural_programming#Comparison_with_object-oriented_programming
> Perhaps the most popular language used for OOP is Java, but you can
> write procedural code in Java if you wanted, correct?
Not really.
> I was hoping that the OP could list the exact criteria he was using for
> determining the answer to his question.
Can you write code without objects, object wrappers, etc. and use functions
and subroutines instead? Can you make function calls without object-like
notation (i.e. little arrows made of hyphens and inequality signs pointing
in counter-intuitive directions)? Are you bound to use some basic set of
objects which don't do what you want and you cannot edit? Will it be
incredibly slow and inefficient?
--
Lars Eighner <http://larseighner.com/> usenet@larseighner.com
Countdown: 263 days to go.
------------------------------
Date: Thu, 1 May 2008 18:09:34 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: Will Perl 6 be usable as a procedure language?
Message-Id: <fvdpkf02a6n@news4.newsguy.com>
Peter Scott wrote:
[...]
> Are you thinking that Perl 6 is intended to be backwards compatible
> with Perl 5? It isn't, and it won't be.
While Perl 6 has it's merits, this alone doesn't really inspire me to an
all out switch when it finally comes, and given how much code would be
broken, I wouldn't be surprised if it ends up having a poor adoption
rate for the first year or two because of this, as Perl 5.10 adds some
of the Perl 6-destined features (like given/when) and still promotes
backwards compatibility (and in a very intelligent and un-intrusive way)
and future releases are likely to only be better.
So given this, why would one, who have plenty of Perl code, feel
compelled to choose Perl 6 over Perl 5 and spend what could huge amounts
of time rewriting a lot of code?
--
szr
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 1501
***************************************
