[13118] in Perl-Users-Digest
Perl-Users Digest, Issue: 528 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Aug 14 16:17:23 1999
Date: Sat, 14 Aug 1999 13:10:13 -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 Sat, 14 Aug 1999 Volume: 9 Number: 528
Today's topics:
Re: printing vars <bwalton@rochester.rr.com>
Re: printing vars <rick.delaney@home.com>
Re: printing vars <cassell@mail.cor.epa.gov>
Udate file using another file <rvdd@iafrica.com>
Re: Updating Tables using two seperate files <bwalton@rochester.rr.com>
Re: Updating Tables using two seperate files <rvdd@iafrica.com>
Re: What happened to Perl in 1990? <cassell@mail.cor.epa.gov>
Re: Why use comp.lang.python when you've got comp.lang. <tismer@appliedbiometrics.com>
Re: Why use Perl when we've got Python?! (Michael Rubenstein)
Re: Why use Perl when we've got Python?! (John Stevens)
Re: Why use Perl when we've got Python?! (John Stevens)
Re: Why use Perl when we've got Python?! (John Stevens)
Re: Why use Perl when we've got Python?! (John Stevens)
Re: Why use Perl when we've got Python?! <dgris@moiraine.dimensional.com>
Re: Why use Perl when we've got Python?! (John Stevens)
Re: Why use Perl when we've got Python?! <tchrist@mox.perl.com>
Re: Why use Python when we've got Perl? <cassell@mail.cor.epa.gov>
Digest Administrivia (Last modified: 1 Jul 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 14 Aug 1999 14:15:58 -0400
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re: printing vars
Message-Id: <37B5B25E.80EBA972@rochester.rr.com>
ted fiedler wrote:
> with this:
>
> open(NAS,"names");
After an open, be sure to check to see if it worked or not, as in:
open NAS,"names" or die "Oops, $!";
>
> open(ACS,"accounts");
> open(DBREADY,"> data.mrg");
> @name=<NAS>;
Add:
chomp @name;
unless you really want the newline at the end of each name.
>
> foreach $name(@name) {
> if( /^name/) {
> s/name//;
Above, your loop reference variable is $name. You are, however, testing
and modifying $_. Try:
for(@name){
s/name // if /^name /;
You probably want a space character after "name" so you don't get that
in your output.
>
> }
> }
> @account=<ACS>;
chomp @account;
>
> foreach $account(@account) {
> if( /^account/) {
> s/account//;
Same here -- get rid of the $account in the foreach statement, add a
space after "account".
>
> }
> }
> print"@name,@account\n";
You need to modify your print -- what you have will just output what is
left in the "name" array followed by what is left in the "account"
array. Maybe something like:
for(@name){
print "$_,$account[$i++]\n";
}
>
>
> I am reading from a file that looks like this:
>
> name john doe
> name ed doe
> name joe doe
> account 123
> account 234
> account 456
I assume from your code that the name data is in file "names" and the
account data is in file "accounts". If it is all in one file, you will
need to open only one input file, and will need to process names from
the "name" records and accounts from the "account" records.
>
>
> in this file there are always the same number of names as accounts
> i need my output to look liike this:
>
> john doe,123
> ed doe,234
> joe doe,456
>
> instead it looks like this:
>
> name john doe
> name ed doe
> name joe doe
> account 123
> account 234
> account 456
The above fixes should give you what you want.
------------------------------
Date: Sat, 14 Aug 1999 18:19:54 GMT
From: Rick Delaney <rick.delaney@home.com>
Subject: Re: printing vars
Message-Id: <37B5B32F.8A435275@home.com>
[posted & mailed]
ted fiedler wrote:
>
> with this:
>
> open(NAS,"names");
> open(ACS,"accounts");
> open(DBREADY,"> data.mrg");
You really should check the success of all those opens.
> @name=<NAS>;
> foreach $name(@name) {
> if( /^name/) {
> s/name//;
> }
There is no need to test for the pattern before you replace it since it
won't be replaced unless it matches.
s/^name//;# would do
[snip]
> print"@name,@account\n";
This will print all the names followed by all the accounts. What you
want is to print each name followed by each account. So use foreach.
foreach (0 .. $#name) {
print "$name[$_],$account[$_]\n";
}
Of course, you will want to chomp the newlines off of the names and
accounts first.
Also, it's not very scalable to large files to process them in arrays.
You could instead process the files a line at a time.
use strict;
my $err = "Files weren't the same size\n";
open(NAS, 'names') or die "NAS: $!";
open(ACS, 'accounts') or die "ACS: $!";
while(<NAS>) {
chomp;
my $name = $_;
$name =~ s/^name\s*//;
my $account = <ACS>;
die $err unless defined $account;
$account =~ s/^account\s*//;
print "$name,$account";
}
die $err unless eof ACS;
--
Rick Delaney
rick.delaney@home.com
------------------------------
Date: Sat, 14 Aug 1999 12:24:57 -0700
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: printing vars
Message-Id: <37B5C289.34AB628@mail.cor.epa.gov>
ted fiedler wrote:
>
> with this:
>
> open(NAS,"names");
Ooh. You really ought to check the return on all your open()s.
The ones below, too.
[snip of other code]
> I am reading from a file that looks like this:
>
> name john doe
> name ed doe
> name joe doe
> account 123
> account 234
> account 456
Wait. That's not what you *code* said. Are names in "names"
and accounts in "accounts", or are all names and accounts
lumped in the same file? It makes a difference when reading
in the data.
> in this file there are always the same number of names as accounts
> i need my output to look liike this:
>
> john doe,123
> ed doe,234
> joe doe,456
>
> instead it looks like this:
>
> name john doe
> name ed doe
> name joe doe
> account 123
> account 234
> account 456
Well, for one thing, you're not doing the regex matching
and trimming that you think. Your code looks like:
XX> foreach $name(@name) {
XX> if( /^name/) {
XX> s/name//;
XX> }
XX> }
So you take the element in @name, assign it to $name,
then do your match and substitution on the default
variable $_ instead. You could do this:
for (@name) {
if /^name/ {
s/name//;
}
}
But that's still a waste of time. Just do the substitution.
If the line doesn't start with 'name' then no substitution
occurs:
for (@name) {
s/^name //; # I added a space after the word 'name'
}
Which, in a modern Perl [like version 5.005] could be
written as:
s/^name // for (@name);
And a form like that might make you wonder if there's a
more Perlish way to do the same thing. There is. Read
about map().
But if what you want is to parse out a *single* file
with both names and account numbers in it, you ought to
do this a little differently. If all your lines of your
combined file are in @lines, you can do something like:
@names = grep { s/^name // } @lines;
@accounts = grep { s/^account // } @lines;
Now [assuming you really can depend on proper alignment
of names and accounts in the original file - I wouldn't
for anything important unless I had a key to match on],
you can print line i+1 like this:
print $names[$i],",", $accounts[$i],"\n";
HTH,
David
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician
------------------------------
Date: Sat, 14 Aug 1999 21:08:17 +0200
From: "Romiko" <rvdd@iafrica.com>
Subject: Udate file using another file
Message-Id: <7p4f75$d4t$1@nnrp01.ops.uunet.co.za>
Howzit
I have been trying to write a script that compares two similar files and
updates the changes , I have been trying for two days and cannot get it
right. FileA is the Table that needs to be updated and fileB is the table
with the latest records. The third field in FILEA(cifa) needs to be
compared
with the first field in FILEB(cifb) and the fith field in FileA(Account
number) compared with the 3rd field in FileB (Account Number)to see whether
an existing customer open another account eg had a savings and then opened a
cheque account later.
you will notice that a portion of the account number matches the cif number.
FileA
002233791|10001|7|Romiko van de dronker|021/00007/13
002233792|10001|7|Romiko van de dronker|022/00007/14
002333745|10002|14|Bob Harrison|021/00014/12
FileB
7|Romiko van de dronker|021/00007/13
7|Romiko van de dronker|022/00007/14
8|Michael Bake|021/00008/12
14|Bob Harrison|021/00014/12
16|Harry Ford|429/00016/11
16|Harry Ford|430/00016/12
200|Joe Blogs|021/00200/13
23333|Gary Player|022/23333/45
OUTPUT
002233791|10001|7|Romiko van de dronker|021/00007/13
002233792|10001|7|Romiko van de dronker|022/00007/14
8|Michael Bake|021/00008/12
002333745|10002|14|Bob Harrison|021/00014/12
002543578|10003|16|Harry Ford|429/00016/11
16|Harry Ford|430/00016/12
200|Joe Blogs|021/00200/13
23333|Gary Player|022/23333/45
OUTPUT2 (shows changes only)
8|Michael Bake|021/00008/12
16|Harry Ford|430/00016/12
200|Joe Blogs|021/00200/13
23333|Gary Player|022/23333/45
notice that Harry has opened another
account and his customer number stays the same (16), so the record with the
new account needs to be taken into account.
------------------------------
Date: Sat, 14 Aug 1999 14:28:41 -0400
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re: Updating Tables using two seperate files
Message-Id: <37B5B559.181D3CCB@rochester.rr.com>
> Guys I have tried using this
> script that I made but is does not work, why??
>
> Cut here -------------------
>
> BEGIN { FS = OFS = "|"
> while (getline <"A") {
>
> cifa = $3; acca = substr($5, 5, 5)
> while (getline <"B") {
> cifb = $1; accb = substr($3, 5, 5); name = $2; accfull = $3
> }
> }
> {if (cifb != cifa || accb != acca ) {
> print cifb, name, accfull
> }
> }
> }
>
> CUT---------------------------------
Try an awk newsgroup, if you can find one. Your code is not Perl, it is awk, so
it doesn't belong in the Perl newsgroup. Or try a2p on it and then ask us why
the resulting Perl code doesn't work :-).
------------------------------
Date: Sat, 14 Aug 1999 21:05:01 +0200
From: "Romiko" <rvdd@iafrica.com>
Subject: Re: Updating Tables using two seperate files
Message-Id: <7p4f0r$d3f$1@nnrp01.ops.uunet.co.za>
Sorry dudes I missed the group?
Bob Walton wrote in message <37B5B559.181D3CCB@rochester.rr.com>...
>> Guys I have tried using this
>> script that I made but is does not work, why??
>>
>> Cut here -------------------
>>
>> BEGIN { FS = OFS = "|"
>> while (getline <"A") {
>>
>> cifa = $3; acca = substr($5, 5, 5)
>> while (getline <"B") {
>> cifb = $1; accb = substr($3, 5, 5); name = $2; accfull = $3
>> }
>> }
>> {if (cifb != cifa || accb != acca ) {
>> print cifb, name, accfull
>> }
>> }
>> }
>>
>> CUT---------------------------------
>
>Try an awk newsgroup, if you can find one. Your code is not Perl, it is
awk, so
>it doesn't belong in the Perl newsgroup. Or try a2p on it and then ask us
why
>the resulting Perl code doesn't work :-).
>
------------------------------
Date: Sat, 14 Aug 1999 11:56:47 -0700
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: What happened to Perl in 1990?
Message-Id: <37B5BBEF.E7A0CFC@mail.cor.epa.gov>
brian d foy wrote:
>
> looking over e.'s Perl Timeline
> <URL:http://history.perl.org/PerlTimeline.html#1990s> i see that
> there is nothing significant listed for the year 1990. surely
> something must have happened that year, but that's before i had
> heard of Perl...
Well, 1990 was the year in which biomedicine first performed
gene therapy in humans. I won't say that synchronicity is
causality, but draw your own conclusions...
Alternatively, 1990 was the year in which astrophysicists
published the first confirmation of the Big Bang theory, so
perhaps Larry was too busy trying to console Fred Hoyle.
David
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician
------------------------------
Date: Sat, 14 Aug 1999 22:03:33 +0200
From: Christian Tismer <tismer@appliedbiometrics.com>
To: Tom Christiansen <tchrist@mox.perl.com>, python list <python-list@cwi.nl>
Subject: Re: Why use comp.lang.python when you've got comp.lang.perl.misc?
Message-Id: <37B5CB95.3FCF571F@appliedbiometrics.com>
Tom Christiansen wrote:
>
> [courtesy cc of this posting mailed to cited author]
>
> In comp.lang.perl.misc,
> Christian Tismer <tismer@appliedbiometrics.com> writes:
> :I believe that people would read comp.lang.perl.[xxx]
> :if they wanted to do so.
>
> I believe that if someone wanted to hear about why Perl was a nasty
> language and Python was the cat's meow, that they wouldn't be reading
> comp.lang.perl.misc to do so. Wouldn't you agree? Nonetheless, certain
> members of the Python Mafia seem to have taken it upon themselves to
> come over here and do precisely that.
I'm ashamed to hear that.
And reading c.l.p.m I have to realize that this crap
is 218 messies already. Oops - 221 meanwhile.
...
> I don't mean to paint everyone with a broad brush here. There are
> reasonable people on whatever side. I could name names. :-) Sadly,
> it's the noisy ones you tend to hear from.
I agree. But I wasn't just complaining about pointless crossposting
(which may of course be a problem of both sides) but I also
proposed to think of constructive collaboration.
Do you think this is possible, I mean is there interest at all?
cheers - chris
--
Christian Tismer :^) <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net
10553 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
we're tired of banana software - shipped green, ripens at home
------------------------------
Date: Sat, 14 Aug 1999 18:47:03 GMT
From: miker3@ix.netcom.com (Michael Rubenstein)
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37bcb996.574382107@nntp.ix.netcom.com>
Absolutely correct.
On 13 Aug 1999 14:07:45 -0700, Tom Christiansen
<tchrist@mox.perl.com> wrote:
>Please face it: terms like "readable" and "intuitive" are completely
>subjective, and therefore purely opinion.
------------------------------
Date: Sat, 14 Aug 1999 18:57:20 GMT
From: jstevens@bamboo.verinet.com (John Stevens)
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <slrn7rbf0f.sgr.jstevens@bamboo.verinet.com>
On 14 Aug 1999 02:57:08 -0400, Uri Guttman <uri@sysarch.com> wrote:
>>>>>> "JS" == John Stevens <jstevens@bamboo.verinet.com> writes:
> JS> Thank you. I will. Perl cannot be used without manuals.
>
>neither can python.
This statement has some validity, but is not entirely true. I can
and do write Python without refering to manuals.
But it is true that you need to have the library reference close
at hand to lookup interface definitions when using some of the
less commonly used library modules.
About 10% of the Python I write uses nothing more than standard
python.
>this book is not a manual, but a study in how to
>write OO perl and do all the stuff other OO languages can and more. OO
>perl can do stuff very few if any other languages can handle.
Yes. As I said, it is powerful. Just confusing, due to its
lack of common key words.
Ada programmers are not allergic to seeing "package" or "module" and
thinking "class", but most people have to take a second look.
> JS> My primary complaint re: OO-Perl, is the lack of "expected"
> JS> keywords and OO syntax.
>
>what is expected keywords?
Almost every OO language uses the word: "class".
>there are only a couple of things that make
>perl oo: creating a reference, bless, @ISA for inheritance and the
>direct method call $obj->method. can't get much simpler syntax that
>that. don't need no steenkin keywords!
It needs the keywords to communicate intent with the reader.
>not really. you haven't tried hard enough.
;->
Right. Why doesn't anybody every question whether or not it
should be that hard?
Note: I teach OO programming courses. In the past, I've used
Perl as one of the languages I use to teach OO. After exposing
the class to Python,
I give them an hour to create their first Python class.
They almost all, always, get the assignment done in less than an
hour.
After showing them the Perl way, I let them have a full day.
And, on the average, 1 in 4 cannot finish the assignment
at all.
It is more difficult to learn to do OO in Perl.
>you have shown more perl bugs
>in your examples than someone should who claimed to use it for 2 years.
Excuse, but I used if for more than two years. I used Perl almost
*exclusively* for two years, but I've haven't used it for almost
six months, now.
IOW, the Perl bugs I've shown are simply more proof of the
greater inherent difficulty in learning, using, and maintaining
Perl code.
> JS> When is it warranted?
>
> JS> When is it *NOT* warranted?
>
>bullhockey.
Excuse? Those were questions. What are you calling bullhockey,
the questions? Since when are questions unacceptable?
>i have written dozens of programs both OO and not in many
>languages including assembler. OO is an attitude abotu organizing you
>data and code.
No. It is not just that. Have you ever had any formal OO training?
>it is not a stricture requiring you do use keywords and
>crap like that.
Keywords are crap?
There is an OO term: polymorphism. It means: the same things
should be said in the same way. An example of polymorphism
is the use of the + keyword to indicate both integer and
floating point addition.
Among other things, good OO design uses appropriate polymorphism.
>i wrote a realtime system in pdp-11 assembler using
>macro-11 which was OO since all major operations which needed mutex
>locking were isolated in macros.
OO describes a system for designing, analyzing, implementing and
maintaining systems, it does not describe languages. Learning an
OO language, does not teach you OO.
>so the critical data and queues were
>hidden from the rest of the code like OO says to do.
Encapsulation is not the sum total of OO. In fact, if all you do
is encapsulation, you are not doing OO. The bare minimum requirement
for OO is encapsulation, inheritance, messaging and support for
subclass responsibility.
>yet i write medium sized perl programs with no OO at all if i feel
>(warranted) it is not needed.
Yet the question remains unanswered: what do you use to decide
that OO is waranted, or not waranted.
>it would be a waste of code and structure
>for a single standalone program to use OO like that.
Why?
>onthe other hand i
>wrote a simple perl module (only 4 data members) with many methods since
>it was going to be used by a bunch of small utilities. OO was warranted
>there as it made the design easier and speed was not an issue.
Ok, so I guess you are saying that OO is unwaranted when speed is
an issue. By that, I am also assuming you are implying that the
speed hit incurred by OO is unacceptably large.
>i chose the time and place for oo since i know how to do both. forcing
>it on newbies is a crime as they will have a hard time going without
>it.
Excuse? Why would teaching OO to newbies be a crime?
>it's just like event programming is very difficult for most coders
>who have just done procedural for their careers. "who calls my event
>subs?" they ask. well oo slaves will say, "what is a global?" and "how do
>you share data?"
An OO trained programmer will not ask questions like:
"What is a global?". They'll ask: why are you using such a poor design?
They will not ask: "How do you share data?", they'll ask: "What are
you going to do about this in maintenance?"
> JS> I have my own guidelines, ones that I teach when I teach OO, but I
> JS> am curious as to where other people draw the line.
>
>at python and java and c++.
Again, OO is a paradigm, not a language. You can do
OO in ANSI C.
> JS> Python does not force OO on you. You can use it as a purely
> JS> procedural language.
>
>not from what you have shown.
What example are you talking about?
>even a simple array or dictionary has to
>be an object with messages passed to it. a procedural language just does
>what you tell in via the syntax, not via methods or messages.
:-)
> JS> And, in point of fact, those earlier methodologies did indeed
> JS> reduce the number of bugs.
>
>not really, they just delayed them.
No, really. They really did reduce defect rates.
> JS> Yes, but OO is an improvement over previous methodologies.
>
>not true.
>it is just another methodology, not an improvement.
Interesting assertion. Do you have any reasons you'd care to share
that suuport that assertion?
> JS> It lowers the bar, allowing less talented programmers to design,
> JS> write and maintain more complex systems.
>
>let's see. cpan is full of modules, many of which use OO perl. it is
>massive, shared and growing rapdily.
Now, if OO is not an improvement. . . then why introduce OO into
Perl?
>python has what??
Go look. http://www.python.org/
>if it is so much more
>shareable and manageable than why hasn't it developed such a world class
>library?
What particular part of Python's library is *not* world class?
>it seems that the python lovers are either
>scared of perl syntax, or like to be handheld along the coding
>path.
Or that they simply don't like wasting time and money.
>maybe
>the pseudo-barrier of perl's syntax just filters out the chaff and so the
>perl community is just a smarter and more skilled one.
And TC says that Perl encourages stupid people to use it . . .
So, which do you suppose is the truth?
Perhaps Perl simply attracts people who believe that learning
something that is arbitrarily made difficult than it needs to be
somehow proves that they are more intelligent than the average.
Or maybe it traps users, because after they've spent so much time
becoming competent, they are loathe to waste that time and
fall into the trap of throwing good money after bad.
Or maybe it is simpler than that: maybe people are attracted
to Perl because they are more comfortable being part of a
large group, instead of a small group.
>as for a comparison of the market size, just search for perl vs. python
>on any jobs site and compare the numbers.
Actually, I hadn't mentioned market size at all.
>it is not because perl is
>a better language or whatever, it is because perl gets the job
>done.
Your logic is flawed. You have yet to show that Perl's
characteristics have anything at all to do with the number
of people that use it.
An equally good case could be made, from the existing data, that
Perl is so difficult to learn and use, that programmers use it
to protect their jobs.
And the high level of demand, may simply be a symptom of that.
> JS> Compare the complexity of Windows 2000 to, say, Windows 3.11.
>
>BFD. it is buggier to boot. and it is redmondware which makes it
>useless.
The point was re: the speed at which systems complexity
has increased in relationship to the speed at which systems
designed to control complexity have been developed.
>when did you first learn OO? i was taught it by barbara liskov at mit in
>1978. it was in pl/1 of all languages!
OO is not a language.
And PL/1 did not support sub-class responsibility (feel free to correct
me if I'm wrong).
Therefore PL/1 did not have language support for OO.
>so it was not the syntax but the
>concepts that mattered.
Yes.
>so having a language which forces OO is not the
>answer.
One could make the same argument re: procedural programming.
>so it would actually be better to teach how to do OO in c than
>to require it in python/java.
And in fact, one of the languages I use in class is C (when the
class has lots of C programmers in it, any way).
But, for production use, it is preferable to use a language
that has support for doing OO programming in it.
>since c has no OO features, teaching and
>using it in c (as i have on many designs) is more educational than in oo
>languages.
Yes, it can be quite educational. Especially when you go back and
tell your students: "Now, add in sub-class responsibilty." ;->
>and as i said before, any moron can design a bad object.
Yes.
>oo didn't save
>him from his own stupidity.
No.
>the tool is only as good as the craftsman
>using it.
True. But that does not extend to: "Therefore, all tools are
equally good at all jobs".
>a master craftsman can do wonders with the simplest of tools
>while an idiot couldn't make a good toothpick with a numerically
>controlled milling machine.
Correct. But a Master Craftsman will use the right tool for the
right job, rather than forcing a screw driver to act as a chisel.
> JS> If that were the case (that only newbies find Python more
> JS> readable), you might be right (but only if you assume that the
> JS> ability to read and understand programs even if not a programmer
> JS> is useless).
>
>readibility of code depends on the skill of the coder much more than
>the language.
No, it does not.
Readability has more to do with designing the language to be
intuitive, than skill of the programmer.
The best Perl programmer in the world cannot make Perl readable
to a non-programmer. But well written Cobol can be read even
by people that have never programmed.
>oo does not make that any easier or harder.
It makes it easier.
Which is easier? Analyzing a program of 10,000 lines, or one
that is 100 lines?
>it is
>just another tool to be used when it is needed. you can have a beautiful
>procedural api (some parts of the unix kernel is like that) or a messy
>OO interface with no clarity of what method needs to be called or what
>will really happen due to the complexity of the inheritance tree. my
>point is that oo is as good as the coder. which is true for any
>language/code pair.
But not to the same degree.
> JS> It is true, however, that some languages are easier to learn than
> JS> others, and that once learned, are easier to remember.
>
>that is not what i said.
No, it is what I said.
>lisp is the simplest language in the
>world. pure prefix calls. nothing else. guaranteed simple parsers. lisp
>in lisp in a page of code. it still sux for real world projects (other
>than for dyed in the wool lispers who are a dying breed). but do you
>think in parens? do you want to memorize the hundreds of twisty little
>calls all looking like each other?
Exactly. Perl is the procedural programming equivalent of Lisp.
>the same with python. it is a oo purist oriented language.
No, it isn't. You can do procedural programming in Python.
>BTW perl has stacks, queues, and arrays and all that is needed is one
>data type and one function, splice.
You haven't learned OO yet. Nor have you learned how to control
defect rates. That one statement pretty much explains to me why
Perl coders (if they think like you do) generate more defects, and
why they are so hard to find.
>just speedier shortcuts for common splice operations. perl's intrinsic
>array allows multiple well defined operations which can be used to
>emulate a variety of complex data structures.
Using an array as a stack is an inherent source of defects, and
reduces the maintainability of the program. The interface to
a stack is not the same as an interface to an array, so when
a maintainer inadvertently uses an array operation on a stack:
BOOM! Defect.
If it's a stack, it should only allow stack operations (push, pop).
>so your taunt about push implying a stack is bogus. the
>fact that the name of an operation is push does not mean it is a
>stack.
IOW, the word "push" should not have been used to define this
operation.
Drastically reducing both the readability and maintainability
of the code.
>you can just use splice. think of splice as the
>universal array method even though arrays are not objects.
Further muddying the water. The operation name chosen should be
indicative of the problem space of the application. Which
is what OO gives you: the ability to write programs that more
closely models the application space, not the language space.
John S.
------------------------------
Date: Sat, 14 Aug 1999 19:05:41 GMT
From: jstevens@bamboo.verinet.com (John Stevens)
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <slrn7rbfg5.sgr.jstevens@bamboo.verinet.com>
On 13 Aug 1999 17:44:42 -0700, Tom Christiansen <tchrist@mox.perl.com> wrote:
> [courtesy cc of this posting mailed to cited author]
>
>In comp.lang.perl.misc,
> "John W. Stevens" <jstevens@basho.fc.hp.com> writes:
>:> To help me learn Python, I decided to rewrite some of my Perl scripts
>:> in Python. The first script I chose for conversion was called "getfile";
>:> it grabs a file via FTP and prints it on stdout. Here it is:
>:
>:The Python FTP client module is designed to be a base class, not a user
>:class.
>
>Man, that's just superclever.
Geeze, thanks!
>You really expect to stuff all this
>complete OO crudolo down some poor script kiddie's throat complete
>just because they want a library that's simple to use?
I am not trying to stuff anything down anybodies throat.
And, as I demonstrated, the FTP base class in the Python library
*is* easy to use.
Want it easier? Just say so. Ask nasty, ask nice, ask in any
way I can understand, and I'll simplify it for you. Anybody
who wishes to, can use the code I posted. It's public domain.
>That's nutty.
Thanks.
>If that's all Python has, it's no wonder why they use Perl.
:-)
>Sheesh.
>Regular humans need to program, too, not merely the duly annointed
>OO indoctrinees.
What, I'm not human? I'm not regular? OO is incredibly difficult
to learn? OO requires annointing, why Perl only takes learning?
Perl doesn't take any learning?
In point of fact, it will take less time for a newbie to learn
to do what I did in Python, than they will in Perl.
Of course, if what you mean by "script kiddie" is some one
who doesn't understand the Perl code they use, they just snag
it out of some "cookbook", then we are talking about two
different things.
Why the rabid-anti-OO phobia, anyway? Who bit you?
John S.
------------------------------
Date: Sat, 14 Aug 1999 19:25:46 GMT
From: jstevens@bamboo.verinet.com (John Stevens)
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <slrn7rbglq.sgr.jstevens@bamboo.verinet.com>
On 14 Aug 1999 01:46:27 GMT, Sam Holden <sholden@pgrad.cs.usyd.edu.au> wrote:
>On Fri, 13 Aug 1999 17:30:09 -0600,
> John W. Stevens <jstevens@basho.fc.hp.com> wrote:
>>Sean McAfee wrote:
>>
>>The difference is: it would take me six lines to add a putFile method,
>>while modifying your script would take longer. Note, also, that my
>>code does error checking. Yours doesn't.
>
>It would take one line to add a put method to the perl code,
That depends on your design, of course.
>I would be more inclined to create a seperate command for the put, since
>you are unlikely to use it in the same way?
To copy from a vi buffer to a remote file, you need to read lines
from the buffer, then print them out unchanged.
Simply sending the lines to the remote file would, in effect, cut
out the select portion.
>In fact to be equivalent
>it owuld really need to get the file from STDIN anyway. Did you read the
>description of what the program was for?
My Python code gets a file from a remote source and dumps it into
the current vi buffer.
>I snipped it sorry, but I'm
>sure you remember. Making the user always type getFile or whatever it is
>seems a little excessive for such a specific purpose script.
Why is it excessive?
get.
Get what?
getFile
Get a file. The second is clear. The first is ambiguous.
>>Also, note that your code is not portable. Mine is: it runs the same
>>under NT as it does under Unix, though of course, you must run it
>>from a command line environment on NT.
>
>It doesn't work under Unix of course.
Yes, it does.
>Unless you consider broadcasting your
>password to everyone who can be bothered running 'ps' working.
That assumes, of course, that you are using a private password.
Accessing a file from an anonymous FTP server, you would pass
your email address. . .public information.
>Of course
>you would save the' unportable' part of the perl script and half the
>code if you set it up to use the same incrediblyu stupid way of getting a
>password.
You didn't consider that it isn't a security
risk when user is 'anonymous', or the repository is a shared
one.
>The only Unix specific part of the perl code was the two system() calls.
Right. So it won't run under NT, will it? Or has NT added an stty
call since last I used it?
>The only thing they did was turn echo off and on. Since the python
>program doesn't do that the python program doesn't work - it doesn't
>fulfill the spec.
The Python program works just fine, considering the fact that it
wasn't written to a spec, just dumped to the news group as a demo.
If you are saying you want a Python program that works exactly
like the Perl, that would be easy enough to do. But I posted
that code in order to show that using the FTP client software
supplied by the Python library was easy to use.
>Those system()s can be removed bu using the Term::ReadKey module of course,
But, of course, that wasn't done. The temptation to use Unixisms in
Perl seems to be pretty strong.
>Most real programmers I know spend a reasonably large amount of their time
>writing one liners to automate the things they need to do as part of their
>work.
He claimed he wrote more one liners than anything else.
>>That would count . . . IF it were true, and IF you have MegaBytes of
>>data to
>>process. But I thought you said that you use mostly one liners?
>
>The length of the code has no relation to the size of data?
When processing large amounts of data, one liners probably will
do nothing more than fail to work correctly.
One liners are almost always written to do something non-critical
on small amounts of data.
>The last one liner I wrote operated on a 112Mb squid cache index.
Must have been a very simple task, or a very long line.
>>> ======================================================================
>>> #!/usr/local/bin/perl
>>>
>>> use Net::FTP;
>>>
>>> @ARGV == 3 || die;
>>> ($host, $userID, $file) = @ARGV;
>>>
>>> system("stty -echo");
Non portable stuff here, right?
>>> chomp($passwd = <STDIN>);
>>> system("stty echo");
Non portable stuff here, right?
Not every system has stty.
>>> $ftp = new Net::FTP $host;
>>> login $ftp $userID, $passwd;
>>> get $ftp $file, \*STDOUT;
>>> quit $ftp;
John S.
------------------------------
Date: Sat, 14 Aug 1999 19:27:34 GMT
From: jstevens@bamboo.verinet.com (John Stevens)
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <slrn7rbgp5.sgr.jstevens@bamboo.verinet.com>
On 13 Aug 1999 21:52:47 -0700, Russ Allbery <rra@stanford.edu> wrote:
>John W Stevens <jstevens@basho.fc.hp.com> writes:
>
>> Consider using the Perl module for FTP operations that *DON'T* conform
>> to standard usage. . .
>
>If they're not part of standard usage, they're not FTP.
Non-standard, as in, not a standard part of an FTP client program.
Not as in: not conforming to the FTP standard.
The poster was complaining about the fact that the Python
library module did not present him with the same interface
as did his ftp client program.
Sorry for the confusion.
John S.
------------------------------
Date: 14 Aug 1999 13:45:16 -0600
From: Daniel Grisinger <dgris@moiraine.dimensional.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <m3wvuy6t9v.fsf@moiraine.dimensional.com>
Tom Christiansen <tchrist@mox.perl.com> writes:
> Pick a Perl programmer with experience equivalent
> to mine.
Wow, that's got to be a short list. :-)
dgris
--
perl -Mre=eval -e'$_=shift;;@[=split//;;$,=qq;\n;;;print
m;(.{$-}(?{$-++}));,q;;while$-<=@[;;' 'Just Another Perl Hacker'
------------------------------
Date: Sat, 14 Aug 1999 19:43:44 GMT
From: jstevens@bamboo.verinet.com (John Stevens)
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <slrn7rbhnf.sgr.jstevens@bamboo.verinet.com>
On 12 Aug 1999 21:18:05 -0500, Abigail <abigail@delanet.com> wrote:
>Ian Clarke (I.Clarke@NOSPAM.strs.co.uk) wrote on MMCLXVI September
>MCMXCIII in <URL:news:37AAFAD1.A032765B@NOSPAM.strs.co.uk>:
>
>I really don't believe in this crap "my language is better than yours".
There are objective, quantifiable metrics that do indeed prove that
one programming language is better than another for specific classes
of tasks.
The CS "Urban-Myth" that programming language is meaningless re:
productivity, clarity, cost control, etc., is just that.
A myth.
>People are different. Programmers are different. For some programmers,
>Perl is the better choice. For others, Python. If you are happy with
>Python, by all means, use it. I don't think Perl gives you anything that
>Python doesn't give use - except when it comes to certain design issues:
>many ways of doing things, dense code, lots of operators/functions.
Which implies that it has a higher level of complexity, while not
giving you any additional functionality.
Consider the relationship between complexity and cost.
>But does that make Python better than Perl?
That factor alone is not a good enough reason for changing languages,
but in the right situation, yes, that means Python is better than
Perl.
>No. Python is different.
>They are useful in the roughly the same domain. I cannot come up with an
>area where Perl would be a better choice than Python, or where Python
>would be a better choice than Perl.
In almost every case, when users are exposed to both, and given
equal amounts of time to play with both, they end up prefering
to do OO programming in Python.
So there is at least one area where Python would be a better choice
than Perl.
>I can imagine many areas where
>neither Perl or Python would be a wise choice.
True.
But among languages of similiar class, it is possible to
extract metrics, and prove that one language is better than
the another.
>Please, don't come with any arguments of the form "Perls syntax is
>complicated, hence Python is better". That's an opinion.
No, it is not. This factor can be measured, and it's effect
on productivity, maintainability and defect rates can also
be measured.
Perl's greater complexity would be justified, if that greater
complexity gave you greater functionality. So far, I haven't
seen anything that would indicate that this is the case.
>Yes, it's a fact
>that Perls syntax is more complicated than Pythons, but the conclusion
>("Python is better") is your opinion.
The conclusion that Python is generically better would be a mistake.
The conclusion that Python is better than Perl for large, scalable
projects that are written and maintained by a team, is
not an opinion. It is a fact that can be proven by measuring
the relevant factors.
John S.
------------------------------
Date: 14 Aug 1999 13:46:38 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37b5c79e@cs.colorado.edu>
[courtesy cc of this posting mailed to cited author]
In comp.lang.perl.misc,
Daniel Grisinger <dgris@perrin.dimensional.com> writes:
:> Pick a Perl programmer with experience equivalent
:> to mine.
:Wow, that's got to be a short list. :-)
I can't count them in the thousands, but there are plenty.
--tom
--
Actually, you'll know we're nearing the end when I make |$foo| mean
"absolute value"... :-) Larry Wall in <1994Feb25.192042.17196@netlabs.com>
------------------------------
Date: Sat, 14 Aug 1999 11:53:53 -0700
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: Why use Python when we've got Perl?
Message-Id: <37B5BB41.5DBC094B@mail.cor.epa.gov>
Russ Allbery wrote:
>
> In comp.lang.perl.misc, Miles Egan <milese@pacbell.net> writes:
>
> > This is excellent advice. Even if you never write a line of production
> > code in Scheme or ML, studying these languages can be very enlightening.
>
> And speaking from personal experience, learning LISP and ML will make you
> a considerably better Perl programmer. For one thing, knowing LISP means
> that things like map and grep will become more intuitive.
Or, if you're less fluent in other programming languages, like
me, then you may do as I did. It was the shock of Randal's
first Schwartzian Transform that led me to check out LISP.
And it was Perl's object style that led me to look at Python.
There are lots of hidden advantages to using a language like
Perl...
David
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician
------------------------------
Date: 1 Jul 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 1 Jul 99)
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.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq" from
almanac@ruby.oce.orst.edu. The real FAQ, as it appeared last in the
newsgroup, can be retrieved with the request "send perl-users FAQ" from
almanac@ruby.oce.orst.edu. Due to their sizes, neither the Meta-FAQ nor
the FAQ are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq" from
almanac@ruby.oce.orst.edu.
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 V9 Issue 528
*************************************
