[13101] in Perl-Users-Digest
Perl-Users Digest, Issue: 511 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Aug 13 19:17:29 1999
Date: Fri, 13 Aug 1999 16:10:15 -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 Fri, 13 Aug 1999 Volume: 9 Number: 511
Today's topics:
Re: Why use Perl when we've got Python?! <aqumsieh@matrox.com>
Re: Why use Perl when we've got Python?! <arcege@shore.net>
Re: Why use Perl when we've got Python?! <jstevens@basho.fc.hp.com>
Re: Why use Perl when we've got Python?! <jstevens@basho.fc.hp.com>
Re: Why use Perl when we've got Python?! <tchrist@mox.perl.com>
Re: Why use Perl when we've got Python?! <tchrist@mox.perl.com>
Re: Why use Perl when we've got Python?! <tchrist@mox.perl.com>
Re: Why use Perl when we've got Python?! <tchrist@mox.perl.com>
Re: Why use Perl when we've got Python?! <tchrist@mox.perl.com>
Re: Why use Perl when we've got Python?! <skip@mojam.com>
Re: Why use Perl when we've got Python?! <tchrist@mox.perl.com>
Re: Why use Perl when we've got Python?! <tchrist@mox.perl.com>
Re: Why use Perl when we've got Python?! <tchrist@mox.perl.com>
Re: Writing lines to file twice or more (newbie questio (Matthew David Zimmerman)
Digest Administrivia (Last modified: 1 Jul 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 13 Aug 1999 15:46:44 -0400
From: Ala Qumsieh <aqumsieh@matrox.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <x3ypv0r1n18.fsf@tigre.matrox.com>
Ian Clarke <I.Clarke@NOSPAM.strs.co.uk> writes:
> I will not rise to the bait, except to say
> that I initially applied equal amounts of time to trying to learn Perl
> and Python, but ended up getting nowhere with Perl, but becomming
> increasingly fond of Python.
Ok. So you say you have tried to learn both languages, at the same
time, and ended up prefering Python over Perl.
That's good. You seem to have made up your mind. Why do you need
someone else to convince you otherwise? Different people have
different tastes, even when it comes to your programming language of
choice. If Python appeals to you more than Perl, then stick to Python
by all means. If you prefer Lisp, then go ahead and use it.
> How many people can claim to have started
> using Python, and then, of their own free will, migrated to Perl? (And
> if you are such a person, could you please tell my why - as this would
> be an answer to my initial question!).
Maybe 1, maybe none, maybe many. How would knowing this number help
you? What is the purpose of your initial question? Are you conducting
a survey of some sort?
If your goal was to learn Perl, then you took a wrong direction. If
you applied your and time and energy, that you have already put into
this thread, into learning Perl, then you would've made the comparison
yourself. People can NOT decide for you. Do you like other people to
decide what color your pants should be? Or what style your hair should
look like? Or whether to eat hamburgers or chinese food for dinner?
> Anyway, while I appreciate the list of pet-gripes that you have with
> Python (none of which I ever had a problem with, but maybe that's just
> me), you are missing the point of my post. You have replied to my post
> as if it were an attack on Perl, which was not my intention. My
> intention is to find out what features Perl has that Python doesn't, and
> why I might want to use Perl when we have Python?
/me puts on his Socrates hat that he stole^H^H^H^H^Hborrowed from a
museum in Greece.
I don't think Perl has anything significant to offer over Python when
it comes to functionality. The inverse is also true. Except maybe for
regular expressions.
But, IMO, Perl gives you the freedom to code the way you like. Python,
OTOH, restricts you. A lot of people like Python because it restricts
you and gives you only one way to do things. I think, the reason is
that they are afraid of making choices. "Should I use this idiom? or
that one? or maybe this one? I don't know! Let me post to usenet and
see what the experts do." It also makes maintaining programs easier
(especially for beginners -- not so much for experts).
Perl on the other hand gives you more flexibility. This is good for
some people, bad for others. I personally like to compare Perl with
the human brain. The brain is the most complicated, least understood,
most efficient, and most ingeniously designed system you could ever
percieve. It lets you do all sorts of marvelous things like the
Pyramids, the Mona Lisa, the Great Wall, computers, walking on the
moon, etc ... It also has the ability to do all sorts of evil things
like killing, raping, massacres, etc ..
If the brain were limited to doing good things only, our ability to
apply it to different domains will be greatly limited as well. If the
brain gave us one way to travel (crawl), or one language to speak
(probably an ancestor of hebrew), or one choice of food (dunno,
milk?!), or the chance to do good only, then its application space
will be a fraction of what it is now. Great inventions could be used
for both good and evil. That's the price you pay.
Perl is like the human brain. It sets you free.
/me 's Socrates hat gets blown away by the wind.
I like apples too.
Ala
------------------------------
Date: Fri, 13 Aug 1999 22:23:37 GMT
From: "Michael P. Reilly" <arcege@shore.net>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <JV0t3.40$mV.9167@news.shore.net>
Tom Christiansen <tchrist@mox.perl.com> wrote:
: [courtesy cc of this posting mailed to cited author]
: :The first thing that hit me with Perl is that different types of
: :variables require different special characters to identify them,
: No, it's not like BASIC. Perl has only three basic types: scalars,
: arrays, and hashes. If I recall, there were dialects of BASIC in which
: you distinguished between integer and string values. Perl doesn't
: distinguish between the values. Instead, it distinguishes between
: whether something is singular or plural in nature.
: Consider the following Python code, which illustrates the three types:
: a = 10
: b = ["alpha", "beta", "gamma"]
: c = { "fred" : "wilma", "barney" : "betty" }
: To access elements, you use
: print b[0]
: to get alpha, and yet despite the obvious analogy, you do not use
: print c{"fred"}
: But rather
: print c["fred"]
: You use one syntax for initialization, but a complete different one for
: access; this is inconsistent. You cannot tell which fundamental kind
: of thing a, b, and c is just by looking at it. And it gets better
: when you pull in tuples.
And consider:
sub who {
return ("fred", "george", "wilma", "jane", "pebbles", "judy");
}
Does this return a hash or an array? No limitation, but hardly DWIM.
The door swings both ways as far as initialization/accessing where
Perl and Python are conserned.
: When you hear non-Python programmers complaining of what they see in
: Python as stupid or wrong or ugly or backward-seeming, you will be quick
: to point out underlying reasons such as those listed above. But I doubt,
: however, that you have yourself ever analysed how your *own* adverse
: reactions to C or Perl are elicited by the same unconscious prejudices and
: bigotries as irritate you when they are applied by others toward Python.
: Perhaps you should.
Okay Tom (for the benefit of this thread), based on personal
experience, usenet postings and various places and webpages, I'll make
the following statement. I know you've heard it before. Except on the
last year or so where there has been a flood of people new to scripting
learning both Python and Perl, it would be fair to say that people who
were learning Python had come from another scripting language, usually
Perl. The majority of Perl users I've ever heard in the last four
years who have touted Perl over Python have never even coded in
Python. And you know me (or maybe you wanted to forgot by now ;), I
don't make up judgements like this, even if they could be viewed as
subjective. I had my reasons for leaving the Perl community four or
five years ago and it was because of Perl, not because of Python
(didn't know about Python back then).
But you are perfectly correct, each person needs to evaluate why they
like or do not like the languages. And in corelation to that, only
when they can say they know both should they be commenting on what they
know in a forum like this thread.
: --tom
-Arcege
------------------------------
Date: Fri, 13 Aug 1999 16:32:52 -0600
From: "John W. Stevens" <jstevens@basho.fc.hp.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37B49D13.60FF6FF8@basho.fc.hp.com>
Tom Christiansen wrote:
>
> [courtesy cc of this posting mailed to cited author]
>
> In comp.lang.perl.misc,
> fl_aggie@thepentagon.com (I R A Darth Aggie) writes:
> :+ Happy languages like FORTRAN come to mind.
> :
> :Heh. I thought f90 got rid of the column-dependencies, but I'm not so
> :sure.
>
> You think that's rich, you ought to see what happens to people
> who set their tabstops to 3 or 4. :-)
I set *MY* tab stops to three or four. No problems. . . but
of course, I don't let my prejudices get the better of me.
John S.
------------------------------
Date: Fri, 13 Aug 1999 16:31:22 -0600
From: "John W. Stevens" <jstevens@basho.fc.hp.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37B49CBA.772D9783@basho.fc.hp.com>
Tom Christiansen wrote:
>
> [courtesy cc of this posting mailed to cited author]
>
> In comp.lang.perl.misc, Ian Clarke <I.Clarke@strs.co.uk> writes:
>
> :That is not entirely true - I do have an open mind. The point is that
> :as part of work, I may *need* to write Perl code, and I was really
> :looking for some reasons why this might not be a bad thing... can anyone
> :give me any?
>
> Because learning is good. And because there are 10-100x more Perl
> programmers and Perl programs in the world than there are the same for
> Python, despite increasingly comparable longevity. Think about why
> that might be.
CGI. For many people, CGI still means Perl, even though CGI scripts
can be written in almost any language.
Secondary reason: Syntax similiar to a combination of the most commonly
used Unix langauges (C and shell, of course).
Tertiary reason: The natural tendency of human beings to stick
to what they already know, and to find comfort in going along
with the herd.
[That last is not an insult. Going along with the herd is, in general,
survival oriented behavior, as has already been pointed out by other
posters to this news group.]
> Perl is hardly original in most of its approaches. Consider the famous
> epithet, "Perl is the Cliff Notes of Unix". If you are a Unix programmer,
> then this distilled essence of things already well known is familiar even
> to the freshman Perl programmer.
This provides a good reason for both using and not using Perl: if you
are
working on a Unix box, and have been doing so for quite some time, Perl
is the easier way (than either pure C, pure shell, or even a mixture of
the two).
$a = `uname -a`;
Is just to easy. . . I still prefer Perl to Python as a replacement
for shell programming.
> The corollary is of course that those
> without a Unix background in C, shell, sed, awk, and a few dozen other
> culture references find themselves even more lost.
Yep.
> That's a good part of
> why you see the some folks saying that Perl made complete sense to them
> immediately, but others saying that this is quirky and unpredictable
> and inconsistent and complicated. Consider the situation of Chinese
> speaker trying to learn Italian. Everything is completely foreign and
> unrelated to his accumulated experiences. Now consider the Spanish
> speaker in the same class, also setting out to learn Italian. The Spanish
> speaker finds intuitive and familiar everything that the Chinese speaker
> finds confusing and strange.
Which brings into question the use of the term: "intuitive".
Unless, of course, you defined intuitive as: "leveraging off of
existing knowledge and habits", in which case I totally agree.
> Are you, perchance, a non-Unix person? That might explain your
> antipathy over the same aspects of coding in which so many others
> find comfort.
I am totally a Unix person (Linux at home, Unix at work), and I
still prefer Python for general programming, Perl for short, simple
"throwaway" scripts or text processing.
Even though I learned Perl first, and had come from an extensive
"C and shell programming" background.
> Nevertheless, I shall attempt to try. Keep in mind that you'll often
> discover that the feature that one side holds as a strong point the other
> side deems a weak one, and vice versa. I do not expect the following
> exposition to differ significantly in that regard.
>
> The core point of Perl is usefulness. It's not there to win awards on
> complexity or cleverness or simplicity or minimalism or beauty or any
> other goal that might detract from its real job: helping you get your
> job done by making easy things easy and hard things possible. Try to
> keep that in mind.
The same is true of Python. The difference seems to be:
Perl was designed to make the single users life easier and more
productive.
Python was designed to make the team's life easier and more productive.
> This concept is often expressed as the "Do What I Mean" principle, or in
> short, "DWIM".
Right. Python, OTOH, enforces "Do It My Way So Others can Understand".
> When the language tries to do what you want it to do,
> rather than requiring you produce that one exact incantation that will
> accomplish your task, this is DWIM. DWIM makes the language react to
> the user's expectations, which is nearly the opposite of these stoic and
> spartan dialects, who, in a sad case of the tail wagging the dog, try to
> make the programmer conform to their ideas, not the other way around.
Which makes Perl perfect for the lone programmer who comes from a
Unix/C/Shell background, and who has no OO training.
OTOH, Python is perfect for the OO trained programmer who is part of
a team, or where the code will have to be maintained over a long
period of time by many different people.
> Making life hard for the programmer and easy for the computer
Whoops. . . no. Python does not make life harder for the programmer in
order to make life easier for the computer. Python makes life
*slightly*
more difficult for the programmer in order to make life *much* easier
for all of the *other* programmers.
I never have any problem understanding my own Perl scripts. Nor do I
have any real problem understanding other people's Python scripts.
Understanding somebody elses Perl. . . now that can be heart breakingly
difficult.
> The DWIM principle can be found most high-level languages, be these Perl,
> Python, Awk, or BASIC. In fact, you might even argue that the notions
> of DWIM and high-levelness aren't all that far apart from each other.
In OO, they talk about machine vs. application space (as in: information
space). Neither raw Perl, nor raw Python really make a dent in this
problem. OO, on the other hand, can help.
> One place that Perl's dweomer glows is in its automatic conversion between
> character strings and numeric values. This is something Python doesn't
> do. Consider what Python does if I feed it 42 on its standard input here:
>
> % python
> >>> import sys
> >>> n = sys.stdin.readline()
> 42
> >>> print n + 19
> Traceback (innermost last):
> File "<stdin>", line 1, in ?
> TypeError: illegal argument type for built-in operation
>
> Perl has no such difficulty, and this we consider a strength.
It has, instead, a different but related problem: non-polymorphic
comparison operators (to differentiate between string and
numeric comparison).
> If I feed 42 into Perl's standard input for the following code:
>
> $n = readline(*STDIN);
> print $n + 19;
>
> Then I simply get "61" out my standard output. It's quite obvious what
> I meant to do, so Perl applies its dweomer to DWIM.
On the other hand, of course:
$a = "t";
print $a + 3, "\n"
prints:
3
> You also see DWIM behaviour when converting between arrays (what
> you would call lists) and hashes (what you would call dictionaries).
> You can hold a list (what you would call a tuple), and these can be
> automatically converted. This:
>
> @array = ("fred", "wilma", "barney", "betty");
> %hash = @array;
>
> Is the same as:
>
> %hash = ("fred", "wilma", "barney", "betty");
>
> Because the list stored in the array will have its key-value pairs
> re-interpreted when this is stored into the hash.
Resulting, again, in someting confusing to the programmer who
hasn't any idea of what the above does, and that is still
somewhat confusing even to an intermediate Perl programmer.
I can *guess*, from my Perl experience, that this creates a hash whose
keys are the elements of the list, and that the data elements
mapped to those strings are . . . wait a minute, I'm not absolutely
sure.
Let me try it. . . Ok, the data elements are set to either an integer
zero, or a string whose contents are the zero character, or a floating
point zero.
Due to the auto-coercion of Perl, I really don't know whether the
default values are integer zero, strings, or floating point zeros.
> Another principle underlying much of Perl is that "things that
> act different should look different". This allows you to write
> programs in Perl that are *easier* to read, because different things
> don't look like each other. Python tends to obscure this.
I disagree with this. Refering back, again, to the
concept of polymorphism. Which assumes, of course, that what
you mean by "different" is not the same as what I mean by different.
And, in point of fact, Perl is inconsistent on this. Later in
this very reply, you will claim that doing two different things
in the same way is a *GOOD* thing (add new, vs. reassign).
> For example, that's one reason why when you want numeric ordering you
> use "==", but when you want lexical ordering you use an operator that
> looks completely different: "eq".
This is a bad thing, not a good thing. Again, it fails to be
polymorphic, to say nothing about failing to be OO.
> Likewise, because an array and a hash
> are, despite their interconvertibility, fundamentally different things,
> they *look* different. Contrast Python's:
>
> b = ["alpha", "beta", "gamma"]
> c = { "fred" : "wilma", "barney" : "betty" }
> print "b nought is", b[0]
> print "c fred is", c["fred"]
>
> with Perl's
>
> @b = ("alpha", "beta", "gamma");
> %c = ( "fred", "wilma", "barney", "betty");
> print "b nought is", $b[0];
> print "c fred is", $c{"fred"};
Correct. Python's behavior is preferable. Think: operator overloading
in C++.
Python allows this:
a = [ "This", "is", "a", "list" ]
b = ( "This", "tuple", "is", "immutable" )
c = { 0 : "Dictionaries", 1 : "are", 2 : "like", 3 : "hashes" }
def printSecondElement(c):
print c[2]
printSecondElement( a )
printSecondElement( b )
printSecondElement( c )
And, since Python is OO, you can even do:
printSecondElement( a )
d = a; a = b; b = d
printSecondElement( a )
d = a; a = c; c = d
printSecondElement( a )
Since variables store references to objects.
> Or, if you prefer to work only with references (which are like pointers):
>
> $b = ["alpha", "beta", "gamma"];
> $c = { "fred", "wilma", "barney", "betty"};
> print "b nought is", $b->[0];
> print "c fred is", $c->{"fred"};
> Accessing an array and accessing a hash are different operations.
No, they aren't.
That is the point of polymorphism. . . an array maps integers to
data elements. $a[ $index ] is an umapping operation. $a{ "x" }
is, equally, an unmapping operation.
Of course, other operations *ARE* different. Since arrays and lists
both suppy the additional semantic of: keys are ordered, and neither
dictionaries nor hashes supply this, then adding new elements to
a dictionary is going to be a different operation from adding one
to an array or list.
> They look very different. It's obvious to the reader what's going on.
> They can look at %h and @a and know these are different.
Yes. A flaw, for OO. How would one write a single function that
duplicates
the above Python code in Perl?
> They can look at $h{"fred"}" and $a[0] and know these are different.
Requiring a huge hit across many, many lines of code if, for some
reason,
you choose to change from arrays to hashes. In Python programs, I've
changed lists to dictionaries without having to change any dependent
code.
Polymorphism requires both OO training, and discipline to use, but if
used correctly, it is very powerful.
> Perl consistently produces better error messages than Python.
> Here's one example:
>
> % echo 'print f()' | python
> Traceback (innermost last):
> File "<stdin>", line 1, in ?
> NameError: f
>
> % echo 'print f()' | perl
> Undefined subroutine &main::f called at - line 1.
>
> After a while, you just want to take all your mysterious "name errors"
> and "syntax errors" and send them one at a time to Guido.
Oh, I agree with this one. Better error reporting is a must.
No ifs, ands, or buts about it.
> Let's finish up go back to DWIM. Python is really not very good at
> autoallocation, at least when compared to Perl. Consider for example:
>
> @array = ("alpha", "beta", "gamma");
> $array[3] = "delta";
You are making a basic mistake here: Python has lists. Not arrays.
And in fact, to use the same syntax for *ADDING* into them as you
do for REASSIGNMENT violates the one of the Perl principles you've
already said is good: that of being able to tell the difference.
So, just from the following line, how do you tell whether you are
performing a reassignment, or whether you are adding a new element?
$b[ 2 ] = $c;
> That's just fine in Perl. It's not fine in Python, because Python
> won't automatically grow an array.
'Cause it doesn't have arrays (or, at least, not built in ones).
>
> >>> a = ["alpha", "beta", "gamma"]
> >>> a[3] = "delta"
> Traceback (innermost last):
> File "<stdin>", line 1, in ?
> IndexError: list assignment index out of range
>
> Instead, you need to remember to use
>
> a.append("delta")
According to what you said earlier, this is better than the Perl
way. Appending to a list is better, 'cause you can tell the
difference between adding a new element, vs. reassignment: two
different operations, right?
> if it doesn't exist yet. This complexity forces the programmer who wants
> to assign "delta" to the third slot (there's a zeroth slot) of the list
> (Python parlance) to do something totally different in one situation
> than they have to do in another.
Excuse, but the two cases are different. One is reassignment. The
other is resize-list-and-add-a-new-element. A language that
has both eq and ==, should have two different operations here.
> In Perl, this is much easier. In fact, it just does what you mean
> right from the start.
This was actually quite irritating for me. It didn't DWIM, for
me (because, of course, DWIM is subjective, right?).
> Oddly enough, Python does let you grow dictionaries automatically.
> In fact, you have to do so. Even though they are initialized
> differently
Both lists and dictionaries auto-grow in Python. HOWEVER, Python
differentiates between ADDING, vs, REASSIGNMENT, where Perl does
not.
Compare:
list.append( newElement )
to Perl's closest equivalent:
list[ $#list + 1 ] = $newElement
Compare, also:
list = ( "One", 1, 1.0 )
dict = { "Test" : list }
t = list.append( dict )
print t[1]["test"]
print t
to the equivalent Perl code:
Uh. . .
Uh. . .
Darn, I can't get my example to work (my Perl book
has been borrowed, while the Python example was done
from memory. . . I know this requires references, but
for the life of me, cannot remember exactly how to
state this)! Anybody who wants to, please show an
equivalent example.
Anybody? Here's your chance to show what a Perl-DWIM-wit
I am. . . :-)
> a = ["alpha", "beta", "gamma"]
> d = {"fred": "wilma", "barney": "betty"}
>
> But they look the same on access:
>
> print a[0]
> print d["fred"]
Yup. Unmapping is. . . unmapping. Python is
polymorphic, here.
> You aren't able to add something to them the same way. For
> adding a new slot to the dictionary where there wasn't one,
> you can just use
>
> d["more"] = "stuff"
>
> but the list requires a completely different syntax. In fact,
> it requires a function call! And you can't call
OOps. That isn't a function call. list.append( x ) is
a message send.
And, it would be wrong for these to be the same (list vs. dictionary)
because for this operation, the semantic differences between
dictionaries and lists require different operations.
Or, to make it clearer, just how do you append a new element
to a hash in Perl?
> d.append("more" : "stuff")
>
> Perl is much more consistent here than Python is.
'Scuse, but again, it depends on your point of view.
The message: append, implies an ordering between keys.
Dictionaries do not supply key ordering (they are exactly
like Perl hashes, in this case), so "append" is not a
valid message to send to a dictionary object.
> Finally, consider this code in Perl. This is a complete
> program.
>
> $n{"alpha"}{"beta"}{"gamma"}{"delta"} = 400;
> $n{"alpha"}{"beta"}{"gamma"}{"delta"} **= 2;
> print $n{"alpha"}{"beta"}{"gamma"}{"delta"}, "\n";
>
> Grab your mouse and do the old snarf-and-barf into Perl. You'll see
> that it prints 160000 as we saw before.
>
> To do the equivalent in Python is remarkably more tedious.
>
> n = {}
> n{"alpha"} = {}
> n["alpha"]["beta"] = {}
> n["alpha"]["beta"]["gamma"] = {}
> n["alpha"]["beta"]["gamma"]["delta"] = 400
> n["alpha"]["beta"]["gamma"]["delta"] = (
> n["alpha"]["beta"]["gamma"]["delta"]
> *
> n["alpha"]["beta"]["gamma"]["delta"]
> )
> print n["alpha"]["beta"]["gamma"]["delta"]
C'mon, Tom, you know better ;->.
A *SIMILIAR* Program would be:
n = { "alpha" : { "beta" : { "gamma" : { "delta" : 400.0 } } } }
def square(base):
return base * base
print square( n["alpha"]["beta"]["gamma"]["delta"] )
> Notice all those steps you have to go through? It's true that
> you can get by with just
>
> n = {'alpha': {'beta': {'gamma': {'delta': 400}}}}
See? I told you you knew better! ;->
> But the point is that Python refused to autoallocate for you.
Excuse, but Python did indeed automatically allocate on:
a.append( b )
Will automatically allocate a space for a new element in the container
class object 'a'.
What you are discussing here is the difference between two different
operations: which earlier you said should have different operators.
> You have to do all the hard work on your own. Perl, on the other
> hand, is much more helpful here, applying DWIM to do what you meant.
>
> And if you think that the dictionary example is rough, consider
> this Perl code:
>
> $n[20][20][20][20] = 400;
> $n[20][20][20][20] **= 2;
> print $n[20][20][20][20], "\n";
>
> Because a Python list can't grow by direct assignment the way
> a Perl array, a Python dictionary, or a Perl hash can, you can't
> just do repeated assignments in Python like
>
> n = []
> n[20] = []
> n[20][20] = []
> n[20][20][20] = []
> n[20][20][20][20] = 400
>
> That still won't work, of course.
Once again: Python has lists. Not arrays.
What you fail to point out is:
$n[20] = "DWIM"
in Perl will give you an ARRAY whose first 20 elements are assigned
default values.
In Python, if you really wanted to do something like this, you'd
do:
from Arrays import Array
myArray = Array(4, 21, 21, 21, 21)
myArray(20, 20, 20, 20) = 400
print myArray(20, 20, 20, 20)
Incidentally, if you want an array extension module for Python. . . just
ask. I've got two of 'em, and I would love to find out which you feel
is more DWIM for you.
> I've typed for you all morning long. I hope that this gives you a feel
> for some fundamental ways where Perl is more programmer-friendly than
> Python is. There are others, such as scoping issues, but these should
> suffice to provide you something of the flavor.
>
> --tom
Yup. I appreciate your spending the time on this, if for no other
reason
than it makes the mind set of a Perl programmer a little bit clearer.
Which,
incidentally, helps me to understand why I am slowly giving Perl up.
In summary: for you, Perl DWYM. For me, Python DWIM.
However, in all fairness, in the future you should include examples of
defining and using a class in both Perl and Python. . . as well as
hierarchical data structures.
Perl is neither superior to Python, nor inferior. Use the right tool
for the job (I've used Python from Perl, and vice versa to get
sufficient
speed).
John S.
------------------------------
Date: 13 Aug 1999 16:39:12 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37b49e90@cs.colorado.edu>
[courtesy cc of this posting mailed to cited author]
In comp.lang.perl.misc,
"Michael P. Reilly" <arcege@shore.net> writes:
:And consider:
: sub who {
: return ("fred", "george", "wilma", "jane", "pebbles", "judy");
: }
:
:Does this return a hash or an array?
Neither. It returns a list. Do with it as thou wilt.
:Except on the
:last year or so where there has been a flood of people new to scripting
:learning both Python and Perl, it would be fair to say that people who
:were learning Python had come from another scripting language, usually
:Perl.
First, define "scripting" in a way that means something clearly
distinct from "programming".
Next, let me point out that shell programmers (whom you would
likely call "scripters") take readily to Perl. Perl was designed
to make it easy for shell programmers and C programmers to get
a head-start. I don't really know any professional programmers
anymore who aren't C/C++ hackers, so this works fine. (I used
to know Fortran hackers, but they're mostly retired now.)
I suspect that shell/C programmers find Python not half so easy
to learn and understand as they find Perl. This is difficult
to measure, of course.
As for VISUAL BASIC SCRIPTERS or Pascal "scripters" or other such, I
don't know those people, so perhaps you have a point regarding them.
I can't say; I deal mostly with professionals. I have been told,
however, that these two broods are often happy with the same Python
constructs that absolutely infuriate C and Perl programmers. Lack of an
assignment is one of these, since it leads to loops whose status tests
must be deceptively stated. There are others, as you know.
:The majority of Perl users I've ever heard in the last four
:years who have touted Perl over Python have never even coded in
:Python.
Which, if true, would be a shame. I encourage Perl programmers trying to
learn or evaluate Python to take all the program examples at the ends of
the chapters in the Perl Cookbook and try to recode them in Python. These
are available at ftp://ftp.oreilly.com/published/oreilly/perl/cookbook/
for the snatching. If that's too hard, just start on the smaller recipes
instead. In any event, this would be extremely instructional.
:But you are perfectly correct, each person needs to evaluate why they
:like or do not like the languages. And in corelation to that, only
:when they can say they know both should they be commenting on what they
:know in a forum like this thread.
I certainly do not know both equally well, but neither am I ignorant
of Python. I cannot speak for others here.
As for your "leaving" the Perl community five years ago, certainly I
guard no memories of the event. What then are you doing now in this
newsgroup? :-) Of course, five years ago, Perl had only been a real
programming language for around a year. And yet to this day, many shops
continue to use perl4 for their scripting needs. That should tell you
several different things.
--tom
--
MSDOS is a Neanderthal operating system -- Henry Spencer
------------------------------
Date: 13 Aug 1999 16:50:37 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37b4a13d@cs.colorado.edu>
[courtesy cc of this posting mailed to cited author]
In comp.lang.perl.misc,
"John W. Stevens" <jstevens@basho.fc.hp.com> writes:
:Which makes Perl perfect for the lone programmer who comes from a
:Unix/C/Shell background, and who has no OO training.
That statement is trivially countered by demonstrating the zillions of
Perl OO modules people, have distributed to parties unknown to them.
I completely disbelieve this "lone programmer" crud, and challenge you
to defend it. I suspect that you're confusing "bad programmer" with
"lone programmer". A bad programmer will make code that you wouldn't
want to try to share and reuse. A good programmer makes good code.
Please don't pretend that you can't do that in Perl, or that it hasn't
been done. That there exist millions of horrible script kiddies with
CGI written all over them doesn't change any of this.
--tom
--
"36 percent of the American Public believes that boiling radioactive milk
makes it safe to drink."
--results of a survey by Jon Miller at Northern Illinois University
------------------------------
Date: 13 Aug 1999 16:51:59 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37b4a18f@cs.colorado.edu>
[courtesy cc of this posting mailed to cited author]
In comp.lang.perl.misc,
"John W. Stevens" <jstevens@basho.fc.hp.com> writes:
:OTOH, Python is perfect for the OO trained programmer who is part of
:a team, or where the code will have to be maintained over a long
:period of time by many different people.
As is Perl. A sound Perl OO module designed by a competent programmer
is certainly up to fitting that bill. A CGI monstrosity from a
script kiddie isn't, but this is irrelevant.
--tom
--
"Without knowing what I am and why I am here, life is impossible."
- Leo Tolstoy
------------------------------
Date: 13 Aug 1999 16:55:30 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37b4a262@cs.colorado.edu>
[courtesy cc of this posting mailed to cited author]
In comp.lang.perl.misc,
"John W. Stevens" <jstevens@basho.fc.hp.com> writes:
:Understanding somebody elses Perl. . . now that can be heart breakingly
:difficult.
Then they were a bad Perl programmer, or else you are. Perl doesn't force
you to write good code any more than English forces to write good prose.
When you find bad prose, whom do you shoot? The writer, not the language.
So, too, with Perl.
If it is counted against Perl fault that "stupid" people can program in
Perl, then so be it. This aspect has made many people's lives better,
even if they are too "stupid" or too "inexperienced" for a "real
programming language". They got their job done, and they're happy.
I doubt you want to maintain their code, but why did you hire someone to
write professionally maintainable code who had no demonstrated ability
to do so?
--tom
--
"The past was erased, the erasure was forgotten, the lie became truth."
-- George Orwell, 1984
------------------------------
Date: 13 Aug 1999 16:57:33 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37b4a2dd@cs.colorado.edu>
[courtesy cc of this posting mailed to cited author]
In comp.lang.perl.misc,
"John W. Stevens" <jstevens@basho.fc.hp.com> writes:
:> @array = ("fred", "wilma", "barney", "betty");
:> %hash = @array;
:> Is the same as:
:> %hash = ("fred", "wilma", "barney", "betty");
:> Because the list stored in the array will have its key-value pairs
:> re-interpreted when this is stored into the hash.
:
:Resulting, again, in someting confusing to the programmer who
:hasn't any idea of what the above does, and that is still
:somewhat confusing even to an intermediate Perl programmer.
:
:I can *guess*, from my Perl experience, that this creates a hash whose
:keys are the elements of the list, and that the data elements
:mapped to those strings are . . . wait a minute, I'm not absolutely
:sure.
:
:Let me try it. . . Ok, the data elements are set to either an integer
:zero, or a string whose contents are the zero character, or a floating
:point zero.
Goodness no, it doesn't mean that at all. Key-value pairs, dude.
--tom
--
QVIDQVID LATINE DICTVM SIT PROFVNDVM VIDITVR
------------------------------
Date: Fri, 13 Aug 1999 22:50:44 GMT
From: Skip Montanaro <skip@mojam.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <7p27g1$kf3$1@nnrp1.deja.com>
Russ Allbery:
> Ian Clarke:
>
> > I agree that conflict won't bring understanding, but I was hoping
> > that people familiar with the language could explain what is good
> > about Perl, without trying to start a conflict.
>
> You're doing the equivalent of asking people to describe to you why
> you might want to eat ice cream, in detail, while never taking a bite
> yourself. I really don't know how you'd expect people to be able to
> do that.
I'd much rather know what is good about the overall environment than the
language. Let's try and get beyond the details of language syntax and
explain what the Perl environment has that's not available to us
herpophiles. Someone else mentioned CPAN and perldoc. Those are two
excellent things that Python currently doesn't have. I believe there are
active projects in the Python world to try and provide similar
functionality, but they aren't there yet.
Are there application areas to which Perl has been applied that give it
an edge as far as available libraries? We know both languages have been
fruitfully applied to web stuff, both using CGI and other programming
interfaces. Can we build a table of application domains and point out
what the major packages available for each language are?
Given that most of us who use Python like its micro details better
(syntax, its subjective DWIMishness, etc) and probably always will, it's
the stuff that surrounds the language that will make a difference.
--
Skip Montanaro (skip@mojam.com, 847-971-7098)
Mojam: "Uniting the World of Music" http://www.mojam.com/
Musi-Cal: http://www.musi-cal.com/
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: 13 Aug 1999 17:00:52 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37b4a3a4@cs.colorado.edu>
[courtesy cc of this posting mailed to cited author]
In comp.lang.perl.misc,
"John W. Stevens" <jstevens@basho.fc.hp.com> writes:
:> For example, that's one reason why when you want numeric ordering you
:> use "==", but when you want lexical ordering you use an operator that
:> looks completely different: "eq".
:
:This is a bad thing, not a good thing. Again, it fails to be
:polymorphic, to say nothing about failing to be OO.
Wrong. I can assure you that not falling into the OO trap is considered
a strength not a weakness. You obviously have been under the altar
sipping at the communion wine at the Church of the Holy Object, whose
credo is "I am Object -- the way, the truth, and the light. Let no man
come unto his data save through Me."
Thank you, but Perl isn't going to force such idolatry down anyone's
throat, and the fact that it doesn't force them down on their knees
in worship of Lord Object cannot be counted against it.
You've got them if you want them. You don't have them if you don't
want them. We call it "free will". *THIS* is a a feature.
--tom
--
"Unix is the answer, but only if you phrase the question very carefully."
- Belinda Asbell
------------------------------
Date: 13 Aug 1999 17:02:26 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37b4a402@cs.colorado.edu>
[courtesy cc of this posting mailed to cited author]
In comp.lang.perl.misc,
"John W. Stevens" <jstevens@basho.fc.hp.com> writes:
:> Likewise, because an array and a hash
:> are, despite their interconvertibility, fundamentally different things,
:> they *look* different. Contrast Python's:
:>
:> b = ["alpha", "beta", "gamma"]
:> c = { "fred" : "wilma", "barney" : "betty" }
:> print "b nought is", b[0]
:> print "c fred is", c["fred"]
:>
:> with Perl's
:>
:> @b = ("alpha", "beta", "gamma");
:> %c = ( "fred", "wilma", "barney", "betty");
:> print "b nought is", $b[0];
:> print "c fred is", $c{"fred"};
:
:Correct. Python's behavior is preferable. Think: operator overloading
:in C++.
You seem to equate quantifiable benefit with mere opinion. Please work
on that. I don't want different things looking the same. It sucks.
That's an opinion. I prefer it that way. That doesn't make it better.
Objects are *NOT* ipso facto the Answer. Bad programmers persist.
--tom
--
"Imagine you are a congressman. Now imagine you are an idiot. But I repeat
myself."
- Mark Twain
------------------------------
Date: 13 Aug 1999 17:04:07 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37b4a467@cs.colorado.edu>
[courtesy cc of this posting mailed to cited author]
In comp.lang.perl.misc,
"John W. Stevens" <jstevens@basho.fc.hp.com> writes:
:> Accessing an array and accessing a hash are different operations.
:No, they aren't.
:
:That is the point of polymorphism.
Genuflect when you say that. And realize that it's completely
wrong-headed in these parts.
--tom
--
Does the same as the system call of that name.
If you don't know what it does, don't worry about it.
--Larry Wall in the perl man page regarding chroot(2)
------------------------------
Date: 13 Aug 1999 22:55:13 GMT
From: mdz4c@node9.unix.Virginia.EDU (Matthew David Zimmerman)
Subject: Re: Writing lines to file twice or more (newbie question)
Message-Id: <7p27oh$k49$1@murdoch.acc.Virginia.EDU>
In article <7p1nga$8u2$1@nnrp1.deja.com>, <zchon@my-deja.com> wrote:
> Any help would be greatly apperciated (This is
>my first really perl program, no way like
>learning how to swim then by being thrown in the
>deep end)
Right! Of course, by diving into this group, you may be swimming in
shark-infested waters... :)
We really need to see your code (a reasonable, relevant snippet of it,
say about 20 lines?) before we can help you fix it.
Matt
print "Just Another Perl Novice\n";
--
Matthew Zimmerman ------------ http://www.people.virginia.edu/~mdz4c
Interdisciplinary Biophysics Program --------- University of Virginia
| "You got to be very careful if you don't know where you're going, |
| because you might not get there." -- Yogi Berra |
------------------------------
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 511
*************************************
