[28780] in Perl-Users-Digest
Perl-Users Digest, Issue: 24 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Jan 14 00:05:56 2007
Date: Sat, 13 Jan 2007 21:05:02 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 13 Jan 2007 Volume: 11 Number: 24
Today's topics:
Re: Ascii characters in a loop <john@castleamber.com>
Re: Ascii characters in a loop <john@castleamber.com>
Re: Perl free e-books axel@white-eagle.invalid.uk
Re: Unix commands <john@castleamber.com>
Re: Unix commands <john@castleamber.com>
Re: Unix commands <john@castleamber.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 14 Jan 2007 04:10:47 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: Ascii characters in a loop
Message-Id: <Xns98B7E19E790B0castleamber@130.133.1.4>
Mark Donovan <novafyre@hotmail.com> wrote:
> On 1/13/07 16:04, in article rm4o74-cqk.ln1@neptune.markhobley.yi.org,
> "Mark Hobley" <markhobley@hotpop.deletethisbit.com> wrote:
[..]
>> for ($l = 'a'; $l le 'z'; $l++) {
>> print "$l";
>> }
>>
>> I know that a for each loop would work, but that is not what I want.
>>
>
> I think you're expecting: abcdefghijklmnopqrstuvwxyz
>
> And if that's what you want, you must use ne instead of le to end the
> loop.
No, 'aa' Which might confuse a lot of people.
> for ($l = 'a'; $l ne 'z'; $l++) {
> print "$l";
> }
abcdefghijklmnopqrstuvwxy
for ($l = 'a'; $l ne 'aa'; $l++) {
print "$l";
}
abcdefghijklmnopqrstuvwxyz
> If you replace
> print "$l";
> with
> print "$l ";
> you can see what's happening. Change the comparison from le the ne,
> and the loop stops at z,
but doesn't reach the print ;-)
--
John Experienced Perl programmer: http://castleamber.com/
Perl help, tutorials, and examples: http://johnbokma.com/perl/
------------------------------
Date: 14 Jan 2007 04:12:18 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: Ascii characters in a loop
Message-Id: <Xns98B7E1E0AC7EBcastleamber@130.133.1.4>
RedGrittyBrick <RedGrittyBrick@SpamWeary.foo> wrote:
> Oh yes,
>
> Why exactly don't you want a foreach loop?
My guess: because he wants to know why this one "doesn't work" instead of
reading: "use this instead".
To me it was educational (as in if someone has asked to write that loop
like that I am sure it would have bitten me as well), so thanks OP :-)
--
John Experienced Perl programmer: http://castleamber.com/
Perl help, tutorials, and examples: http://johnbokma.com/perl/
------------------------------
Date: Sun, 14 Jan 2007 03:43:41 GMT
From: axel@white-eagle.invalid.uk
Subject: Re: Perl free e-books
Message-Id: <NFhqh.85596$lD5.72919@newsfe14.phx>
solomonrex <mwidrick@gmail.com> wrote:
> PDF beginner's book here. Just to be clear, unless you have experience
> with regular expressions in Linux/Unix already, Perl isn't great to
> start with (can you understand
> s/\(^[0-9]*\).*/\1
> ?). If you have that experience, Perl is great to start with.
How many people who use Perl had experience of using ex/vi regular
expressions before they started Perl?
> http://www.perl.org/books/beginning-perl/
> And I don't understand the top-posting Nazis. This isn't a dinner
> table, it's a street corner and Google owns it.
Google does not own or administer Usenet, but is just one of thousands
of news servers in the world.
Axel
------------------------------
Date: 14 Jan 2007 03:38:20 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: Unix commands
Message-Id: <Xns98B7DC1D0828Ecastleamber@130.133.1.4>
Andrew DeFaria <Andrew@DeFaria.com> wrote:
> John Bokma wrote:
>>> Finding it by hand I take it you mean when I said:
>>>
>>> Because 1) it's inefficient in that you are forking and exec'ing a
>> No, the part before it:
> But I didn't write anything before it.
But I did:
"Maybe reread "<X5CdnYE4KLbIpDXYnZ2dnUVZ_rHinZ2d@comcast.com>" were I
"clearly wrote: "Depends on what you're doing of course.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
After that I wrote a kind of rhetorical part: "Why would I copy a program
that does already its work perfectly and reinvent the wheel?"
To which you replied (paraphrased): fork overhead & non-portable
Maybe you want to carefully (this time) read
<slrneqirua.ge.abigail@alexandra.abigail.be>?
>> Yes, it sounded silly. It still does. Like I said: it depends on what
>> you're doing. The fork overhead and the portability, if you know what
>> you're doing, might be considered a small price to pay for not
>> inventing the wheel again.
> And it might not. You asked a question. Why would you do that? I gave
> you an answer. Because it's more portable and efficient.
Regarding the former: if the program is not available there is no way the
external program does its work perfectly of course.
Now regarding efficiency: that's also not an easy thing to answer for many
reasons. As far as I know (but I am quite out of it to be honest) the
overhead of forking has been reduced a lot over the years, also because
forking is very common. Moreover, on Windows (again as far as I know, I
might be very wrong here) forking is emulated by threading with (again
that disclaimer) way less overhead compared to a classic *nix fork.
However: if efficiency is that big an issue probably you shouldn't have
opted for Perl in the first place.
> Does that mean
> there are no situations where the overhead and portability are not
> important?
Of course there are, but I excluded your portability argument by asking
"why ... its work perfectly" which (work) a non-available program can't
do.
As for the overhead, you might be right in some circumstances, but in that
case I agree with Abigail: you shouldn't have picked Perl in the first
place.
> No. There are exceptions to every rule. So what! Why would
> people do it? Sometimes (not every time) they are concerned about being
> portable or being efficient. The real question is why is this so
> difficult for you to understand!
Again, if the overhead of fork forces you to copy a well working program
in Perl you're very likely on the wrong track to begin with. Hourly rates
of skilled Perl programmers exceed the price of a faster computer in a
short time. Using an external program in a way outsources part of the
solution you're working on. And in many cases the external program has
been more widely tested then you can manage on your own.
And if the bottleneck is that serious that the faster hardware is so
expensive that its ok for you to copy an external program into Perl then I
am very sure Perl was a bad choice.
> Oh. I see. So you read into my posts whatever you want using words,
> phrases and ideas that I just didn't say just because "that's how I read
> your posts". There's a word for that. It's called strawman!
Only if I severely misrepresent your argument. After carefully rereading
your attacks (since that's how I read them, which again is not a strawman)
I am even more convinced that I am right.
>> If people state that there are plenty of situations one can call an
>> external program because fork overhead and
>> portability (or lack off) are a non-issue you call them lazy,
> Actually they called themselves lazy and tried to say it's OK because
> Larry Wall says so.
There is nothing wrong with being lazy. It stops one very often from doing
stupid things :-D.
>> incompetent and start a pissing contest.
> When I have to constantly re-write other people's code because they
> consciously made it non-portable and inefficient you betcha I'm
> thinking, lazy, incompetent programmers... I really don't think I'm
> alone in this.
Sure, every programmer calls the work of many others utter crap. And very
often they are right. But there are also programmers who think that
because they have seen it used wrong in many cases that there is a need to
educate other programmers even when those other programmers clearly have a
very good argument why they are using it in the first place.
I am not a big fan of "foo considered harmful" when it's written like it's
against the law. To me programming is about flexibily and freedom of
expressing oneself. Creativity and such. IMNSHO you tried to make a too
strong case against calling external programs missing a bit what I
originally wrote.
--
John Experienced Perl programmer: http://castleamber.com/
Perl help, tutorials, and examples: http://johnbokma.com/perl/
------------------------------
Date: 14 Jan 2007 03:40:32 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: Unix commands
Message-Id: <Xns98B7DC7DD269Dcastleamber@130.133.1.4>
Andrew DeFaria <Andrew@DeFaria.com> wrote:
> Oh you mean some people don't like it. I know. I don't agree with
> them.
In short you're ignoring the guidelines of a technical group because
you're a loser.
--
John Experienced Perl programmer: http://castleamber.com/
Perl help, tutorials, and examples: http://johnbokma.com/perl/
------------------------------
Date: 14 Jan 2007 04:02:14 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: Unix commands
Message-Id: <Xns98B7E02AA9966castleamber@130.133.1.4>
Andrew DeFaria <Andrew@DeFaria.com> wrote:
> John Bokma wrote:
>>> Calling `ls /path/file` certainly is in that ls is not guaranteed to
>>> be there
>> where?
>
> Available for execution.
Like the perl executable is not guaranteed to be available for
execution? Tell me something new.
>>> nor is it guaranteed that "/" a valid directory separator.
>> nor is it guaranteed that there is a perl executable, nor is it
>> guaranteed that it's the version you're expecting. Nor is it
>> guaranteed that your Perl program doesn't trigger a platform specific
>> bug in Perl or the modules you're using. Comes with the job.
> Right. We have much to be concerned about. Let's not start adding new
> problems...
My point. If the external program does perfectly its work (my
prerequisite) then it's available for execution.
>> Nor is installing ls (for example) an impossible hurdle. If it is,
>> then it was implied by the requirements of the job, and I wouldn't
>> have chosen that solution (if it was already apropriate in the first
>> place). What is it you don't get?
>
> What I don't get is why you insist on adding more dependencies...
Your mistaken (no that's not something new). Instead of copying
perfectly working (prerequisite) functionality to Perl, I decided to use
the aforementioned external program. Or does the program not depend on
the functionality if you write it yourself?
>> Fine with me. You understand that "Depends on what you're doing" was
>> a reply to "It's generally preferable to use Perl when you write Perl
>> programs."
> Which were not my words. Perhaps you should argue with that guy. BTW I
> happen to agree with him.
Yes, and hence I argue with you. Moreover you just confirmed that I was
right with my reading between the lines instead of using a straw man
:-D (not a surprise there).
>> I disagree with that. There are plenty of examples that in my opinion
>> an external program is preferable. Perl is amongst others a glue
>> language.
> Great. Tell it to that guy...
This is Usenet. You jumped in (agree with him), so I discuss with you
and am aware that as a side effect I might reach David as well.
>>> Fork overhead and non-portability are legitimate concerns.
>> In some situations yes. In plenty of others no. Like I wrote (again):
>> "Depends on what you're doing"
> I was specifically answering a question that you posed about a
> specific set of examples. One example was using "ls".
It's you who should read better.
"
>>"It's generally preferable to use Perl when
>> you write Perl programs.
> Depends on what you're doing of course. Why would I copy a program
> that does already its work perfectly and reinvent the wheel?
"
How that can refer to a specific set of examples is a bit beyond me.
Maybe you can clarify?
> So, is it better
> to use "ls" or do it using opendir, etc.?
"Depends on what you're doing of course."
If you need an example, Abigail mentioned one involving grep. I know,
it's not ls and I hope you can live with that.
>> I quote the whole thing again:
>>
>> "
>>>> It's generally preferable to use Perl when you write Perl programs.
> Which, again, is something that I didn't write!
But like I said earlier, you seem to agree with it (I wrote something
along "read it between the lines"). You just confirmed that you *do*
agree with it (few paragraphs up). I disagree with "generally
preferable" which sounds to me too much like: "Using external programs
from Perl programs considered harmful". People (like you, I am afraid)
take it too serious.
Also, if you agree with someone, and jump into a public discussion,
don't be so amazed that people start to agree or disagree with you. This
is Usenet, remember.
>>> Depends on what you're doing of course. Why would I copy a program
>>> that does already its work perfectly and reinvent the wheel?
>>> Increase development time, and make many mistakes while doing so?
>> Because 1) it's inefficient in that you are forking and exec'ing a
>> process to do it and 2) portability - there's no guarantee that the
>> next platform you port this to has the same commands. For example,
>> you use "ls" above. But there is no "ls" under Windows. If instead
>> you use a more Perl like way your Perl script will immediately port
>> without and issue.
>> "
>>
>> My "Depends..." was a comment on the "generally ... use Perl ...
>> write Perl". You seemed to be trying to make a point by staring
>> yourself blind on ls.
> Indeed however the part that I wrote was obviously directed at your
> question about why somebody would do such a thing. A "because" is an
> answer to a "why" question, not an answer to a "depends" statement.
If you write a Perl program that has to be portable "a [external]
program that does already its work perfectly" implies that it's
available. So your second point (portability) is void, unless you want
to imply that every Perl program has to be written portable because you
can.
As for your first point: I have a gut feeling that fork overhead is
overrated and in cases it plays an important role it might be very well
the case that Perl itself is an option, making your first point somewhat
void as well.
> I take it that English is not your first language...
Yet I seem to have less problems with it. But even if you're right,
we're talking about programming here.
--
John Experienced Perl programmer: http://castleamber.com/
Perl help, tutorials, and examples: http://johnbokma.com/perl/
------------------------------
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 24
*************************************
