[13128] in Perl-Users-Digest
Perl-Users Digest, Issue: 538 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Aug 15 06:17:16 1999
Date: Sun, 15 Aug 1999 03:10:09 -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 Sun, 15 Aug 1999 Volume: 9 Number: 538
Today's topics:
Re: Why use Perl when we've got Python?! <rra@stanford.edu>
Re: Why use Perl when we've got Python?! <sisk@mojotoad.com>
Re: Why use Perl when we've got Python?! <sisk@mojotoad.com>
Re: Why use Perl when we've got Python?! <sisk@mojotoad.com>
Re: Why use Perl when we've got Python?! (Abigail)
Re: Why use Perl when we've got Python?! (Abigail)
Re: Why use Perl when we've got Python?! (Abigail)
Win32::Process (Parent/Child Communication) <kangas@anlon.com>
Digest Administrivia (Last modified: 1 Jul 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 15 Aug 1999 01:07:07 -0700
From: Russ Allbery <rra@stanford.edu>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <ylso5la2ms.fsf@windlord.stanford.edu>
Abigail <abigail@delanet.com> writes:
> Russ Allbery (rra@stanford.edu) wrote:
>> I hope your editor doesn't insert literal tabs. People who use tab
>> stops other than eight and actually insert literal tabs, which they
>> then think represent four spaces despite the fact that the whole rest
>> of the world will see them as eight, have a circle of hell reserved for
>> them.
> Which is why I switched almost a decade ago changed the configuration of
> my editor such that it is hard to enter a literal tab. Hitting tab just
> inserts the appropriate amount of spaces.
> Yeah, that does mean creating Makefiles is a bit awkward. Considering
> the amount of coding Makefiles vs typing in other things, that's a price
> I gladly pay. Besides, a simple ':set tabinsert' turns the behaviour
> off.
You probably don't use emacs, judging from that, but for those people out
there who do and who want to do the same thing (rather than emacs's
default mode that automatically converts eight space indentation to tabs
behind your back), put:
;; Use only spaces when indenting or centering, no tabs.
(setq-default indent-tabs-mode nil)
in your .emacs file. makefile-mode overrides this setting and Tab when
editing Makefiles will still enter literal tabs.
--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
------------------------------
Date: Sun, 15 Aug 1999 03:18:08 +0000
From: Matt Sisk <sisk@mojotoad.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37B63170.46F06A93@mojotoad.com>
> A computer language can set you free? ;->
Insofar as it avoids setting constraints.
Matt
------------------------------
Date: Sun, 15 Aug 1999 03:58:53 +0000
From: Matt Sisk <sisk@mojotoad.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37B63AFD.159B1D8B@mojotoad.com>
"John W. Stevens" wrote:
> > When you find bad prose, whom do you shoot? The writer, not the language.
> > So, too, with Perl.
>
> Comparing Perl to English, and trying to emulate English, is in fact the
> basis for Perl's flaws.
>
> But the discussion was aimed more at "typesetting" not at "prose".
>
> When you find bad typesetting, who do you shoot? The system that
> encourages/allows bad typesetting. In this case, the flawed system
> is Perl.
Allrighty then, enter meaning vs. semantics. Shall we insist on
literal interpretation, or rely instead on native intelligence?
Does a sonnet cease to be so based on whitespace?
Matt
(cloak thyself in thine own insecurities)
------------------------------
Date: Sun, 15 Aug 1999 04:28:27 +0000
From: Matt Sisk <sisk@mojotoad.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37B641EB.1DBC8151@mojotoad.com>
John W. Stevens said:
> Proof, please, that Perl is 100x more popular than Python?
> (To prove this, you must find a random sample of people who
> have used both, then prove that of those who use both equally,
> that 100x as many prefer Perl).
Hmmm. In order to prove the enthusiasm of those that use 'A',
we must first limit ourselves to those that also use 'B'.
Okay.
Matt
------------------------------
Date: 15 Aug 1999 04:32:22 -0500
From: abigail@delanet.com (Abigail)
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <slrn7rd2au.a5.abigail@alexandra.delanet.com>
John W. Stevens (jstevens@basho.fc.hp.com) wrote on MMCLXXIII September
MCMXCIII in <URL:news:37B49CBA.772D9783@basho.fc.hp.com>:
;;
;; 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.
I fully agree with that. I would probably use Eiffel in such a case, as
it would the requirements for such a task in a better way than Python.
But doesn't this just solves the question "why do people still use Perl,
and not use Python?" Just because the cases were you have OO trained
programmers, that are part of a team where they have to write code
that's going to be maintained by many different people isn't that often?
Or at least, that the language of choice of such a team isn't that often
Python? Perhaps you should ask in comp.lang.eiffel, or comp.lang.ada why
they still use Eiffel or Ada - as those languages seem to be performing
similar tasks.
There are just hundreds of thousands of lone programmers out there with
a Unix/C/Shell background. Of course, that doesn't explain the fact
that with the Windows market as big as it's now, why Python is still
not getting as many followers as they like. Or does Perl also look
like Windows?
;; > 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.
I often see code of people that don't understand easily. But that's
seldomly due to the language. It's because of the design of the code.
Or how they break up things. Strange ways of passing data. Stuff like
that. Stuff that no language is going to solve. Bad programmers write
bad code in any language.
;; Understanding somebody elses Perl. . . now that can be heart breakingly
;; difficult.
"can", not "is". One can write hard to understand Python code as well.
;; > 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).
Because they are 2 different ordering. 42 < 100, but 100 le 42.
Now, if your language is such that you have different types for
strings and numbers, you can overload your operator, to have it
mean 2 different things. Is that a good thing? Which ordering is
being used in:
if foo < bar:
print "Hello, world!"
You argue that Python is so readable. Comparing elements should be
a very easy thing. But tell me, is 'foo < bar' comparing two strings,
or 2 numbers? Or do you have to look elsewhere in your program to
figure it out? Is that what you mean by readability?
;; > 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
Yes. What else do you expect? Should it print 17? It *does* give you a
warning if you tell Perl to warn you though.
;; > 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.
Why would a programmer write something of which he has no idea of what
it does? Cargo-cult programming is considered a bad thing by Perlers.
Perhaps the Python community adores it?
;; 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.
Well, anyone who had spend more than 3 minutes reading about hashes
would have seen several examples of this form. The fact you don't
know for sure says a lot about you, and little about Perl.
;; 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.
I'm not sure where you suddenly get those data elements from.
;; Due to the auto-coercion of Perl, I really don't know whether the
;; default values are integer zero, strings, or floating point zeros.
And you don't have to. In Perl, zeros are zeros, whether they are integer
zeros, string zeros, or float zeros. A Perl programmer doesn't have to
worry about trivialities like that. That makes for programs that are
more readable - no code doing casting or coercions.
;; > 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.
Polymorphism means you don't know what it does by just looking at it.
You need context. Guess what? In Perl the behaviour of functions
and operators depends on context as well.
;; 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.
Yeah, it tells me immediately that
print knurf % bral
is doing modulus, and not an sprintf. Python is sooooo readable, every
statement is immediately obvious.
That probably also why python uses " for strings not containing
newlines, and """ for strings containing newlines. Very, very
polymorphic.
;; > 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++.
Then why does Python use { } to define dictionaries, but [ ] to define
arrays, while both are indexed using [] ? I think the use of : in contrast
to , is good (but that's why Perl has => next to , ; Perl doesn't enforce
the use of => though). And indexing both arrays and dictionaries in the
same way has a merit as well. But why {} vs []? That's inconsistent.
Either you are polymorpic, or you don't. But doing it sometimes, and
not other times means you're obscure.
Oh, and before you argue that Perl uses both () for arrays and hashes,
but uses [] for indexing arrays and {} for indexing hashes, that's
because what's on the right hand side are lists, not arrays, nor hashes.
;;
;; 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.
And the OO aspect of that is?
It's true. You can't make a 'printSecondElement' in Perl as in Python.
Which is a good thing, as hashes don't have an ordering, and any
suggestion otherwise create obscure and hard to understand programs.
You'd write a similar sub in Perl like:
sub printSecondElement {
my $obj = shift;
print $obj -> [1] if ref $obj eq 'ARRAY';
print $obj -> {2} if ref $obj eq 'HASH';
}
with the added benefit it doesn't cause an error if someone passes
in something else.
It's also more readable than your Python program. It clearly indicates
it prints the second element (the one with index 1) if the argument is
an array, and it prints the element named '2', if the argument is a hash.
Now, why you want to call your function 'printSecondElement' to print
out the third element, is beyond me.
As for swapping elements, Perls
($a, $b) = ($b, $a);
is far more readable, and namespace friendly than your
d = a; a = b; b = d
;; > 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?
See above.
;; > 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.
Sure. If the keys of the lists don't contain any additional information.
But then, what would be the point of changing?
;; > 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;
print @b <= 2 ? "ADDING" : "REASSIGNING";
$b [2] = $c;
Easy. Isn't?
And of course, with your 'polymorphism' fetish, you have to love the
fact that you can do "$b [2] = $c", regardless whether it's reassigning
or adding. Or don't you love polymorphism anymore?
;; >
;; > >>> 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?
No, not really.
;; > 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?).
Let me get this straight. You have an array with at most 2 elements,
you assign something to the element with index 2, Perl grew the array
to create an element with index 2, then assigned your value to it,
and Perl didn't do what you meant? Do tell us, what *did* you mean
when you wrote: "$array [2] = 'frobnitz;' ?
;; > 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.
But what about polymorphism?
;; Compare:
;;
;; list.append( newElement )
;;
;; to Perl's closest equivalent:
;;
;; list[ $#list + 1 ] = $newElement
Bleah. You don't know Perl at all.
push @list => $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:
*What* equivalent Perl code?
>>> list = ("One", 1, 1.0)
>>> dict = {"Test" : list}
>>> t = list.append (dict)
Traceback (innermost last):
File "<stdin>", line 1, in ?
AttributeError: 'tuple' object has no attribute 'append'
Perhaps you mean to use [] in the first line? Let's try again:
>>> list = ["One", 1, 1.0]
>>> dict = {"Test" : list}
>>> t = list.append (dict)
>>> print t[1]["test"]
Traceback (innermost last):
File "<stdin>", line 1, in ?
TypeError: unsubscriptable object
Hmmm. Perhaps it is because dict has an element "Test" and not "test"?
>>> list = ["One", 1, 1.0]
>>> dict = {"Test" : list}
>>> t = list.append (dict)
>>> print t[1]["Test"]
Traceback (innermost last):
File "<stdin>", line 1, in ?
TypeError: unsubscriptable object
Nope. But, perhaps you meant t[3]?
>>> list = ["One", 1, 1.0]
>>> dict = {"Test" : list}
>>> t = list.append (dict)
>>> print t[3]["Test"]
Traceback (innermost last):
File "<stdin>", line 1, in ?
TypeError: unsubscriptable object
Nope. Hmmm. Perhaps we should look how t looks like.
>>> list = ["One", 1, 1.0]
>>> dict = {"Test" : list}
>>> t = list.append (dict)
>>> print t
None
My, my, my. It looks like list.append doesn't return anything.
Perhaps list is a mutuable object? Lets look what list is after
list.append.
>>> list = ["One", 1, 1.0]
>>> dict = {"Test" : list}
>>> t = list.append (dict)
>>> print list
['One', 1, 1.0, {'Test': [...]}]
Ah. So it looks like Python is difficult enough to confuse an experienced
user when it comes to simple things as growing a list.
Now, for the more subtle issues, one might wonder, with not use the
polymorphed + instead of list.append?
>>> list = ["One", 1, 1.0]
>>> dict = {"Test" : list}
>>> list = list + [dict]
print list
['One', 1, 1.0, {'Test': ['One', 1, 1.0]}]
Yes, yes, I know why it's different.
;; Uh. . .
;;
;; Uh. . .
And now for the Perl equivalent:
@list = ("One", 1, 1.0);
$dict = {Test => \@list};
push @list => $dict;
print $list [3] {Test}, "\n";
__END__
ARRAY(0x8120b20)
Granted, the latter isn't as nice a Pythons, but you can make the same
datastructure with the same easy as in Python.
However, we can make use of one of the standard modules:
use Data::Dumper;
@list = ("One", 1, 1.0);
$dict = {Test => \@list};
push @list => $dict;
print Dumper ($list [3] {Test});
__END__
$VAR1 = [
'One',
1,
1,
{
'Test' => $VAR1
}
];
The format is more verbose, but it does show exactly how the recursion
is there, instead of the [...], where you would have to guess which
list it is, would there be more than one list.
;; 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.
Perhaps you should stop boasting about you don't need the Python manual
and it's impossible to write Perl without the manual, as you can't
write a 4 line Python program that doesn't use anything that isn't very
basic without several bugs. What was that again you said about how OO
languages caused less bugs? You got the only OO aspect of the four liner,
*fundamentally* wrong.
;; 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?
$hash {newkey} = $newvalue;
Guess what? That's except for the way the indexing goes (because that's
a different way of indexing) identical as adding a new element to
an array:
$array [$newindex] = $newvalue;
There is of course, no equivalent of push, as there is no ordering in
hashes.
;; > 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.
That's a good reasoning. But don't you think the same reasoning
goes for indexing?
;; 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.
*TWO* of them? You mean there are *DIFFERENT* ways to do such a fundamental
thing as arrays? What's going to happen to all those poor programmers that
have to maintain code, and whose brain goes into overload mode as soon as
it hits something that isn't standard? After all, doing the same things in
different ways is the madness you accuse Perl of.
Abigail
--
perl -wlpe '}$_=$.;{' file # Count the number of lines.
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: 15 Aug 1999 04:47:55 -0500
From: abigail@delanet.com (Abigail)
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <slrn7rd389.a5.abigail@alexandra.delanet.com>
John Stevens (jstevens@bamboo.verinet.com) wrote on MMCLXXIV September
MCMXCIII in <URL:news:slrn7r9nde.h3c.jstevens@bamboo.verinet.com>:
%% On 14 Aug 1999 02:32:12 GMT, Sam Holden <sholden@pgrad.cs.usyd.edu.au> wrote:
%% >On 13 Aug 1999 20:04:03 -0700, John W. Stevens <jstevens@basho.fc.hp.com> wrote:
%% >>> In comp.lang.perl.misc,
%% >>> "John W. Stevens" <jstevens@basho.fc.hp.com> writes:
%% >>> :$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).
%% >>>
%% >>> Gosh, that's a feature. NOT.
%% >>
%% >>Perl doesn't have lists. Python doesn't have built-in arrays.
%% >
%% >You should learn some perl you now..
%% >
%% >@array = (1,10,20,30);
%% >$from_list = (1,10,20,30);
%% >$from_array = @array;
%% >print "$from_list\n$from_array\n";
%% >
%% >Will output :
%% >30
%% >4
%%
%% The @ prefix denotes an array. You, yourself, should learn
%% Perl. Calling an array a list, doesn't make it one.
He doesn't. Please, get yourself a copy of Learning Perl and learn Perl.
I don't see any @ in "(1, 10, 20, 30)", so your point is totally moot.
%% >Perl has lists,
%%
%% Not built in, it doesn't, unless you define array and list as being
%% different words for exactly the same type/class.
Arrays and list are 2 different things in Perl. Perl has lists. They
are however, not the same as Python lists. Don't assume that because
someone mentions "list", Python lists are meant.
%% >if you know perl you would know this.
%%
%% I know Perl. You need to learn Python.
The extend of Perl knowledge you have shown in this thread is less
than the average script kiddie knows.
%% >If you program in perl
%% >and don't know this, then you must get very very confused at times.
%%
%% If @ denotes list, then the following Perl would be illegal:
But it doesn't denote lists. Your premise is wrong.
%% @ary = (1, 2, 3);
%% @ary[5] = "Test";
%%
%% But, obviously, this is not illegal.
Indeed. The second line is considered bad style though, and it will
be flagged as a warning with -w. What the second line has to do with
lists, I have no idea. The first line contains a list, on the RHS of
the assignment.
%% >>I will assume that a list module is available for Perl.
%% >
%% >No it is one of the built in bits... like hashes and arrays.
%%
%% Really? What is the prefix character that denotes a list?
There isn't. Just like there isn't a prefix character for operators.
There isn't a prefix character for decimal numbers either. What's
your point?
%% >>I wasn't trying to compare features, I was simply pointing out
%% >>that your comparison was Apples and Oranges, and therefore at
%% >>least somewhat invalid.
%% >
%% >Only because you have no idea what you are talking about.
%%
%% :-)
%%
%% Coming from somebody who doesn't know the difference from *EMULATING*
%% a list with an array, vs. a real array, that is a good one!
Let me repeat that: You have no idea what you're talking about.
%% Now I suppose that you will tell me that Perl has stacks, too!
I don't think he will. Sam has shown more Perl knowledge than you have.
Abigail
--
package Just_another_Perl_Hacker; sub print {($_=$_[0])=~ s/_/ /g;
print } sub __PACKAGE__ { &
print ( __PACKAGE__)} &
__PACKAGE__
( )
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: 15 Aug 1999 05:04:09 -0500
From: abigail@delanet.com (Abigail)
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <slrn7rd46m.a5.abigail@alexandra.delanet.com>
John Stevens (jstevens@bamboo.verinet.com) wrote on MMCLXXIV September
MCMXCIII in <URL:news:slrn7rb0uh.cf9.jstevens@bamboo.verinet.com>:
() On 14 Aug 1999 03:36:23 GMT, Sam Holden <sholden@pgrad.cs.usyd.edu.au> wrote:
() >On Sat, 14 Aug 1999 03:08:33 GMT,
() > John Stevens <jstevens@bamboo.verinet.com> wrote:
() >>On 14 Aug 1999 02:32:12 GMT, Sam Holden <sholden@pgrad.cs.usyd.edu.au> wrote:
() >>>On 13 Aug 1999 20:04:03 -0700,
() > John W. Stevens <jstevens@basho.fc.hp.com> wrote:
() >>>>
() >>>>Perl doesn't have lists. Python doesn't have built-in arrays.
() >>>
() >>>You should learn some perl you now..
() >>>
() >>>@array = (1,10,20,30);
() >>>$from_list = (1,10,20,30);
() >>>$from_array = @array;
() >>>print "$from_list\n$from_array\n";
() >>>
() >>>Will output :
() >>>30
() >>>4
() >>
() >>The @ prefix denotes an array. You, yourself, should learn
() >>Perl. Calling an array a list, doesn't make it one.
() >
() >Can you read?
() >
() >Can you see a @ in the following line of code :
() >
() >$from_list = (1,10,20,30);
()
() Your example included:
()
() @array = (1,10,20,30);
() $from_list = (1,10,20,30);
() $from_array = @array;
() print "$from_list\n$from_array\n";
()
() The line you specify does not contain a list, it contains a
() tuple.
A tuple? In Perl? Hmmm. Let's see, what does the manual say about
tuples....
$ cd /opt/perl/lib/5.00503/pod
$ grep tuple *.pod
$
Strange. You must be the only person believing that Perl has tuples!
Of course, you can randomly relable everything, but then you're just
like a 5 year old.
() >No you can't. Is there an array in that line of code?
()
() No, and that isn't a list, even if you call it one. It is a tuple.
Repeat after me: Perl does not have tuples.
() >No. Is there a list
() >in that line of code?
()
() No, it's a tuple, not a list.
Let me repeat that again: Perl does not have tuples.
() >Yes.
()
() No. Calling it a list, doesn't make it a list.
You must mean: "Calling it a tuple, doesn't make it a tuple."
It's a list. It has always been a list and it shall always be
a list.
() To be able to perform operations on the above, you'd have to
() assign the values of the tuple to an array.
You're so boring. There are no tuples in Perl.
() In which case you'd be performing array operations, not list
() operations.
()
() >>Not built in, it doesn't, unless you define array and list as being
() >>different words for exactly the same type/class.
() >
() >I don't think you can get more built in then perl lists.
()
() You get tuples in Perl. The book calls then lists, but you cannot
() perform any of the standard, defined list operations on a Perl
() "list".
()
() All "list" operations are performed by shoving "lists" into
() array's.
()
() Go ahead, show me a variable that contains a list. In your
() example:
As Sam said, there are no variables containing a list.
()
() $from_list = (1,10,20,30);
()
() $from_list isn't a list.
()
() >Again I repeat, here is a perl list : ('a', 'b', 'c') or qw(a b c)
()
() Again, you are wrong. The construct ('a', 'b', 'c') is a tuple.
() Perl'ers may call it a list, but how do you perform a an insert
() on the above?
Perlers call it a list. It's Perl code. Perl predates Python. Perlers
outnumber Pythoners. Hence, it's a list. No matter how much you whine.
List. List. List.
And of course you don't perform an insert on a list, for the same reason
you don't increase the number 5.
() You don't. You copy the contents of your tuple into an array,
() then perform array operations on that array.
There are no tuples in Perl.
() >>I know Perl. You need to learn Python.
() >
() >Did I mention a single bit of python syntax in my post? No.
()
() So what? I can still make a comment. And if you had been
() paying attention, you would have realized the context of this
() thread.
You should pet your cat more often.
() More specifically, had you studied Python, it would have been
() clear that what Perl calls a list is more properly refered to
() as a tuple.
Had you know a little bit of Perl, you would have known what a list was.
() If @ary were a list, it would be illegal.
Sure. And if @ary were a horse, it couldn't bark. What's your point?
@ary is an array. Not a list.
() >It is just
() >the special case of :
()
() Stop. You are talking about arrays, not lists. I repeat, if
Wrong.
() @ary were a list, the above operation would be illegal.
I repeat, if @ary were a horse, it couldn't bark. Your premise is
silly, and totally beside the point. @ary is an array. What it
can or cannot do if it were something else is irrelevant.
() >@ary[1,2,3,4,5,10,20]
() >
() >It is an array. Thus it has a @.
()
() Yes. It is an array, not a list. Though to be perfectly anal,
() it might be best to refer to that as a vector. . . ;->
It's the 5 year old again, making his own lables for everything.
() >>Really? What is the prefix character that denotes a list?
() >
() >You can't have a list in a variable.
()
() Correct. So, Perl does not have lists, it has tuples.
Wrong. Perl does not have tuples, it has lists.
() >Again here is a list :
() >
() >(1,2,3,4,5,6,7,8)
()
() No, that is a tuple.
It's a list, you bozo.
() >push( (1,2,3,4,5), 6);
() >
() >This results in an error message, funnily enough the message is :
() >Type of arg 1 to push must be an array (not list)
()
() Yes. But calling a tuple a list (or for that matter, calling an
() array a list) does not make it one.
Bzzzt. Wrong. Totally wrong. By calling a list a tuple doesn't make
the list a tuple.
() Had that been a real list, and assuming that "push" really means,
() append, that should have been legal.
Of course not. It's illegal on lists, and there is no such thing
as unreal lists in Perl.
() >Still claim perl has no lists?
()
() Yes.
But we already know your knowledge of Perl isn't worth writing about.
Claim anything you want. It won't carry any weigth.
() >Of course you know better then perl itself.
()
() In this case, I would say that Perl should use the same terminology
() as other fields of study. So, yes, I would consider that Perl
() makes a mistake, calling this a list.
Perl outdates Python. So there.
Abigail
--
perl -MTime::JulianDay -lwe'@r=reverse(M=>(0)x99=>CM=>(0)x399=>D=>(0)x99=>CD=>(
0)x299=>C=>(0)x9=>XC=>(0)x39=>L=>(0)x9=>XL=>(0)x29=>X=>IX=>0=>0=>0=>V=>IV=>0=>0
=>I=>$r=-2449231+gm_julian_day+time);do{until($r<$#r){$_.=$r[$#r];$r-=$#r}for(;
!$r[--$#r];){}}while$r;$,="\x20";print+$_=>September=>MCMXCIII=>()'
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: Sun, 15 Aug 1999 03:28:10 -0500
From: Mike <kangas@anlon.com>
Subject: Win32::Process (Parent/Child Communication)
Message-Id: <37B67A1A.EF0D24D0@anlon.com>
I have Win32::Process create up to 5 child programs and when one child
dies the parent then creates another. I would like to know how to pass
variables from the child to the parent. Currently I have the child print
a file of its results and when all children are finished the parent
reads this file.
If you know how to pass this data to the parent other than through a
flat file this information would be greatly appreciated.
Thanks ahead of time.
--
Michael Kangas
Anlon Systems, Inc.
kangas@anlon.com
------------------------------
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 538
*************************************
