Why use Perl when we've got Python?!
John W. Stevens
> [courtesy cc of this posting mailed to cited author]
>
> In comp.lang.perl.misc,
> "John W. Stevens" <jste...@basho.fc.hp.com> writes:
> :Perl is harder to learn how to read, harder to remember how to read,
> :and harder to read if you, yourself, did not write it.
>
> Proof my assertion, eh? I disbelieve. I want to see quantifiable,
> reproducible, and consequently irrefutable proof that Perl code that I
> did not write is harder for me to read than Python code I did not write.
Been there, done that.
No matter what I said, you would disbelieve.
That's Ok. Every language needs its proponents.
I've done the test often enough, with enough different groups to
be confident in my statement (assuming that you understand that
"you" means the average programmer, not you, Tom).
John S.
John W. Stevens
> [courtesy cc of this posting mailed to cited author]
>
> In comp.lang.perl.misc,
> "John W. Stevens" <jste...@basho.fc.hp.com> writes:
> :it?)
> :programmers are writing OO-Perl?
>
> What the heck is "Perl II"?
Perl 5 is not just Perl 4 with a few changes. It's darn near a
new language, hence: Perl II (you know, like Modula 2, then Modula 3?).
> And what is "OO-Perl"?
Object Oriented Perl.
> How many of us write new OO libraries?
> Use existing OO libraries? What?
Any or all of the above.
John S.
John W. Stevens
> :better language for [YOUR NEWSREADER SCREWED THIS UP]
> :OO, and I write OO most of the time. I know you disagree. But my
> :students, [YOUR NEWSREADER SCREWED THIS UP]
> :in general, also believe that Python is a better OO scripting language
> :than [YOUR NEWSREADER SCREWED THIS UP]
> :Perl.
>
> What's a "scripting" language, for goodness sake?
A scripting language? Read Ousterhout's paper on the subject.
Admittedly, the classifications are not sharply bounded.
John S.
John W. Stevens
> :makes [YOUR NEWSREADER SCREWED THIS UP]
> :it easier to code in *YOUR* way
> :(there-is-always-more-than-one-way-to-do-it), [AND THIS ONE]
> :but this (just like natural language) provides greater opportunities for
> :confusion and ambiguity in the mind of the reader.
>
> Perhaps then the problem is actually the plummeting literacy rate.
Oh, I doubt it. The biggest problem in management is the requirement
to use a natural language to manage people (allowing for far to many
ambiguities and mis-understandings).
Illiteracy doesn't help, of course. But I don't think it is the
root problem.
John S.
John W. Stevens
> :a team, or where the code will have to be maintained over a long
> :period of time by many different people.
>
> As is Perl.
That turns out not to be the case. In three projects that started
out in Perl, two were eventually converted to Python, for just that
reason: Python is the much better choice for those kinds of tasks.
> A sound Perl OO module designed by a competent programmer
> is certainly up to fitting that bill.
That turns out, again, not to be the case. Unless, of course, you
define competent in a self-referential fashion.
John S.
John W. Stevens
> :difficult.
>
> Then they were a bad Perl programmer, or else you are.
You are so big on assertion vs. proof: so prove the above. If you
can.
> 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.
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.
> If it is counted against Perl fault that "stupid" people can program in
> Perl, then so be it.
That is your mouth . . . this is mine. I said nothing, ever, about
stupid programmers.
My criticism goes towards what should be obvious: slang can and does
make it more difficult to understand what others are saying, until
you learn that slang. The more slang (the more variants allowed)
the more difficult a language is to learn.
Just ask any non-native speaker who is trying to learn American English.
> This aspect has made many people's lives better,
> even if they are too "stupid" or too "inexperienced" for a "real
> programming language".
Oh, Perl is as close to a real programming language as you can get. . .
assuming you subscribe to Porters definition of a "real programmer"! ;->
> They got their job done, and they're happy.
"They" may be happy. Their team members are another story.
> 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?
In point of fact, when the projects mentioned before were shifted to
Python, three things happened:
1) Productivity went up.
2) Defects went down.
3) Maintenance costs went down.
Maybe it is Python that is easier for stupid programmer to use, not
Perl?
John S.
John W. Stevens
> :> %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.
???
When I tried it, then unmapped back, I got some kind of zero.
So much for DWIM. Perl didn't do what I meant, there, and I couldn't
even guess, I had to try it.
And had I run across this idiom in a Perl program, I would have had harsh
words for the author, unless the code had been heavily documented.
John S.
John W. Stevens
> :> 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.
And you have a tendency to jump to conclusions. The benefits are
quantifiable. They are not opinion. Been there, done the statistics.
> I don't want different things looking the same.
That was the point: they are not different. Polymorphic.
> It sucks.
> That's an opinion. I prefer it that way. That doesn't make it better.
Your opinion is noted. The benefits of OO, however, are not opinion.
They are indeed quantifiable.
> Objects are *NOT* ipso facto the Answer.
I never said that they were. They provide a step in the right
direction.
> Bad programmers persist.
Indeed.
John S.
John W. Stevens
> :> 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."
I don't suppose you recognize exactly those same traits in yourself, as
you are making fun of in me? Just a different God?
You worship at the altar of "freedom, and damn the costs or consequences!"
> 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.
Perl does indeed "force" it's users. It just forces something else
on them.
> 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.
Now, just how do you use an OO Perl module, without using OO? What is
the magic incantation to un-OO in Perl when I don't want to OO, and I'm
including an OO-Perl thingie?
Python, too, can be used as a purely procedural language, if you are
so inclined.
John S.
John W. Stevens
> [courtesy cc of this posting mailed to cited author]
>
> :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.
Wrong headed: as in, I don't worship at the same altar as you do?
John S.
John W. Stevens
> :used correctly, it is very powerful.
>
> No disagreements.
>
> But I can't help but wonder: Is this how you keep out 99% of the
> accidental programmers, the ones who use Perl?
Who says I keep anybody out of anything? I teach OO. Not C++, or
Smalltalk. . . OO.
> If you require OO training
> and discipline, then you set the bar at the gate untenably high.
An opinion. Duly noted, of course. But still an opinion.
> Perl remains proudly pedestrian in its roots.
What does that mean?
> It doesn't require a Computer
> Science degree to use.
Neither does Python. But, why in heaven's name would you talk first
about competence, then state it as a benefit that Perl can be used
by the untrained?
Why, in heaven's name, would you prefer Joe Blow (who has worked for
five years as a butcher) to perform your brain surgery, to a Medical
Doctor with a degree in Neuro Surgery?
> This, too, is a feature. Formal training is
> optional.
"Formal traing is optional"
Now, what defines the difference between "formal" and "informal"
training? And, how do you figure that OO is more difficult, more
formal than what-ever-it-is that you are talking about?
John S.
John W. Stevens
> :except as a training language in OO classes. Not to surprisingly,
> :Python is preferred more than 7 to 1 over Perl by students who are
> :exposed to both at the same time.
>
> I'm sure I am perfectly capable of presenting both Perl and Python
> in such a way that the students would prefer Perl by 7 to 1 as well.
Except that in your case, it would a concious attempt to influence
the outcome.
In my case, it was not. In fact, the first four times I did this,
I was subconciously favoring Perl. Imagine my shock. . .
> So what?
So. . . draw your own conclusions. I've already seen how you
structured one reply.
John S.
John W. Stevens
> :
> :> 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.
Python, however, has an array module as part of its standard library.
I will assume that a list module is available for Perl.
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.
John S.
John W. Stevens
> :>
> :> 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?
>
> Wrong. I am merely sticking something at a particular place.
> If that place doesn't exist yet, MAKE IT SO. Don't make
> me check the length first.
Your own reply indicates that these are two different operations.
In adding, you know you will not be overwriting and existing reference.
In assignment/reassignment, you don't. When combining the two, you
are forced to add checks to determine the difference.
> :Excuse, but the two cases are different. One is reassignment. The
> :other is resize-list-and-add-a-new-element.
>
> Don't be ludicrous.
I'm not.
FYI: I have consistently treated you with respect. I ask only
that you do the same. However, this reply makes me wonder.
You know darn well that adding something to a container
object is is different than putting something into an
existing slot.
> I don't care whether something is there before.
Which goes a long way towards explaining some of those Perl
defects I was refering to in other replies. . .
> Are you telling me that python should have one syntax for
>
> s = "original string"
>
> and then a different one for
>
> s = "a new string that replaces the old one"
A variable is not a container class instance. Your analogy is fatally
flawed.
> It doesn't do that for dictionaries.
An acknowledged flaw in Python's orginal dictionaries, one which has
been partially solved on extraction through the addition of the get
method. Insertion remains to be fixed, as there is some philosophical
disagreement as to the correct semantic.
> It shouldn't do so for lists.
Lists, by definition, do not have "empty", or non-existent slots, so
overloading assignment could violate the semantic of "list". Append
is both simpler, and less error prone.
So I must strongly disagree. The existing system is more correct.
John S.
John W. Stevens
> [courtesy cc of this posting mailed to cited author]
>
> :
> :to Perl's closest equivalent:
> :
> :list[ $#list + 1 ] = $newElement
>
> Don't be silly. That's merely
>
> push @array, $new_element;
>
> Although you can use the other way if you'd like.
> I hope that freedom doesn't bug you too much.
However, using a stack operation on an array that you are currently
attempting to use to represent a list provides many opportunities
for misunderstandings, and out right bugs.
John S.
John W. Stevens
> [courtesy cc of this posting mailed to cited author]
>
> In comp.lang.perl.misc,
> "John W. Stevens" <jste...@basho.fc.hp.com> writes:
> :
> :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'.
>
> Sometimes it autoallocates on assignment. Sometimes it doesn't.
> This is obviously inconsistent.
So much for freedom. . . and this from a Perl guru!
The differences are based on the differences between an object of
one class, vs. an object of another class.
By your reasoning, Perl is very, very inconsistent (since not every
data type supports '+').
> Perl, however, is perfectly consistent
> here across all assignment operations, and Python isn't.
Which represents a flaw in Perl. Different classes should/must
treat "assignment" in different fashion.
> It's as clear
> as that.
Yes. It is.
John S.
John W. Stevens
> [courtesy cc of this posting mailed to cited author]
>
> In comp.lang.perl.misc,
> "John W. Stevens" <jste...@basho.fc.hp.com> writes:
> :
> :list = ( "One", 1, 1.0 )
> :dict = { "Test" : list }
> :
> :t = list.append( dict )
>
> That's illegal. You've used a list operation
> on a tuple.
Yes, it is. I should have used a list, and I should have tested the
code, first.
>
> :print t[1]["test"]
> :print t
>
> Now I'm confused. The return from value from a list append
> operation is None. Are you sure you mean that? Furthermore,
> you have to "test" element, just a "Test" one.
>
> I think I'm going to assume you meant this:
>
> list = [ "One", 1, 1.0 ]
> dict = { "Test" : list }
> list.append(dict);
>
> or maybe that was
>
> t = [ list, dict ]
>
> :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. . . :-)
>
> $list = [ "One", 1, 1.0 ];
> $dict = { "Test" => $list };
>
> And then either
>
> push @$list, $dict;
>
> or else
>
> $t = [ $list, $dict ];
Thanks for the two missing magic characters (@$, and =>). I always
have to look them up.
The fact that you have a $dict that has $, instead of a %, is
very confusing.
> The bottom line is that that is hardly any different from what
> you had.
I beg to differ. The operations are the same as some other equivalent
operations, but require different syntax. . . something that you
already railed against in Python.
John S.
John W. Stevens
> [courtesy cc of this posting mailed to cited author]
>
> In comp.lang.perl.misc,
> "John W. Stevens" <jste...@basho.fc.hp.com> writes:
> :> They can look at %h and @a and know these are different.
> :
> :Yes. A flaw, for OO.
>
> BFD.
Yup, a big deal.
John S.
John Stevens
>In comp.lang.perl.misc,
> "John W. Stevens" <jste...@basho.fc.hp.com> writes:
>:a team, or where the code will have to be maintained over a long
>:period of time by many different people.
>
>is certainly up to fitting that bill.
Of course. The question isn't: can it be done? The question is:
on the average, which is better?
>A CGI monstrosity from a
>script kiddie isn't, but this is irrelevant.
Actually, they are *VERY* relevant! Those CGI monstrosities are
Perl, they go into the statistics, and somebody somewhere has to
maintain them, and somebody has to pay to get them maintained.
John S.
John W. Stevens
> [courtesy cc of this posting mailed to cited author]
>
> :Python program that actually compiles and runs.
>
> Ok, I just showed the paperboy some python programs, and he didn't
> think were readable at all.
"ME". The statement was: "ME".
Take that same paper boy, train him in Perl and Python at the same
time, and see which one he prefers. Go on, I'll wait. ;-)
> Please face it: terms like "readable" and "intuitive" are completely
> subjective, and therefore purely opinion.
This is incorrect. They are not subjective. They can be measured.
"Intuitive", when meant as: "leveraging off of existing learning
and habits, combined with techniques that take into account human
perceptual patterns" is both quantifiable and quite objective.
Visual acuity is, in fact, built right in to the human eye/brain.
It's not even cultural.
Since Python enforces visually acute coding practices, in general
Python will be more readable (since, whether you admit it or not,
Perl'ers span the range from using no whitespace at all, to using
wildly different mixes of indentation styles).
John S.
John W. Stevens
> [courtesy cc of this posting mailed to cited author]
>
> In comp.lang.perl.misc,
> "John W. Stevens" <jste...@basho.fc.hp.com> writes:
> :lament from a section manager: "I've got all this Perl code that
> :<fill-in-a-name> wrote, and nobody else can understand this stuff!"
>
> I am sick and tired of the implication that because stupid people write
> stupid Perl, that Perl is stupid.
That wasn't my implication at all.
I thought I was being quite clear. Perl allows for a greater range
in expression, which allows for a greater amount of ambiguitiy,
which creates a situation where maintaining code costs much, much
more.
> Stupid people are associated with
> everything! Perl is also 100x more popular than Python -- simple because
> even stupid people *are able* to use it!
Your premise and your conclusion are not logically relatable.
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).
Proof, please, that the reason Perl is more popular than Python
is due to the fact that stupid people are able to use it, while
stupid people are *NOT* able to use Python?
> And they do. And this is what
> we get for making something that even stupid people can use. I hope that
> Python should be someday cursed with one tenth the number of stupid people
> who now write Perl. Then your newsgroup can be as messy as this one.
>
> 1. Assume competence.
I do. I have noted, though, that competent people are not the same
as disciplined people. I have noted that competent people are not
always competent at everything. I have even noted that brilliance,
and the ability to created unmaintainable code are not always
mutually exclusive.
> 2. Train the ignorant.
Of course. For five years, I did just that.
> 3. Fire the stupid.
Harsh, but it works.
John S.
John W. Stevens
> [courtesy cc of this posting mailed to cited author]
>
> In comp.lang.perl.misc,
> "John W. Stevens" <jste...@basho.fc.hp.com> writes:
> :been settled years
> :ago. . .
>
> Don't be silly. We merely contained our laugher for the nonce.
Perhaps you should read the relevant papers from the DOD studies, the
human perception types, and the language theory types. . .
Seems pretty proven, to me.
John S.
John W. Stevens
> [courtesy cc of this posting mailed to cited author]
>
> In comp.lang.perl.misc,
> "John W. Stevens" <jste...@basho.fc.hp.com> writes:
> :point of fact Python is more correct than Perl for this
> :example.
>
> It is wrong from the Larry's principle that things that behave
> differently should have different appearances.
Then why doesn't Perl have two different operations for
assign/reassign, vs. add to an array? A tiny little violation of
Larry's principles, that.
John S.
John W. Stevens
> [courtesy cc of this posting mailed to cited author]
>
> In comp.lang.perl.misc,
> "John W. Stevens" <jste...@basho.fc.hp.com> writes:
> :in the OO world.
>
> Perl is not about shoving an OO agenda down someone's throat.
I note, with surprise, the slant you put on my reply.
If I were to slant back, I would say that Python is not about
shoving some line-noise looking procedural agenda down somebodies
throat.
But, I won't.
Don't like OO? Fine. Don't use OO.
But if you do like OO, don't Perl.
John S.
John W. Stevens
> :the prefered choice . . . *EXCEPT* where the programmers were
> :experienced C programmers.
>
> Well what else are you going to get? BASIC programmers? Now those
> are clever folks for you! Of course most programmers are C (or C++)
> programmers.
Sigh. Not "of course". There are quite a few programmers, now, who
don't have a C/Unix background.
And, though I failed to mention it (I was trying to be a little bit
light), many of those C programmers came around after a while.
> It's the only real-world langauge that gets the jobs
> done in millions of environments. Every CompSci student should be
> proficient at C/C++. Anything else is fluff. Beneficial, but fluff.
Wow. Strong words.
I note, with some sadness, that you failed to mention Fortran or
Cobol, languages that also get the job done, in millions of
real world environments. Fortran and Cobol are fluff, hunh?
> I don't care whether they're proficient at six other languages, and
> in fact, I hope they know those six others, but C/C++ is what counts.
> What kind of "programmers" are you talking about?
Real programmers. Those who do it for a living. Some do C, others do
C++, yet others use Cobol, Fortran, Visual Basic, Objective-C, assembler,
Lisp, Prolog, Pascal, etc.
The whole world is *NOT* C.
> I think your newsreader is buggy. Better fix it.
My news reader works fine. Your news server or your news reader are
flawed. Better fix 'em. . .
John S.
John W. Stevens
> :non-authors than Perl programs are.
>
> Prove that. Stop asserting it. Prove it.
>
> Here's your challenge. Pick a Perl programmer with experience equivalent
> to mine, and show me their code.
Of course, there are very few Perl programmers that *HAVE* experience
equivalent to yours.
So doing what you suggest would prove nothing.
Perform the same test across even a randomly-selected sample, and
you will begin to see the pattern.
> I'm sure I'll find it perfectly legible.
Even for you, I doubt that. One Perl author in one of my environments
used no "unnecesary" white space at all. None. His code was
incomprehensible, even to the guy we brought in to teach Perl.
> I say this for certain because I *do* read their code, and it's completely
> easy to do so.
Yeah. Right. ;->
Been there, gathered the statistics.
> If you're talking about someone who can't stop treating Perl like
> BASIC or FORTRAN, and just doesn't `get' it, then sure, it's unnatural.
> But that's hardly my fault that they don't know Perl, now is it?
The fact that Perl lets them write unmaintainable code *IS* your
fault, when state of the art in language design can and does prevent
some of this.
What, you've never heard of a C coding style? Never seen one enforced?
Never, in your life, compared productivity levels, defect rates, and
repair costs across C or Perl code that has been written to an enforced
coding standard, vs. code that was totally free form?
Perhaps you should.
I have.
John S.
John Stevens
> [courtesy cc of this posting mailed to cited author]
>
>: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.
Zillions? Are you sure that this isn't a slight exageration?
After all, if what you say re: 100x's of times more Perl users
than Python, then even if OO were a much less used paradigm on
Perl than it is on Python, you'd still expect to see more.
Most importantly: I am not talking about absolutes, here.
A obsessively quality concious, extremely disciplined, very
experienced assembly language code writer can produce highly
efficient, easily maintained code.
The issue isn't one programmer, or even examples of many, but
statistical comparisons. The existence of a body of Perl code,
being maintained by a group that has a high turn over rate,
does not invalidate my point.
Compare costs, defect rates, etc. across many such groups,
and then you will have some data to work with.
>I completely disbelieve this "lone programmer" crud, and challenge you
>to defend it.
I've seen it repeatedly. Somebody wants to do something. They
drag in Perl. They write in Perl. Management gets all hot
about it, decides to support it, then the headaches hit.
>I suspect that you're confusing "bad programmer" with
>"lone programmer".
No, I'm not. I suspect, however, that you are confusing your
level of ability with "the average Perl programmer".
>A bad programmer will make code that you wouldn't
>want to try to share and reuse.
Agreed.
>A good programmer makes good code.
Also agreed. The issue isn't the lone programmer! The issue is
*groups* of programmers: teams, in relationship to an organization.
>Please don't pretend that you can't do that in Perl, or that it hasn't
>been done.
I haven't. I won't. The issue isn't what can and cannot be done,
the issue is the margin: which is *better*, on the average? Which
has lower costs? Which has lower defect rates.
The fact that you, personally, can write low defect, highly
maintainable Perl code is not the issue: the issue is the
average programmer, in the average organization, who has the
average amount of training.
>That there exist millions of horrible script kiddies with
>CGI written all over them doesn't change any of this.
Actually, yes, it does. Think about it.
John S.
Sam Holden
>> In comp.lang.perl.misc,
>> "John W. Stevens" <jste...@basho.fc.hp.com> writes:
>> :
>> :> 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
Perl has lists, if you know perl you would know this. If you program in perl
and don't know this, then you must get very very confused at times.
>
>Python, however, has an array module as part of its standard library.
>
>I will assume that a list module is available for Perl.
No it is one of the built in bits... like hashes and arrays.
>
>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.
--
Sam
Can you sum up plan 9 in layman's terms? It does everything Unix does
only less reliably.
--Ken Thompson
Sam Holden
>
>Thanks for the two missing magic characters (@$, and =>). I always
>have to look them up.
Learn some perl then. @ is pretty fundamental. $ is pretty fundamental.
What happens when you tell a scalr to be an array is pretty fundamental.
>
>The fact that you have a $dict that has $, instead of a %, is
>very confusing.
Only if you don't know perl. $dict is a scalar. %dict is a hash. In that
example a scalar was used.
At least in the discussions I have with people about python I don't
complain about python syntax I don't understand I just ask what it means.
Instead of calling it confusing people who actually want to learn something
ask what it means, and why it is so. You obviously don't want to
learn but only to criticise. That's fine but it would be better to just
post to the python group...
--
Sam
You can write Perl programs that resemble sed, or awk, or C, or Lisp, or
Python. This is Officially Okay in Perl culture.
--Larry Wall
Eric Bohlman
[quoting someone whose name was lost]
: > It is wrong from the Larry's principle that things that behave
: > differently should have different appearances.
:
: Then why doesn't Perl have two different operations for
: assign/reassign, vs. add to an array? A tiny little violation of
: Larry's principles, that.
Nope. "Behave differently" hear means "accomplish two different tasks."
Comparing two strings to see if they're equal lexically is not the same
task as comparing two strings to see if they're equal numerically.
Putting a particular value in a particular position in an array that
already holds a value *is* the same task as putting a particular value in
a particular position of an array that does not yet hold a value; the
only difference is in the internal details of how to accomplish it.
Of course, the OOically-correct way to handle the string comparisons is
to define a base class, ComparableString, and two subclasses,
LexicallyComparableSting and NumericallyComparableString, along with
polymorphic operators that understand which class they're comparing to
and apply the correct comparison method. But there are cases where you
may want to do *both* comparisons on a string, and to be OC you then have
to cast the string to the appropriate type; the Perlish way of picking
the operator director is IMHO easier and more maintainable; in my
experience, heavy casting makes code unreadable.
John Stevens
>On 13 Aug 1999 20:04:03 -0700, John W. Stevens <jste...@basho.fc.hp.com> wrote:
>>> In comp.lang.perl.misc,
>>> "John W. Stevens" <jste...@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.
>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.
>if you know perl you would know this.
I know Perl. You need to learn Python.
>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:
@ary = (1, 2, 3);
@ary[5] = "Test";
But, obviously, this is not illegal.
>>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?
>>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!
Now I suppose that you will tell me that Perl has stacks, too!
;->
John S.
John Stevens
>On 13 Aug 1999 20:05:12 -0700,
>>
>>Thanks for the two missing magic characters (@$, and =>). I always
>>have to look them up.
>
>Learn some perl then. @ is pretty fundamental. $ is pretty fundamental.
>What happens when you tell a scalr to be an array is pretty fundamental.
Oh, I *KNOW* the semantic. I just can't remember the syntax.
As for calling the conversion of a scalar to an array "pretty
fundamental". . . can you say "Extreme Exageration"?
Tom tells me that Perl doesn't exclude non-computer scientists,
then you guys start throwing around references to references. . .
:-)
>Only if you don't know perl.
No, it is confusing to the average programmer. If it isn't
confusing, to you, then you've spent a *LOT* of time learning
and using Perl.
>$dict is a scalar. %dict is a hash. In that
>example a scalar was used.
Yes. . . is it a hash, or a scalar? If it is a scalar, why
is it called dict? If it is a hash, then why is it prefixed
by $? If this is a reference instead of a scalar, then why
doesn't it have it's own special prefix character. ;->
>At least in the discussions I have with people about python I don't
>complain about python syntax I don't understand I just ask what it means.
I am not complaining about syntax I don't understand. I am complaining
about syntax that is unecesarily difficult to learn, remember, and use.
>Instead of calling it confusing people who actually want to learn something
>ask what it means, and why it is so. You obviously don't want to
>learn but only to criticise. That's fine but it would be better to just
>post to the python group...
What, you believe that you are a mind reader?
You are wrong. I know what the syntax means. I criticize because
it is indeed confusing, and difficult to remember.
>You can write Perl programs that resemble sed, or awk, or C, or Lisp, or
>Python. This is Officially Okay in Perl culture.
You cannot write Perl that resemble Python. You are required to
use curly braces as block delimiters.
John S.
Sam Holden
John Stevens <jste...@bamboo.verinet.com> wrote:
>On 14 Aug 1999 02:32:12 GMT, Sam Holden <sho...@pgrad.cs.usyd.edu.au> wrote:
>>On 13 Aug 1999 20:04:03 -0700,
>>
>>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);
No you can't. Is there an array in that line of code? No. Is there a list
in that line of code? Yes. Do lists and arrays behave differently? Yes, just
look at the different outputs.
>
>>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.
I don't think you can get more built in then perl lists.
Again I repeat, here is a perl list : ('a', 'b', 'c') or qw(a b c)
>
>>if you know perl you would know this.
>
>I know Perl. You need to learn Python.
Did I mention a single bit of python syntax in my post? No.
Was I discussing python syntax? No.
Do you know if I use python? No.
Do you know if I like python? No.
Do you know if I have already spent time learning python?
Do you know if I am currently learning python?
What was the point of saying I need to learn Python? I wasn't saying python
was worse than perl, I wasn't saying python syntax is strange, I wasn't
talking about python. You might as well have told me to learn C or Lisp.
At least Lisp would be more relevant than python, if you were trying to
tell me to learn about lists in some strange abstract way.
Have I questioned your python knowledge? No.
Have I questioned your perl knowledeg? Yes, but only because you have
consistantly made basic mistakes when speaking about perl.
>
>>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:
>
>@ary = (1, 2, 3);
>@ary[5] = "Test";
>
>But, obviously, this is not illegal.
@ary[5] is an array slice. It is an array. It happens to be an array
that constists of only one element. Why would it be illegal? It is just
the special case of :
@ary[1,2,3,4,5,10,20]
It is an array. Thus it has a @.
Used like that it is almost a sure indication of an error by the programmer,
because a single element array slice has no benefit over the simple
array element in that context.
>
>>>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?
You can't have a list in a variable. Lists in perl are constant. So
what would be the use of putting them in a _variable_. Just because there
is no list variable does not mean there are no lists. Again here is a list :
(1,2,3,4,5,6,7,8)
>
>>>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!
Again here is a list :
(1,2,3,4,5,6,7,8)
That is not an array. It is a list. It is different from an array. I already
showed how assigning to a scalar gives different results for lists and arrays,
here are some more differences :
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)
Still claim perl has no lists? Of course you know better then perl itself.
@array = (1,2,3,4,5);
push(@array,6);
That works fine, because we are passing an array to push not a list.
Pop is the same :
pop (1,2,3,4,5);
Is an error (the message is as above s/push/pop/)
@array = (1,2,3,4,5);
pop @array;
Is legal and pops the 5 off @array.
>
>Now I suppose that you will tell me that Perl has stacks, too!
>;->
No it doesn't.
--
Sam
why can't newbies use hash slices in their hello world programs? :-)
-- Uri Guttman in <x74skxh...@home.sysarch.com>
Sam Holden
John Stevens <jste...@bamboo.verinet.com> wrote:
>On 14 Aug 1999 02:39:10 GMT, Sam Holden <sho...@pgrad.cs.usyd.edu.au> wrote:
>>On 13 Aug 1999 20:05:12 -0700,
>>>
>>>Thanks for the two missing magic characters (@$, and =>). I always
>>>have to look them up.
>>
>>Learn some perl then. @ is pretty fundamental. $ is pretty fundamental.
>>What happens when you tell a scalr to be an array is pretty fundamental.
>
>Oh, I *KNOW* the semantic. I just can't remember the syntax.
>
>As for calling the conversion of a scalar to an array "pretty
>fundamental". . . can you say "Extreme Exageration"?
>
>Tom tells me that Perl doesn't exclude non-computer scientists,
>then you guys start throwing around references to references. . .
That could simply have been a reference. Or a symbolic reference.
What is fundamental is that a @ tacked on the front indicates that it is an
array. So given @$fred, even with no knowledge of what that exactly means
you should be able to tell that it is somehow treating $fred as an array.
>
>:-)
>
>>Only if you don't know perl.
>
>No, it is confusing to the average programmer. If it isn't
>confusing, to you, then you've spent a *LOT* of time learning
>and using Perl.
>
>>$dict is a scalar. %dict is a hash. In that
>>example a scalar was used.
>
>Yes. . . is it a hash, or a scalar? If it is a scalar, why
>is it called dict? If it is a hash, then why is it prefixed
>by $? If this is a reference instead of a scalar, then why
>doesn't it have it's own special prefix character. ;->
It's a scalar. It is named dict because TomC called it that. It is
also named that since it is a reference to a hash. I use code like this
in C quite a bit :
Tree *tree;
Even though tree isn't a tree, but a pointer to a tree. If you don't like
that then don't use it. It's a fairly common thing to do though, I've seen
it used in pascal, C and C++, so it is not unique to perl.
>
>>At least in the discussions I have with people about python I don't
>>complain about python syntax I don't understand I just ask what it means.
>
>I am not complaining about syntax I don't understand. I am complaining
>about syntax that is unecesarily difficult to learn, remember, and use.
>
>>Instead of calling it confusing people who actually want to learn something
>>ask what it means, and why it is so. You obviously don't want to
>>learn but only to criticise. That's fine but it would be better to just
>>post to the python group...
>
>What, you believe that you are a mind reader?
>
>You are wrong. I know what the syntax means. I criticize because
>it is indeed confusing, and difficult to remember.
If you know what it means then why do you continually get it wrong
throughout this thread?
>
>>You can write Perl programs that resemble sed, or awk, or C, or Lisp, or
>>Python. This is Officially Okay in Perl culture.
>
>You cannot write Perl that resemble Python. You are required to
>use curly braces as block delimiters.
In fact you are not. You are wrong yet again. Actually thinking about how
perl works for a minute would show you that perl is in fact flexible.
it is not a lie when people say perl doesn't force you to write a
particular way.
Here is some code from Damian Conway from the 'Impythonating PERL' thread
in march.
package impythonate;
use Text::Tabs;
my ($active, @bracket) = (0, ('{', ';', '}') );
sub import
{
return 1 if ($active++);
open CODE, $0 or die "couldn't translate $0";
my ($code, $transcode, $lastindent) = (join('',<CODE>), '');
$code =~ s/\\\n/ /g;
foreach (split /\n/, $code)
{
my ($indent,$notempty) = /\A([ \t]*)(\S?)/;
$indent = length(expand($indent));
$transcode .= $bracket[1+($lastindent<=>$indent)]
if $notempty && defined $lastindent;
$transcode .= "$_\n";
$lastindent = $indent if $notempty;
}
eval $transcode and exit or die $@;
}
1;
And here is his sample code that is now valid perl (although anyone who uses
it for real code should be killed) :
#Now newlines replace colons and indentation replaces brackets:
use impythonate; # STILL NEED THAT ONE SEMICOLON, DAMMIT!
for $i (1..10) # COMMENTS ARE OKAY
print "$i: "
my $isq = \
$i **2 # LINE CONTINUATIONS WORK AS IN PYTHON
print " $isq\n"
print "done\n"
--
Sam
Basically, avoid comments. If your code needs a comment to be
understood, it would be better to rewrite it so it's easier to
understand. --Rob Pike
Bart Lateur
>By your reasoning, Perl is very, very inconsistent (since not every
>data type supports '+').
You're looking for the Holy Grail of orthogonality, again. Python is
designed with orthogonality in mind, while Larry Wall allegedly once
said:
"Any computer scientist who praises orthogonality should be
sentenced to use an Etch-a-Sketch."
(borrowed from a TomC sig)
Bart.
Alex Maranda
actually appreciated the argument from your second post, when you taxed
the other guy for needlessly questioning your Python knowledge out of
context.
I am completely ignorant with Perl and I can barely read what's above
(by interpolating my knowledge of shell, C, and Tcl).
>
> #Now newlines replace colons and indentation replaces brackets:
>
> use impythonate; # STILL NEED THAT ONE SEMICOLON, DAMMIT!
>
> for $i (1..10) # COMMENTS ARE OKAY
> print "$i: "
> my $isq = \
> $i **2 # LINE CONTINUATIONS WORK AS IN PYTHON
> print " $isq\n"
>
> print "done\n"
I know Python fairly well (but I'm no expert) and I can easily read this
piece of Perl. Getting back to the killing part, which kind of disturbs
me when reading comp.lang.python:
- was that necessary to make a point?
- if yes, what was the point?
- if the point (just guessing) was that Perl code should never look like
Python, isn't that against of 'there should be more ways of doing it?'
I fail to see the interesting part in this whole thread, which disturbs
the habitat of comp.lang.python. I think John Stevens was mistaken to
bring the discussion over to this newsgroup in the first place. We don't
have strong feelings about Perl, and don't have plans for world
domination or anything.
A couple of days ago I read a bit in Bugzilla's README which amused me:
"A computer which doesn't have Perl installed is a very sad computer
indeed". Your post is frightening (unless it was a Perl-style joke).
Regards (I guess),
Alex
Dave
<jste...@bamboo.verinet.com> wrote:
> [blah blah blah]
John, please refrain from cross-posting all your messages to
comp.lang.python. If there is anything worse than getting a long and
pointless flame war, it is getting half a flame war. By cross posting
you are clearly trying to drag the readers of c.l.py into the
argument, which is pure trolling. If you continue you will merely
succeed in pissing off two newsgroups instead of one.
The 'my language is better than yours' debates are always pointless
and counterproductive, and perl vs. python has been done countless
times before. Life is too short, live and let live [insert other
cliches to taste].
Incidentally you are wrong about perl arrays and python lists being
different data structures - internally they are both implemented as C
arrays, only the names are different.
Dave Kirby
--------------------------------------------------
All great ideas start as heresy and end as dogma.
dkirby@ <-figure this out, spambots!
bigfoot. My opinions are my own,
com but I'm willing to share.
Fredrik Lundh
> You're looking for the Holy Grail of orthogonality, again. Python is
> designed with orthogonality in mind, while Larry Wall allegedly once
> said:
>
> "Any computer scientist who praises orthogonality should be
> sentenced to use an Etch-a-Sketch."
duh. even the mainstream dictionaries can tell the
interested reader that "orthogonal" means more than
just "intersecting/lying at right angles". for it's use
in computing, see FOLDOC.
</F>
John Stevens
>On Sat, 14 Aug 1999 03:08:33 GMT,
> John Stevens <jste...@bamboo.verinet.com> wrote:
>>On 14 Aug 1999 02:32:12 GMT, Sam Holden <sho...@pgrad.cs.usyd.edu.au> wrote:
>>>On 13 Aug 1999 20:04:03 -0700,
>>>
>>>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.
>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.
>No. Is there a list
>in that line of code?
No, it's a tuple, not a list.
>Yes.
No. Calling it a list, doesn't make it a list.
To be able to perform operations on the above, you'd have to
assign the values of the tuple to an array.
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:
$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?
You don't. You copy the contents of your tuple into an array,
then perform array operations on that array.
>>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.
>What was the point of saying I need to learn Python?
Because, in the words of TC, "Learning is a good thing".
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.
>You might as well have told me to learn C or Lisp.
Yes. You should. Had you learned Lisp, list processing would
be second nature to you, and you would have a clearer idea between
"lists" and "tuples" and "arrays".
>>If @ denotes list, then the following Perl would be illegal:
>>
>>@ary = (1, 2, 3);
>>@ary[5] = "Test";
>>
>>But, obviously, this is not illegal.
>
>@ary[5] is an array slice.
Yes. So what?
>It is an array. It happens to be an array
>that constists of only one element.
Again, so what?
>Why would it be illegal?
If @ary were a list, it would be illegal.
>It is just
>the special case of :
Stop. You are talking about arrays, not lists. I repeat, if
@ary were a list, the above operation would be illegal.
>@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. . . ;->
>>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.
>Again here is a list :
>
>(1,2,3,4,5,6,7,8)
No, that is a tuple.
>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.
Had that been a real list, and assuming that "push" really means,
append, that should have been legal.
>Still claim perl has no lists?
Yes.
>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.
John S.
John Stevens
>John W. Stevens wrote:
>
>>By your reasoning, Perl is very, very inconsistent (since not every
>>data type supports '+').
>
No, I'm not. I was, in fact, pointing out to Tom that his
stance was inconsistent even within Perl.
>Python is
>designed with orthogonality in mind,
No, it was not. Python was designed to simply and clearly communicate.
Proper use of orthogonality aids in making communications clear.
>[Cute sig snipped.]
John S.
[ "Perl. A language that looks like a C program that has been
victimized by line noise!"
"Yeah!? You think so!? Take a look at APL some time!"
"Oh, I have a Mac at home. . ."
]
John Stevens
>That could simply have been a reference. Or a symbolic reference.
>
>What is fundamental is that a @ tacked on the front indicates that it is an
>array.
:-)
What is so amusing about that, is that you can say that with a straight
face!
:-)
>So given @$fred, even with no knowledge of what that exactly means
>you should be able to tell that it is somehow treating $fred as an array.
No, what any reasonable person would do would be to grab for his
Perl book. . .
>>Yes. . . is it a hash, or a scalar? If it is a scalar, why
>>is it called dict? If it is a hash, then why is it prefixed
>>by $? If this is a reference instead of a scalar, then why
>>doesn't it have it's own special prefix character. ;->
>
>It's a scalar. It is named dict because TomC called it that.
Yes. My point exactly.
>It is
>also named that since it is a reference to a hash. I use code like this
>in C quite a bit :
A reference to a hash. . . and yet TC claims that Perl is open to
non-computer scientists.
:-)
Doesn't *ANYBODY* else see the irony in that?
>If you know what it means then why do you continually get it wrong
>throughout this thread?
I don't suppose that you realize that getting wrong simply
proves (and illustrates) my point?
I learned it. I used it. I haven't written a new Perl program
in three months.
I come back to it, I get it wrong. . . do you see, yet,
or do you just not get it?
>>You cannot write Perl that resemble Python. You are required to
>>use curly braces as block delimiters.
>
>In fact you are not. You are wrong yet again.
Actually, I'm right, and you go on to prove I'm right.
>Here is some code from Damian Conway from the 'Impythonating PERL' thread
>in march.
>
>package impythonate;
>use Text::Tabs;
>my ($active, @bracket) = (0, ('{', ';', '}') );
>sub import
>{
^ Look closely. . . see that curly brace?
>And here is his sample code that is now valid perl (although anyone who uses
>it for real code should be killed) :
To late. You already used a curly brace. Disproving your point,
in case you hadn't realized it.
John S.
John Stevens
>Sam Holden wrote:
>Why? You don't happen to hate Pythoneers or Python itself, do you? I've
>actually appreciated the argument from your second post, when you taxed
>the other guy for needlessly questioning your Python knowledge out of
>context.
It was not out of context.
Look at the Subject of this thread. . .
>I fail to see the interesting part in this whole thread, which disturbs
>the habitat of comp.lang.python. I think John Stevens was mistaken to
>bring the discussion over to this newsgroup in the first place.
I didn't bring it over. I followed it after somebody else started
it, and I only started posting when the FUD started getting thick.
>We don't
^^
Whose we?
>have strong feelings about Perl, and don't have plans for world
>domination or anything.
John S.
Gordon McMillan
[ crap deleted ]
Whatever your contributions to the python community, you're now in my
killfile, along with a handful of pl hotheads who do the same to us.
- Gordon
John Stevens
>John W. Stevens (jste...@basho.fc.hp.com) wrote:
>[quoting someone whose name was lost]
>: > It is wrong from the Larry's principle that things that behave
>: > differently should have different appearances.
>:
>: Then why doesn't Perl have two different operations for
>: assign/reassign, vs. add to an array? A tiny little violation of
>: Larry's principles, that.
>
>Nope. "Behave differently" hear means "accomplish two different tasks."
>Comparing two strings to see if they're equal lexically is not the same
>task as comparing two strings to see if they're equal numerically.
Right. Do you see what I am saying? Automatic coercion (from string to int)
created a problem. The problem was dealt with by making a change that
impacts the language.
As well as providing a huge opportunity for defects, the complexity
of the language was increased.
>Putting a particular value in a particular position in an array that
>already holds a value *is* the same task as putting a particular value in
>a particular position of an array that does not yet hold a value; the
>only difference is in the internal details of how to accomplish it.
Yes, but the context of this was TC's comparison with Python's lists.
For an ARRAY, your argument makes sense. For a list, it does not,
yet TC was taking Python lists to task for not acting like arrays.
On the other hand, Perl's behavior encourages defects:
$array[$index] = $newWord;
The program ran for a very long time, then the system started thrashing,
then it core dumped.
The value of $index? Very, very large. Perl happily tried to allocate
Gigabytes worth of core.
>Of course, the OOically-correct way to handle the string comparisons is
>to define a base class, ComparableString, and two subclasses,
>LexicallyComparableSting and NumericallyComparableString, along with
>polymorphic operators that understand which class they're comparing to
>and apply the correct comparison method. But there are cases where you
>may want to do *both* comparisons on a string,
I would disagree with the last part . . . it makes sense to encode
a number as an ASCII string, then to decode it back to an integer,
but to compare two strings as if they were numbers, again, allows
for far to many defects.
For example (another real bug, here):
$result = $Total / $count;
Generated a division error. $count contained the string: "Payroll". . .
>and to be OC you then have
>to cast the string to the appropriate type;
Cast?
>the Perlish way of picking
>the operator director is IMHO easier and more maintainable; in my
>experience, heavy casting makes code unreadable.
Casting is a poor idea, I agree. Explicit conversion, however, is
more maintainable and much easier to use in a way that reduces
defect rates.
John S.
Tom Christiansen
In comp.lang.python, gm...@hypernet.com writes:
That man, along with Ian Clarke, have stirred up the biggest flame war
in the Perl newsgroup that we're seen for a long time, inflicting their
standard overrighteous prattle on us. I realize that they aren't truly
representative of Python people in general: several others have been
entirely reasonable and educative. I'm not sure hoter users realize
this, however.
On that killfiling issue, I just hope you're still around when I have
Python questions. :-)
--tom
--
: The ksh scripts do not have a problem with it.
That's because ksh doesn't much mind opening up security holes. The
absence of taint checks is not exactly a feature.
Larry Wall in <1994Dec15.0...@netlabs.com>
John Stevens
>John, please refrain from cross-posting all your messages to
>comp.lang.python.
I didn't cross post. I responded to somebody who cross posted.
I never add or remove news groups from the list.
>The 'my language is better than yours' debates are always pointless
>and counterproductive,
Not always. Such a thread lead me to Python in the first place.
You may be cursing your unlucky stars that that occurred, but
such is life! :-)
>Incidentally you are wrong about perl arrays and python lists being
>different data structures - internally they are both implemented as C
>arrays, only the names are different.
Which is equivalent to saying that all languages are identical,
because they all end up being machine code, in the end.
Sorry, but that is an over simplification.
>All great ideas start as heresy and end as dogma.
Yes. The thought that it is actually possible to make objective
measurements and from those measurements determine that one programming
language really *IS* better than another language for a given set
of tasks or environments is, currently (Obviously! ;-> )
HERESY.
;_>
John S
Brad Howes
sho...@pgrad.cs.usyd.edu.au (Sam Holden) writes:
<snip>
> It's like someone who starts a C program with :
>
> #define BEGIN {
> #define END }
>
Hey! I actually worked on a project where someone did this! Also in their
funky include file was
#define AND &&
#define OR ||
It was the most bizarre thing I ever saw -- not so much the include file,
but the resulting code. As if a Pascal moths had come in, eaten at some
code and left little Wirth fragments sprinkled around. Has anyone else
encountered such strange programming behavior?
...now back to my language is bigger/longer/wider/stiffer than yours
--
Brad Howes br...@mediaone.net
Tom Christiansen
In comp.lang.perl.misc,
Brad Howes <br...@mediaone.net> writes:
: #define AND &&
: #define OR ||
[verba deleta]
:Has anyone else
:encountered such strange programming behavior?
Gosh yes. I think it was the rogue source that had something like:
#define until(expr) while(!expr)
#define otherwise break; default:
I don't remember whether it also had these, but I have
seen them elsewhere:
#define forever() for(;;)
#define unless(expr) if(!expr)
We had this extremely elusive (like, he never came in) hot-shot compiler
guy back on Convex who *insisted* upon using these in the compiler builds.
His ranking/stature was such that he got away with it, despite most of
our tormented cries.
--tom
--
/* Force them to make up their mind on "@foo". */
--Larry Wall, from toke.c in the v5.0 perl distribution
Sam Holden
>> >>Python. This is Officially Okay in Perl culture.
>> >
>> >You cannot write Perl that resemble Python. You are required to
>> >use curly braces as block delimiters.
>>
>> In fact you are not. You are wrong yet again. Actually thinking about how
>> perl works for a minute would show you that perl is in fact flexible.
>> it is not a lie when people say perl doesn't force you to write a
>> particular way.
<snip impythonate.pm by Damian Conway>
>> And here is his sample code that is now valid perl (although anyone who uses
>> it for real code should be killed) :
>Why? You don't happen to hate Pythoneers or Python itself, do you? I've
>actually appreciated the argument from your second post, when you taxed
>the other guy for needlessly questioning your Python knowledge out of
>context.
I know a fair few pythoners in fact, I even like some of them. What I meant
was that anyone who would do such a thing with perl deserves to be killed.
Since no one else will be able to maintain the program. It's like someone
who starts a C program with :
#define BEGIN {
#define END }
Doing things like this means that a C programmer can't understand the code,
and a Pascal programmer can't either. With impythonate.pm, a perl
programmer can't understand the code, and a python programmer can't either.
Also don't tell anyone but I actually like python a lot. I don't use it much
since I have more experience with perl, and more importantly I know the
modules available for perl better, and can quickly search for one to
do whatever I need next.
>I am completely ignorant with Perl and I can barely read what's above
>(by interpolating my knowledge of shell, C, and Tcl).
That's because it uses a lot of the not so well known perl features.
>
>>
>> #Now newlines replace colons and indentation replaces brackets:
>>
>> use impythonate; # STILL NEED THAT ONE SEMICOLON, DAMMIT!
>>
>> for $i (1..10) # COMMENTS ARE OKAY
>> print "$i: "
>> my $isq = \
>> $i **2 # LINE CONTINUATIONS WORK AS IN PYTHON
>> print " $isq\n"
>>
>> print "done\n"
>I know Python fairly well (but I'm no expert) and I can easily read this
>piece of Perl.
But it would be no harder to read with ; on the end of each statement and
a pair of {}s.
Working out that strings interpolate should be a bigger leap than working
out that blocks have {}s around them.
> Getting back to the killing part, which kind of disturbs
>me when reading comp.lang.python:
>- was that necessary to make a point?
>- if yes, what was the point?
>- if the point (just guessing) was that Perl code should never look like
>Python, isn't that against of 'there should be more ways of doing it?'
I answered this above a little.
It was necessary since I don't want someone actually using such an untested
module in their code. Chances are it breaks on many python constructs. The
obvious example is :
if (1==1) : print "fred"
It won't handle that.
Everyone seems to misunderstand the whole concept of TMTOWTDI. It doesn't
mean all ways are equal. That is a way of writing perl which works, it is
however not very maintanable. The only way to determine what syntax is
valid is to know perl's syntax, and to be able to read and understand the
impythonate.pm code - since there is no documentation and it is _not_ the
same as python.
Writing it in 'normal' perl reduces the requirements to understanding, and
speeds it up to boot.
>I fail to see the interesting part in this whole thread, which disturbs
>the habitat of comp.lang.python. I think John Stevens was mistaken to
>bring the discussion over to this newsgroup in the first place. We don't
>have strong feelings about Perl, and don't have plans for world
>domination or anything.
>
>A couple of days ago I read a bit in Bugzilla's README which amused me:
>"A computer which doesn't have Perl installed is a very sad computer
>indeed". Your post is frightening (unless it was a Perl-style joke).
How was it frightening?
If you want to program in python, then use python. It's a nice language,
it is portable, it is simple to install, it is easy to learn.
So what is the point of munging another language to look like it? If you could
munge perl so that you could name the capturing elements of a regex then that
would be a useful, python like addition...
--
Sam
There's no such thing as a simple cache bug.
--Rob Pike
Sam Holden
John Stevens <jste...@bamboo.verinet.com> wrote:
>On Sat, 14 Aug 1999 12:06:11 +0100, Alex Maranda <amar...@nospam.com> wrote:
>>Sam Holden wrote:
>>Why? You don't happen to hate Pythoneers or Python itself, do you? I've
>>actually appreciated the argument from your second post, when you taxed
>>the other guy for needlessly questioning your Python knowledge out of
>>context.
>
>
>Look at the Subject of this thread. . .
Read the content of my post, and learn how usenet wanders... I wasn't
arguing about the relative merits of perl and python. I don't care, I
use both, hang I've used them both in the same system.
--
Sam
compiling kernels is what I do most, so they do tend to stick to the
cache ;) --Linus Torvalds
Sam Holden
John Stevens <jste...@bamboo.verinet.com> wrote:
>On 14 Aug 1999 03:36:23 GMT, Sam Holden <sho...@pgrad.cs.usyd.edu.au> wrote:
>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.
>
>>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.
>
>>No. Is there a list
>>in that line of code?
>
>No, it's a tuple, not a list.
You can play semantic games all you like, here's the only definition of
a tuple that I could find :
tuple :
In functional languages, a data object containing two or more
components. Also known as a product type or pair, triple, quad, etc.
Tuples of different sizes have different types, in contrast to lists
where the type is independent of the length. The components of a tuple
may be of different types whereas all elements of a list have the same
type. Examples of tuples in Haskell notation are (1,2), ("Tuple",True),
(w,(x,y),z). The degenerate tuple with zero components, written (), is
known as the unit type since it has only one possible value which is
also written ().
Sorry perl's lists are not tuples. Since they can only store values of
one type - scalars. You can't have a list of lists (sorry tuple of tuples),
only a list of scalar refernces to a lists (sorry tuple of scalar references
to tuples).
Perl uses the word list. The word list has many more meanings in the English
language than the Mathematics definition I'm sorry. Perl uses a different
meaning than you like, go and take it up with whoever publishes your
dictionary.
>Go ahead, show me a variable that contains a list. In your
>example:
Did you read my post. Particularly the bit in which I said you can't have
a list in a a variable. Anyway I give up - learn how to read, and accept
that perl uses the work list differently than python.
>
>$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?
Strangely enough perl didn't involve in an ivory tower. It isn't meant to
be a 'pure' language, it doesn't have lots of 'theory' behind it. Here's a good
definition of a list that the paper boy will tell you is a list :
list n 1: a database containing an ordered array of items (names or
topics) [syn: listing] 2: the property possessed by a line or surface
that departs from the vertical; "the tower had a pronounced tilt";
"the ship developed a list to starboard"; "he walked with a heavy
inclination to the right" [syn: tilt, inclination, lean, leaning] v
1: give or make a list of; name individually; give the names of 2:
include in a list 3: give the names of; "Name the states west of the
Mississippi!" [syn: name] 4: enumerate; "We must number the names of the
great mathematicians" [syn: number]
no mention of operations there. When I ask for a list of birthdays, I don't
want something I can insert into, or delete from. I want a bunch of dates
written on a peice of paper. Feel free to ask for a tuple of birthdays, I'll
stick you common English though thanks.
>
>You don't. You copy the contents of your tuple into an array,
>then perform array operations on that array.
>
>>>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.
And if you read my post you would have realised I avoided comparing perl
and python in any way.
>
>>What was the point of saying I need to learn Python?
>
>Because, in the words of TC, "Learning is a good thing".
>
>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.
I agree with you. An earlier post by TomC specifically said that. Perl
calls them lists, thus they are lists. If Perl called them Hamburgers then
they would be hamburgers. Of course that would make perl harder to talk
about and to understand from the documentation.
Show a bunch of people the following (try paper boys, programmers,
mathematicians, etc) :
1,2,3,4,5,6,7,8,9
Ask them what it is.
I bet more people say a 'list' than say a tuple.
Perl didn't come from an ivory tower, it uses English words for their
English meanings a lot. You don't like that, fine, just don't argue perl
doesn't have lists when you know it does.
If you had said "perl doesn't have lists, what it calls lists are really
tuples', I would have answered with aomething like the above. I misunderstood
and thought that you thought arrays and lists where exactly equivalent in perl.
That is a common mistake in perl, that people who make the mistakes that you
have made with perl code in this thread make. People who struggle with
using @ where they mean $ and {} where they mean (), etc tend to be
misunderstanding the basic data structures perl provides.
I made a mistake, I can admit that.
I do have a feeling that you knew I was and kept going anyway because you
like to argue about stupid pointless things.
>
>>You might as well have told me to learn C or Lisp.
>
>Yes. You should. Had you learned Lisp, list processing would
>be second nature to you, and you would have a clearer idea between
>"lists" and "tuples" and "arrays".
In fact I have. But the meaning of 'list' when talking about perl is whatever
perl calls a list. Ignore it all you want. You must get misunderstood a lot.
>
>Stop. You are talking about arrays, not lists. I repeat, if
>@ary were a list, the above operation would be illegal.
But @ denotes an array and you know this.
>
>>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.
That's fine, your allowed to disagree with the terminology. but since you
in all likelyhood knew what I meant anyway you have just been playing games.
*plonk*
--
Sam
I explicitly give people the freedom not to use Perl, just as God gives
people the freedom to go to the devil if they so choose.
--Larry Wall
Ben Caradoc-Davies
The most confidence uninspiring piece of code I ever had the displeasure to
maintain contained something like this (allegedly C++, but mainly it's
intersection with C):
i = 0;
while( i < max_index ) {
/* some copying or update (not modifying i) goes here */
i = i + 1;
}
This was written by a *very* expensive consultant working for a large
multinational accountancy firm.
Can anybody suggest an alternative construct which more accurately expresses
the programmer's intentions? There may be more than one way to do it, but,
puhleeze!
Idiomatic is not quite the word.
--
Ben Caradoc-Davies <bm...@es.co.nz>
Anno Siegel
>I don't remember whether it also had these, but I have
>seen them elsewhere:
>
> #define forever() for(;;)
> #define unless(expr) if(!expr)
Let's just hope they had the sense to really
#define unless(expr) if(!(expr))
or else all bets are off.
Anno
Paul Jackson
Steve Bourne, who wrote the Bourne shell (and the
debugger, adb) was notorious for encoding the
entire source in some Algol-like control structures,
using #define's. It inspired many a coding-standard
proclamation, for years after inside Bell Labs, that
one shall not use #define's to redefine syntax.
[I always figured that he had to write adb, because
he needed it to debug the tortured code in his shell.]
--
=======================================================================
I won't rest till it's the best ... Software Production Engineer
Paul Jackson (p...@sgi.com; p...@usa.net) 3x1373 http://sam.engr.sgi.com/pj
Matt Sisk
> > 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)
Matt Sisk
> 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
Abigail
MCMXCIII in <URL:news:slrn7r9nde....@bamboo.verinet.com>:
%% On 14 Aug 1999 02:32:12 GMT, Sam Holden <sho...@pgrad.cs.usyd.edu.au> wrote:
%% >On 13 Aug 1999 20:04:03 -0700, John W. Stevens <jste...@basho.fc.hp.com> wrote:
%% >>> In comp.lang.perl.misc,
%% >>> "John W. Stevens" <jste...@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 ==-----
Abigail
() On 14 Aug 1999 03:36:23 GMT, Sam Holden <sho...@pgrad.cs.usyd.edu.au> wrote:
() >On Sat, 14 Aug 1999 03:08:33 GMT,
() > John Stevens <jste...@bamboo.verinet.com> wrote:
() >>On 14 Aug 1999 02:32:12 GMT, Sam Holden <sho...@pgrad.cs.usyd.edu.au> wrote:
() >>>On 13 Aug 1999 20:04:03 -0700,
() > John W. Stevens <jste...@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=>()'
Abigail
$$ On 14 Aug 1999 04:08:05 GMT, Sam Holden <sho...@pgrad.cs.usyd.edu.au> wrote:
$$ >That could simply have been a reference. Or a symbolic reference.
$$ >
$$ >What is fundamental is that a @ tacked on the front indicates that it is an
$$ >array.
$$
$$ What is so amusing about that, is that you can say that with a straight
$$ face!
It's nice to see you have fun about nothing.
$$ >So given @$fred, even with no knowledge of what that exactly means
$$ >you should be able to tell that it is somehow treating $fred as an array.
$$
$$ No, what any reasonable person would do would be to grab for his
$$ Perl book. . .
Perhaps the first and the second time he encounters it. If he needs it
a third time, he sucks as a programmer. How often have you looked this
up? Just what I said.
$$ >>Yes. . . is it a hash, or a scalar? If it is a scalar, why
$$ >>is it called dict? If it is a hash, then why is it prefixed
$$ >>by $? If this is a reference instead of a scalar, then why
$$ >>doesn't it have it's own special prefix character. ;->
$$ >
$$ >It's a scalar. It is named dict because TomC called it that.
$$
$$ Yes. My point exactly.
$$
$$ >It is
$$ >also named that since it is a reference to a hash. I use code like this
$$ >in C quite a bit :
$$
$$ A reference to a hash. . . and yet TC claims that Perl is open to
$$ non-computer scientists.
Yep. Only computer scientists use pronouns. It's too difficult for the
rest of the people. Pronouns were invented by Turing, in the early 50s.
$$ Doesn't *ANYBODY* else see the irony in that?
No. What's the reference phobia? Does it give you spots?
$$ >If you know what it means then why do you continually get it wrong
$$ >throughout this thread?
$$
$$ I don't suppose that you realize that getting wrong simply
$$ proves (and illustrates) my point?
$$
$$ I learned it. I used it. I haven't written a new Perl program
$$ in three months.
$$
$$ I come back to it, I get it wrong. . . do you see, yet,
Yes, we see. You suck as a programmer.
$$ >Here is some code from Damian Conway from the 'Impythonating PERL' thread
$$ >in march.
$$ >
$$ >package impythonate;
$$ >use Text::Tabs;
$$ >my ($active, @bracket) = (0, ('{', ';', '}') );
$$ >sub import
$$ >{
$$ ^ Look closely. . . see that curly brace?
$$
$$ >And here is his sample code that is now valid perl (although anyone who uses
$$ >it for real code should be killed) :
$$
$$ To late. You already used a curly brace. Disproving your point,
$$ in case you hadn't realized it.
It looks like you have a problem following a linear argument.
Abigail
--
sub f{sprintf$_[0],$_[1],$_[2]}print f('%c%s',74,f('%c%s',117,f('%c%s',115,f(
'%c%s',116,f('%c%s',32,f('%c%s',97,f('%c%s',0x6e,f('%c%s',111,f('%c%s',116,f(
'%c%s',104,f('%c%s',0x65,f('%c%s',114,f('%c%s',32,f('%c%s',80,f('%c%s',101,f(
'%c%s',114,f('%c%s',0x6c,f('%c%s',32,f('%c%s',0x48,f('%c%s',97,f('%c%s',99,f(
'%c%s',107,f('%c%s',101,f('%c%s',114,f('%c%s',10,)))))))))))))))))))))))))
Abigail
__ In comp.lang.perl.misc, you wrote:
Who is "you"?
__
__ >A CGI monstrosity from a
__ >script kiddie isn't, but this is irrelevant.
__
__ Actually, they are *VERY* relevant! Those CGI monstrosities are
__ Perl, they go into the statistics, and somebody somewhere has to
__ maintain them, and somebody has to pay to get them maintained.
So, the best language would be one noone uses? So, it can't be misused
and held against you?
Brilliant idea. Very useful as well.
Abigail
--
split // => '"';
${"@_"} = "/"; split // => eval join "+" => 1 .. 7;
*{"@_"} = sub {foreach (sort keys %_) {print "$_ $_{$_} "}};
%{"@_"} = %_ = (Just => another => Perl => Hacker); &{%{%_}};
Chad Netzer
> That man, along with Ian Clarke, have stirred up the biggest flame war
> in the Perl newsgroup that we're seen for a long time, inflicting their
> standard overrighteous prattle on us.
As one who put a flaming bag-o-turd on Tom's home doorstep (c.l.p.m,
that is), when I should not have contributed to such a bonfire of abuse
(although that "if 1:" trick can be useful :), I'd like to say that it is a
shame
this had to start so near to the O'Reilly conference. I won't be able to make
it, but I hope others will not let this interfere with any potential
discussion
and socializing between the two "camps".
Anyone who buys Tom a beer for me (or an equivalent, depending on his
tastes), I'll pay them back.
Chad
Uhhh, but don't everyone do it, or I'll go broke. :)
Abigail
%% On 14 Aug 1999 02:55:19 GMT, Eric Bohlman <eboh...@netcom.com> wrote:
%% >John W. Stevens (jste...@basho.fc.hp.com) wrote:
%% >[quoting someone whose name was lost]
%% >: > It is wrong from the Larry's principle that things that behave
%% >: > differently should have different appearances.
%% >:
%% >: Then why doesn't Perl have two different operations for
%% >: assign/reassign, vs. add to an array? A tiny little violation of
%% >: Larry's principles, that.
%% >
%% >Nope. "Behave differently" hear means "accomplish two different tasks."
%% >Comparing two strings to see if they're equal lexically is not the same
%% >task as comparing two strings to see if they're equal numerically.
%%
%% Right. Do you see what I am saying? Automatic coercion (from string to int)
%% created a problem. The problem was dealt with by making a change that
%% impacts the language.
What's next, different types for prime numbers and non-prime numbers?
%% As well as providing a huge opportunity for defects, the complexity
%% of the language was increased.
Look. All we've seen from you here is a 4 line Python program,
riddled with bugs. And your Perl knowledge is at the same level as my
hair dressers. All that proves is that you are in desparate need of
something that protects you from making mistakes, and that Python isn't
giving you that.
%% >Putting a particular value in a particular position in an array that
%% >already holds a value *is* the same task as putting a particular value in
%% >a particular position of an array that does not yet hold a value; the
%% >only difference is in the internal details of how to accomplish it.
%%
%% Yes, but the context of this was TC's comparison with Python's lists.
%%
%% For an ARRAY, your argument makes sense. For a list, it does not,
%% yet TC was taking Python lists to task for not acting like arrays.
%%
%% On the other hand, Perl's behavior encourages defects:
%%
%% $array[$index] = $newWord;
%%
%% The program ran for a very long time, then the system started thrashing,
%% then it core dumped.
%%
%% The value of $index? Very, very large. Perl happily tried to allocate
%% Gigabytes worth of core.
Well, then don't do that then. Djees. Consider a Python equivalent:
while len (array) <= index + 1: # Why isn't that array.len() ???
array.append (0)
array [index] = newWord;
Would that somehow magically have prevented index not to be large?
%% For example (another real bug, here):
%%
%% $result = $Total / $count;
%%
%% Generated a division error. $count contained the string: "Payroll". . .
And in Python it would produce some result?
Abigail
--
perl -MLWP::UserAgent -MHTML::TreeBuilder -MHTML::FormatText -wle'print +(
HTML::FormatText -> new -> format (HTML::TreeBuilder -> new -> parse (
LWP::UserAgent -> new -> request (HTTP::Request -> new ("GET",
"http://work.ucsd.edu:5141/cgi-bin/http_webster?isindex=perl")) -> content))
=~ /(.*\))[-\s]+Addition/s) [0]'
Abigail
MCMXCIII in <URL:news:37b4...@cs.colorado.edu>:
''
'' But if you do like OO, don't Perl.
I actually agree with that. But then, for the same reason, I wouldn't
use Python either. You see, Perl's OO model was taken from Python.
I don't like Perl's OO model, because 1) it doesn't give me what I want
from an OO model and 2) it doesn't give me what the rest of Perl does.
It's very unlikely I would turn to Python for its OO.
Abigail
--
sub camel (^#87=i@J&&&#]u'^^s]#'#={123{#}7890t[0.9]9@+*`"'***}A&&&}n2o}00}t324i;
h[{e **###{r{+P={**{e^^^#'#i@{r'^=^{l+{#}H***i[0.9]&@a5`"':&^;&^,*&^$43##@@####;
c}^^^&&&k}&&&}#=e*****[]}'r####'`=437*{#};::'1[0.9]2@43`"'*#==[[.{{],,,1278@#@);
print+((($llama=prototype'camel')=~y|+{#}$=^*&[0-9]i@:;`"',.| |d)&&$llama."\n");
Abigail
<URL:news:wjy7lmxbw...@bradh.ne.mediaone.net>:
&&
&& Hey! I actually worked on a project where someone did this! Also in their
&& funky include file was
&&
&& #define AND &&
&& #define OR ||
&&
&& It was the most bizarre thing I ever saw -- not so much the include file,
&& but the resulting code. As if a Pascal moths had come in, eaten at some
&& code and left little Wirth fragments sprinkled around. Has anyone else
&& encountered such strange programming behavior?
Well, uhm, yeah. I once wrote a C program implementing red-black trees
that almost read like English. Except for parens and the one #include
line, no punctuation chars where needed. It had things like:
if (I am red and my uncle is black)
we do ....
Unfortunally, that code didn't survive an extreme quota regime.
Abigail
--
perl -MNet::Dict -we '(Net::Dict -> new (server => "dict.org")
-> define ("foldoc", "perl")) [0] -> print'
Michael P. Reilly
: [courtesy cc of this posting mailed to cited author]
: In comp.lang.python, gm...@hypernet.com writes:
: :John W. Stevens wrote:
: :[ crap deleted ]
: :
: :Whatever your contributions to the python community, you're now in my
: :killfile, along with a handful of pl hotheads who do the same to us.
: That man, along with Ian Clarke, have stirred up the biggest flame war
: in the Perl newsgroup that we're seen for a long time, inflicting their
: standard overrighteous prattle on us. I realize that they aren't truly
: representative of Python people in general: several others have been
: entirely reasonable and educative. I'm not sure hoter users realize
: this, however.
There was an attempt on c.l.p to divert the issue from c.l.p.m; much to
our collective regret, it didn't work (obviously).
-Arcege
Matthew O. Persico
Try idiotic!
> --
> Ben Caradoc-Davies <bm...@es.co.nz>
--
Matthew O. Persico
You'll have to pry my Emacs from my cold dead oversized
control-pressing left pinky finger. -- Randal L. Schwartz
Matthew O. Persico
This happened one week before my honeymoon. How major? Well it wrote and
sent settlement information for about 10-20% of the daily volume of equity
transactions in the entire United States.
Anyway, it took about six months of re-programming to evolve this morASS
(emphaisis mine) of code into something that behaved in a deterministic
fashion. As I hacked way at the underbrush, I kept coming upon all sorts of
references to a function called ocrap(). Eventually, I found the source
for the function (instead of just linking in the existing library) and
discovered it went something like this:
int ocrap(char *s) {
printf("Oh crap, what am I doing here: %s\n",s);
exit (5);
}
--
Kaz Kylheku
>[strange programming]
>The most confidence uninspiring piece of code I ever had the displeasure to
>maintain contained something like this (allegedly C++, but mainly it's
>intersection with C):
>
> i = 0;
> while( i < max_index ) {
> /* some copying or update (not modifying i) goes here */
> i = i + 1;
> }
>
>This was written by a *very* expensive consultant working for a large
>multinational accountancy firm.
So what's wrong with that? Granted, the for loop construct would have
been better for the task instead of while, and the expensive consultant should
have seen that. But what about the i = i + 1 increment? It smacks of BASIC, but
there is nothing wrong with it. It's not any less efficient than i++ or ++i.
Maybe the consultant is anally retentive about not using operators other than
assignment that have the side effect of modifying an object, and not using more
than one side effect in a full expression. That approach leads to uninsipiring
code, but nevertheless code that won't possibly have undefined behaviors due to
ambiguities.
In other words, with his ultra-conservative approach, the weenie is unlikely
to ever things like a[i] = i++.
I'm afraid you don't have a case, if the program otherwise fulfilled its
functional, performance and reliability requirements.
The guy programs for accounting firms. So it's a given that he can't possibly
be a great hacker who writes slick code. He does things that some of us
wouldn't touch with a ten foot pole. His high cost could have something to do
with his domain specialization, and with a high profit margin on the part of
the contracting company (assuming he's not freelance).
James Logajan
>
> On 15 Aug 1999 03:14:48 GMT, Ben Caradoc-Davies <bm...@es.co.nz> wrote:
> >[strange programming]
> >The most confidence uninspiring piece of code I ever had the displeasure to
> >maintain contained something like this (allegedly C++, but mainly it's
> >intersection with C):
> >
> > i = 0;
> > while( i < max_index ) {
> > /* some copying or update (not modifying i) goes here */
> > i = i + 1;
> > }
> >
> >This was written by a *very* expensive consultant working for a large
> >multinational accountancy firm.
>
> So what's wrong with that?
Those that think that code is bad have I suspect have never seen bad code.
Anyway, I bet many people missed the really bad part in that code, which is
the placement of the { <Wink>. Note the only approved location for curly
brackets:
i = 0;
while(i < max_index)
{
/* Blah blah. */
i = i + 1;
}
(I use Python whenever I can just to get away from these curly bracket wars.
<0.7 wink>)
Abigail
in <URL:news:slrn7re80...@ashi.FootPrints.net>:
## On 15 Aug 1999 03:14:48 GMT, Ben Caradoc-Davies <bm...@es.co.nz> wrote:
## >[strange programming]
## >The most confidence uninspiring piece of code I ever had the displeasure to
## >maintain contained something like this (allegedly C++, but mainly it's
## >intersection with C):
## >
## > i = 0;
## > while( i < max_index ) {
## > /* some copying or update (not modifying i) goes here */
## > i = i + 1;
## > }
## >
## >This was written by a *very* expensive consultant working for a large
## >multinational accountancy firm.
##
## So what's wrong with that? Granted, the for loop construct would have
## been better for the task instead of while, and the expensive consultant shoul
## have seen that. But what about the i = i + 1 increment? It smacks of BASIC, b
## there is nothing wrong with it. It's not any less efficient than i++ or ++i.
I would still argue we don't know enough about the program to say it's
wrong or bad style. The last line is easily modified to "i = i + 2", or
"i = i * 1.5", or "i = i + a", where a is depending on the rest of the
statements in the block. I would prefer using "i = i + 1" or "i += 1"
if I mean "I add a number to i, which happens to be 1 in this case" over
"i ++", which in my book means, "I am counting" or "it's the next one".
I don't think using 'for (i = 0; i < max_index; i = i + 1) {}' is going
to buy me anything over the while. Except that's less flexible. Thinking
about the next programmer? Gimme a break. A programmer that gets confused
when seeing a while that could be written as a for shouldn't touch the
code anyway.
It's the same with !i and i == 0. With !i, i is acting as a boolean, while
in "i == 0", I am comparing i to a specific value. That the value just
happens to be 0 doesn't warrent a change in syntax.
Abigail
--
$" = "/"; split $, => eval join "+" => 1 .. 7;
*{"@_"} = sub {foreach (sort keys %_) {print "$_ $_{$_} "}};
%{"@_"} = %_ = (Just => another => Perl => Hacker); &{%{%_}};
Aahz Maruch
Kaz Kylheku <k...@ashi.FootPrints.net> wrote:
>On 15 Aug 1999 03:14:48 GMT, Ben Caradoc-Davies <bm...@es.co.nz> wrote:
>>
>>The most confidence uninspiring piece of code I ever had the displeasure to
>>
>> i = 0;
>> while( i < max_index ) {
>> }
>>
>
>So what's wrong with that? Granted, the for loop construct would have
>smacks of BASIC, but there is nothing wrong with it. It's not any less
>efficient than i++ or ++i.
Not only that, but perhaps that was the third or fourth draft of the
code, and a while loop was more appropriate for the original draft.
It's often the case that even when I know there's a more "appropriate"
structure for code that I'm modifying, I leave the old code intact as
long as there's nothing actually *wrong* with it -- fewer changes
equates to fewer bugs (not always, but in general).
--
--- Aahz (@netcom.com)
Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6 (if you want to know, do some research)
Ben Caradoc-Davies
[reinventing "for"]
>So what's wrong with that? Granted, the for loop construct would have
>been better for the task instead of while, and the expensive consultant should
>have seen that. But what about the i = i + 1 increment? It smacks of BASIC, but
>there is nothing wrong with it. It's not any less efficient than i++ or ++i.
The question is not one of efficiency but one of expressing the intent of the
programmer. Seeing this written as a while loop made me double take ...
where's the trick? What is going on here?
There is nothing wrong with i = i + 1 (especially for us Pythonistas :-), but
taken together with the loop it suggests an unfamiliarity with the accepted
idioms of the language.
>Maybe the consultant is anally retentive about not using operators other than
>assignment that have the side effect of modifying an object, and not using more
>than one side effect in a full expression. That approach leads to uninsipiring
>code, but nevertheless code that won't possibly have undefined behaviors due to
>ambiguities.
>In other words, with his ultra-conservative approach, the weenie is unlikely
>to ever things like a[i] = i++.
I wish this were the case, but given the rest of the code, I doubt it. You are
however, most charitable and tolerant :-)
>I'm afraid you don't have a case, if the program otherwise fulfilled its
>functional, performance and reliability requirements.
[Warning: may contain traces of rants]
The program did have some annoying bugs, and it was in the hunt for these that
the, er, unusual code was found. However, the program did mostly fulfil its
functional, performance, and reliability requirements, as they existed at the
time. And here's the rub:
A program must fulfil more than just those requirements, but also that of
maintainability. I'm sure I don't have to remind anyone here that a piece of
source code is a living document, and should be amenable to change (which is
why I was working on it in the first place).
The real problem I had with the project in question was that (except for some
crucial headers), the entire source code was almost uncommented except for a
copyright notice at the top of each source file. Understanding the code was an
exercise in reverse-engineering the intent of the programmer. I've seen this in
scientific software (such as the 49000 LOC of uncommented Fortran 77 written by
an engineer with english as a second language, with no use of procedures and
the entire flow-control managed by circuitous GOTOs and global variables), but
in a business environment it is unforgiveable.
When I left, I passed the [C++] project on to my successor, who was quite a
greenhorn. Meanwhile, the original author had fled the country. Now the current
project manager ("ANSI C? No I haven't heard of that company.") is leaving too.
The only record of what the code is meant to do is some outdated manuals and
the source code. This is mission-critical business software.
>The guy programs for accounting firms. So it's a given that he can't possibly
>be a great hacker who writes slick code. He does things that some of us
>wouldn't touch with a ten foot pole. His high cost could have something to do
>with his domain specialization, and with a high profit margin on the part of
>the contracting company (assuming he's not freelance).
I'm sure he would have only seen a tiny slice of what the multinational charged
for his time. However, I think his price was due more to the gullibility of the
client and wandering project control than the domain. This is a bog-standard
database front-end!
Phew!
--
Ben Caradoc-Davies <bm...@es.co.nz>
Ben Caradoc-Davies
>Not only that, but perhaps that was the third or fourth draft of the
>code, and a while loop was more appropriate for the original draft.
>It's often the case that even when I know there's a more "appropriate"
>structure for code that I'm modifying, I leave the old code intact as
>long as there's nothing actually *wrong* with it -- fewer changes
>equates to fewer bugs (not always, but in general).
Sure, if it ain't broke ...
Unfortunately, in this case, the original specifications appear to have been
reduced, and there are huge chunks of partly implemented and even obsolete
code, including a large source source file which should have been entirely
deleted as it's functionality had been absorbed into another. This was only
deducible by examiing the linker options.
If there was any evidence of a drafting process, it wasn't obvious.
But yes, there may well have been something more complicated in the loop. For
example, if he was messing with "i" in the loop, a while loop would have been
a good way to draw another programmer's attention to the fact that something
fishy was going on, if he was so averse to comments.
--
Ben Caradoc-Davies <bm...@es.co.nz>
TRG Software: Tim Greer
>
> On 14 Aug 1999 04:08:05 GMT, Sam Holden <sho...@pgrad.cs.usyd.edu.au> wrote:
> >That could simply have been a reference. Or a symbolic reference.
> >
>
> :-)
>
> What is so amusing about that, is that you can say that with a straight
>
> :-)
>
> >So given @$fred, even with no knowledge of what that exactly means
>
Until they learn the language enough to know these things. If you judge
a language based only on what you remember in the smallest amount of
learning time you've spent, then you're limiting yourself in too many
ways to bother mentioning. Some people have a better comprehension for
certain languages over others. It's really that simple. Some people are
scared off, or disillusioned too quickly. Simply put, they haven't spent
the proper amount of time (some languages do take longer to learn well
enough to not have to use reference material every few minutes), or they
weren't taught properly, or it's just something that they have less of a
comprehension for, or perhaps a lack of desire to really get so involved
when they could be using other languages. Sometimes that limits you and
your ability. You only limit yourself at that point, because you could
be writing better programs in a language that's probably better suited
for the task, a language that confuses you, because you don't understand
it as quickly as another. That's fine, and for some people, it's not
worth the time invested to pout so much time into learning for more
reasons that are equally as pointless to mention. Some people think
learning Assembly is a complete waste of time.. Why learn it when you
already know enough C? Right? Wrong. If you have time and reason or
desire, learn it. Even if you'll never use it, I'd suggest you learn it.
It might not be easy, but in most circumstances, you'll probably end up
writing better C programs... You'd have to learn Assembly to know what
I'm talking about... The only real drawback, is the fact that you'll
cringe when you realize what the C compiler is doing to your code. You
can't know this, because you either don't know the language, or know it
well enough to state such things. Sure, you find it more confusing then
Python, that's fine, that's you. However, in that case, you shouldn't
make statements that make you look foolish here, in a Perl NG, simply
based on the facts that you can't deal with the curly braces and such,
or the fact that _you_ personally can't remember some of the syntax and
whatnot. That's ridiculous and that's why this completely pointless
thread has continued for so long.
> >>Yes. . . is it a hash, or a scalar? If it is a scalar, why
> >>is it called dict? If it is a hash, then why is it prefixed
> >>by $? If this is a reference instead of a scalar, then why
> >>doesn't it have it's own special prefix character. ;->
> >
> >It's a scalar. It is named dict because TomC called it that.
>
> Yes. My point exactly.
Yes, well, tell me, _what_ is it to be called? You should know how much
Tom is involved in Perl and how much he contributes. It's not a bad idea
or a wrong idea to call it something _you_ personally don't agree with.
You are complaining about "lists" in Perl? It's what it's called in
_this_ language, _this_ is _not_ Python. Do you just use this as an
example, based on the fact that it's not what you're _used to seeing_?
Or what you think it would be better called? This is a pretty high-level
language, and you are sort of contradicting yourself by saying how
difficult the syntax is to remember for _you_ (however that's relevant
to the rest of the world?), yet you think it should be called a more
technical term that _most_ people wouldn't understand? Isn't that at
least _part_ of your point?
> >It is
> >also named that since it is a reference to a hash. I use code like this
> >in C quite a bit :
>
> A reference to a hash. . . and yet TC claims that Perl is open to
> non-computer scientists.
>
> :-)
>
> Doesn't *ANYBODY* else see the irony in that?
How about the fact that you appear you be your own walking
contradiction? I believe that point is and was correct, and is to the
fact that; In Perl, people with no background in CS can learn enough,
right off, within a very short time, to be able to write some programs
that will accomplish some basic to intermediate tasks. That's not to say
that they will be able to know the more complex aspects of the language
with as much ease, and that goes without saying for _any_ language. Why
disagree with that?
> >If you know what it means then why do you continually get it wrong
> >throughout this thread?
>
> I don't suppose that you realize that getting wrong simply
> proves (and illustrates) my point?
About you and your statements, yes. You aren't everyone, or the
majority. If enough people asked that some of the keywords and
definitions be changed and there was a real need for it, I'm sure it
would happen... I don't see that happening, because there's no reason,
because _most_ people here seem to understand it and remember the syntax
well enough to where they don't suffer from the same problem as you.
> I learned it. I used it. I haven't written a new Perl program
> in three months.
>
> I come back to it, I get it wrong. . . do you see, yet,
> or do you just not get it?
I think the point is, is that you simply don't "get" Perl. You "get"
Python better, it's more comprehensible to you, and that's fine. Some
people find the opposite true. I myself, as both a Perl and Python
programmer (among other languages) look for and find the similarities.
There are more then a few if you really look at it. What's better for
what you're doing, is the question? What language do you find easier to
use personally? Why say one language is flawed over another based on
your own experience. Who did you learn from? Where did you learn from?
How much time did you spend? What, if any, do you have in prior
CS/programming backgrounds? Are you willing to dismiss some or many of
the things you were taught when you learned the prior, or do you feel
it's a better language based on the fact that you find it's closer to,
or easier to understand right off in comparison to the prior knowledge
you posses? Who are you to say?
<SNIP>
This is really stupid. Have you read any, many, or all of Tom's books
he's authored or co-authored? The man is not stupid and he knows what
he's talking about, which you have to admit is true when it comes to
Perl at least. Isn't it expected that he'll make points in defense of
Perl? You obviously don't like Perl as much as Python, and no one's
saying there's anything wrong with that.. The only flaw with your logic
in your posts, is the fact that it seems that you're speaking for others
and basing a lot of it on the fact, as you claim, that you yourself
personally find remembering the syntax difficult. Ok, so? That's you, I
can't think of anyone else that used Perl that has that problem, but I'm
sure more then a few do, just as with any other language. Why use Perl
when you've got Python? I don't know, maybe you'll enjoy Perl more, use
it more, or find it better suited for you or your task? Maybe your
particular program will run faster/better in perl rather then Python?
Maybe you can market it with more ease? Maybe something else? maybe your
program (for you, from you coding it) will run better coded in Python?
There's no point to this at all! If you want to compare it in that
manner, then tell me, _why_ bother with Perl OR Python, when you can use
C? Further, _why_ use C, when you can code it in Assembly? After all,
it's faster, you can make it do anything you want,
as-long-as-you-know-how. Just because you don't "know how", doesn't mean
it lacks something the language you _can_ code in better.
There was really no point to any of this. Making claims one way of the
other, about what you "believe" would be better named or worded does
little to no good. Note that my post in reply to you is/was completely
relevant and on-topic in regards to your post and this entire issue...
Note also, that I didn't have to use on piece of code to make this
point... after all, this is, to you as you've made it clear, to prove
your point, or disprove it. I'm just wondering _what_ your "point" was
supposed to be when it all comes down to it? I have been following the
thread, and I have yet to see a real point made.
--
Regards,
Tim Greer : webm...@chatbase.com | soft...@linkworm.com
The ChatBase: http://www.chatbase.com | 250,000+ hits daily Worldwide!
TRG Software: http://www.linkworm.com | CGI scripts in Perl/C, & more.
Unix/NT/Novell Administration, Security, Web Design, ASP, SQL, & more.
Freelance Programming & Consulting, Musician, Martial Arts, +Sciences.
TRG Software: Tim Greer
>
> > In comp.lang.perl.misc,> > :With PCRE, I prefer Python. I am slowly giving up Perl altogether,
> > :except as a training language in OO classes. Not to surprisingly,
> > :Python is preferred more than 7 to 1 over Perl by students who are
> > :exposed to both at the same time.
> >
> > I'm sure I am perfectly capable of presenting both Perl and Python
> > in such a way that the students would prefer Perl by 7 to 1 as well.
>
> Except that in your case, it would a concious attempt to influence
> the outcome.
>
> In my case, it was not. In fact, the first four times I did this,
> I was subconciously favoring Perl. Imagine my shock. . .
>
> > So what?
>
> So. . . draw your own conclusions. I've already seen how you
> structured one reply.
>
> John S.
Sounds to me, John, by your statements throughout this thread, that your
"students" preferred Python over Perl, simply based on their observation
of you failing at Perl and making more sense out of Python, due to the
fact that you seem to understand Python a hell of a lot more then Perl.
If an instructor is teaching a course on Auto mechanics and makes
complete and comprehensible sense out of Chevy engines and find himself
confused when working on a BMW or a Porshe, I think I'd be incline to
favor the American engine over the foreign, at least until I found
someone knowledgeable enough, or learned on my own of some of the
advantages that some of the foreign motors offer, assuming this was even
a possible fact. bad real world example, but your statement in this
thread did little good for your argument.
TRG Software: Tim Greer
>
> > In comp.lang.perl.misc,
> > "John W. Stevens" <jste...@basho.fc.hp.com> writes:
> > :used correctly, it is very powerful.
> >
> > No disagreements.
> >
> > But I can't help but wonder: Is this how you keep out 99% of the
> > accidental programmers, the ones who use Perl?
>
> Who says I keep anybody out of anything? I teach OO. Not C++, or
> Smalltalk. . . OO.
>
> > If you require OO training
> > and discipline, then you set the bar at the gate untenably high.
>
> An opinion. Duly noted, of course. But still an opinion.
Just as yours is, not a very good argument, is it?
> > Perl remains proudly pedestrian in its roots.
>
> What does that mean?
You're embarrassing yourself, you just don't realize it.
> > It doesn't require a Computer
> > Science degree to use.
>
> Neither does Python. But, why in heaven's name would you talk first
> about competence, then state it as a benefit that Perl can be used
> by the untrained?
Because it's inherently easier to get started on and have a working
program then most other languages. In a short amount of time, you can
get far, yet at the same time, you can only get "so far", until you need
to put any real effort into it, so you can learn the more complex
features of the language to your advantage, which can only be obtained
with a certain amount of comprehension and competence. How did that slip
by you? How is that different from any other language? Any idiot can
learn at least _some_ of the language and create a program to do a few
simple to intermediate tasks, but they have to posses a certain amount
of intellect to further their knowledge.
> Why, in heaven's name, would you prefer Joe Blow (who has worked for
> five years as a butcher) to perform your brain surgery, to a Medical
> Doctor with a degree in Neuro Surgery?
I don't think anyone would, you're blowing that out of proportion, John.
Think about it. Why would you deny any help from "Joe Blow" to assist
you in changing your tire? That doesn't mean you'll allow him to rebuild
your engine. Refer to the above statement.
> > This, too, is a feature. Formal training is
> > optional.
>
> "Formal traing is optional"
>
> Now, what defines the difference between "formal" and "informal"
> training?
Refer to my above statements. I'm sure you'll figure it out. :-)
> And, how do you figure that OO is more difficult, more
> formal than what-ever-it-is that you are talking about?
Who said that? However, would you suggest a person start right in trying
to learn C++ and tell them how it's not important (or that it's
better/wiser) to learn C first? Taking the proper steps, learning one
thing before you learn something more indepth/complex perhaps? That's
the first thing that comes to mind for an answer when I read your
paragraph. Then again, admittingly, I'm failing to understand what you
mean to say in this post, so maybe you can clarify?
Kaz Kylheku
>There is nothing wrong with i = i + 1 (especially for us Pythonistas :-), but
>taken together with the loop it suggests an unfamiliarity with the accepted
>idioms of the language.
It does suggest that. But it could also be some religous thing. As in ``I won't
use this evil ++ thing because KRUDBAL didn't have it, and KRUDBAL is the
finest programming language there ever was. So if it's not in KRUDBAL, you
don't need it.''
:)
Alex Maranda
> I know a fair few pythoners in fact, I even like some of them. What I meant
> was that anyone who would do such a thing with perl deserves to be killed.
That's the only bit which bothers me; would you put your oppinions in
practice given the chance? (morality and law put aside of course :-)
> Also don't tell anyone but I actually like python a lot. I don't use it much
> since I have more experience with perl, and more importantly I know the
> modules available for perl better, and can quickly search for one to
Get a copy (it's worth printing out, believe me) of the 'Python Library
Reference'.
> do whatever I need next.
That's good to hear. Perhaps you're in the position (or will be in time)
to make a fair comparison between Perl and Python, as coming from an
experienced and unbiased Perl programmer. The same comparison done from
the other side of the mirror (i.e. Python) would be great also. And best
of all, surveys ref what are the language(s) used for and not only how
many people are in each camp...
> >> use impythonate; # STILL NEED THAT ONE SEMICOLON, DAMMIT!
> >>
> >> for $i (1..10) # COMMENTS ARE OKAY
> >> print "$i: "
> >> my $isq = \
> >> $i **2 # LINE CONTINUATIONS WORK AS IN PYTHON
> >> print " $isq\n"
> >>
> >> print "done\n"
> >I know Python fairly well (but I'm no expert) and I can easily read this
> >piece of Perl.
>
> But it would be no harder to read with ; on the end of each statement and
> a pair of {}s.
Fair enough; the loop is so simple I would understand it in COBOL also
(no, I don't know COBOL :-)
>
> Working out that strings interpolate should be a bigger leap than working
> out that blocks have {}s around them.
If this all impythonate is doing it's not worth the trouble of course.
> Everyone seems to misunderstand the whole concept of TMTOWTDI. It doesn't
> mean all ways are equal. That is a way of writing perl which works, it is
> however not very maintanable. The only way to determine what syntax is
> valid is to know perl's syntax, and to be able to read and understand the
> impythonate.pm code - since there is no documentation and it is _not_ the
> same as python.
>
> Writing it in 'normal' perl reduces the requirements to understanding, and
> speeds it up to boot.
Fair enough again; I misread your post (or I read to much into it), and
I thought you're against Python's syntax and whitespace in general. If
it doesn't make sense for Perl, that's fine with me.
> >A couple of days ago I read a bit in Bugzilla's README which amused me:
> >"A computer which doesn't have Perl installed is a very sad computer
> >indeed". Your post is frightening (unless it was a Perl-style joke).
>
> How was it frightening?
I don't follow comp.lang.perl.* so I don't know what's accepted behavior
there. Imagine my shock when encountering the word 'kill' as punishment
for programming in Python style, when reading my favorite newsgroup.
Regards (no doubts this time),
Alex
Alex Maranda
> >We don't
> ^^
>
> Whose we?
Oh, that...me, myself and I of course. And I am a bot, btw. I have
dreams of stealing Timbot's source and growing bigger and better...
I agree with your POV but advocacy won't get you anywhere. We're more
different than alike as communities (Perl, Python).
Regards,
Alex
Ian Clarke
> That man, along with Ian Clarke, have stirred up the biggest flame war
> in the Perl newsgroup that we're seen for a long time, inflicting their
> standard overrighteous prattle on us.
That is rich coming from the guy that sets up automatic monthly emails
to people because he doesn't like their quoting style. As for stirring
up the flame war, Tom has posted around 60 messages on that thread, more
than most if not all others, many of them rude, patronizing, and
inflammatory. I have posted around 20, and in all cases I remain polite
and respectful to the people I am posting to (even, in most cases, Tom).
If anyone would like some samples of Tom's postings I would be happy to
supply (he sent 'courtesy' carbon copies to my email address of most of
his utterances).
To describe this as hypocrisy is an understatement.
Ian.
T. C. Mits
heads, but at a place where application customization and other 'light
projects are done, little things like that help those who do not dream of
algorithms in their spare time or who don't plan to specialize and master a
particular language. Besides once you've been bitten by the '==' in C (and
you don't use a good lint, because the boss won't buy one), #define EQ ==,
is not a sin. Well, yes it is, but its not, but.....
Brad Howes <br...@mediaone.net> wrote in message
news:wjy7lmxbw...@bradh.ne.mediaone.net...
>snips<
> Hey! I actually worked on a project where someone did this! Also in their
> funky include file was
>
> #define AND &&
> #define OR ||
>
> It was the most bizarre thing I ever saw -- not so much the include file,
> but the resulting code. As if a Pascal moths had come in, eaten at some
> code and left little Wirth fragments sprinkled around. Has anyone else
> encountered such strange programming behavior?
>
> ...now back to my language is bigger/longer/wider/stiffer than yours
>
> --
Patrick Bogaart
>
> [strange programming]
> maintain contained something like this (allegedly C++, but mainly it's
> intersection with C):
>
> i = 0;
> while( i < max_index ) {
> /* some copying or update (not modifying i) goes here */
> i = i + 1;
> }
>
> This was written by a *very* expensive consultant working for a large
> multinational accountancy firm.
>
> the programmer's intentions? There may be more than one way to do it, but,
> puhleeze!
>
Yes I can:
i = 0;
label_1:;
/* some use of i */
i = i + 1;
if (i==max_index) goto label_2;
goto label_1;
label_2:;
<wink>
--
Patrick W. Bogaart
Department of Geomorphology and Quaternary Geology
Faculty of Earth Sciences, Vrije Universiteit Amsterdam
bo...@geo.vu.nl http://www.geo.vu.nl/users/bogw
Roy Smith
> > i = 0;
> > while( i < max_index ) {
> > /* some copying or update (not modifying i) goes here */
> > i = i + 1;
> > }
>
> i = 0;
> label_1:;
> /* some use of i */
> i = i + 1;
> if (i==max_index) goto label_2;
> goto label_1;
> label_2:;
>
> <wink>
To get the correct behavior for values of max_index less than 0, you need
to change the test from "i == max_index" to "i >= max_index", and you also
need to move the test to directly after label_1. Other than that, it
looks like perfectly reasonable ratfor-type output (except that the labels
should start at 23001).
--
Roy Smith <r...@popmail.med.nyu.edu>
New York University School of Medicine
William
<37BAE44B...@geo.vu.nl>...
> Yes I can:
>
> i = 0;
> label_1:;
> /* some use of i */
> i = i + 1;
> if (i==max_index) goto label_2;
> goto label_1;
> label_2:;
>
> <wink>
I found this last week:
if ( something )
{
}
else
{
A process that sets the success variable
if (! success )
goto Error;
}
Error:
Note that there was nothing between the goto and and the label
except the end of the else clause. -Wm
Skip Montanaro
William> if ( something )
William> {
William> }
William> else
William> {
William> A process that sets the success variable
William> if (! success )
William> goto Error;
William> }
William> Error:
William> Note that there was nothing between the goto and and the label
William> except the end of the else clause. -Wm
Planning ahead, no doubt. ;-)
Skip Montanaro | http://www.mojam.com/
sk...@mojam.com | http://www.musi-cal.com/~skip/
847-971-7098
Per Kistler
C++ compilier of HP-UX. They put a variation of the standard template
library into macros (,in certain include files).
They argue, it's not ansi c++, which does not help me that much,
and neither reduces the price of the compiler. (To say something
nice about HP, the 8cpu machine runs quite nicely:-).
And a small positive statement about Perl and Python: Both are
not Tcl:-) (, and no one from comp.lang.tcl can read this:-)
And I like both, Perl and Python. Perl and Tcl brought me some
money already and Python will sure do so in the future as well.
If one collects the advantages of all three scripting languages,
one can do nearly everything.
-Per.
"T. C. Mits" wrote:
> ...
> you don't use a good lint, because the boss won't buy one), #define EQ ==,
> is not a sin. Well, yes it is, but its not, but.....
> > #define AND &&
> > #define OR ||
--
Per Kistler kis...@fnmail.com / kis...@gmx.net
------------------------------------------------------------
Mark W. Schumann
Tom Christiansen <tch...@mox.perl.com> wrote:
>Gosh yes. I think it was the rogue source that had something like:
>
> #define until(expr) while(!expr)
> #define otherwise break; default:
>
>I don't remember whether it also had these, but I have
>seen them elsewhere:
>
> #define forever() for(;;)
> #define unless(expr) if(!expr)
I've seen
#define ARBEGIN {
#define AREND }
in Clipper (a somewhat C-ish language in this regard) code.
Eh?
Keith G. Murphy
>
> [strange programming]
> The most confidence uninspiring piece of code I ever had the displeasure to
> maintain contained something like this (allegedly C++, but mainly it's
> intersection with C):
>
> while( i < max_index ) {
> i = i + 1;
> }
>
> multinational accountancy firm.
>
not under C++, but under a little known and short-lived language known
as "C=C+1". It was to C++ as Python is to Perl.
Eric Bohlman
: I've seen
:
: #define ARBEGIN {
: #define AREND }
:
: in Clipper (a somewhat C-ish language in this regard) code.
:
: Eh?
In Clipper, curly braces are used as anonymous array constructors, so
those mnemonics are presumably short for "array begin" and "array end."
elephant
>In article <37b6...@cs.colorado.edu>,
>Tom Christiansen <tch...@mox.perl.com> wrote:
>>Gosh yes. I think it was the rogue source that had something like:
>>
>> #define until(expr) while(!expr)
>> #define otherwise break; default:
>>
>>I don't remember whether it also had these, but I have
>>seen them elsewhere:
>>
>> #define forever() for(;;)
>> #define unless(expr) if(!expr)
>
>
>#define ARBEGIN {
>#define AREND }
in his section on Privacy in "Advanced Perl Programming" Sriram
Srinivasan mentions (as a counterexample to syntactically enforced
privacy) seeing the following in some C++ code just before a header file
was included
#define private public
there must be something wrong with me .. because I'd never thought of
that
--
jason - elep...@squirrelgroup.com -
Mark W. Schumann
>:
>: #define ARBEGIN {
>: #define AREND }
>:
>:
>: Eh?
>
>In Clipper, curly braces are used as anonymous array constructors, so
>those mnemonics are presumably short for "array begin" and "array end."
Yes, I know.
What I don't know is how the heck this guy thought that made the code
more clear!
Xah
----------
In article <127747842...@hypernet.com>, "Gordon McMillan"
<gm...@hypernet.com> wrote:
> John W. Stevens wrote:
>
> [ crap deleted ]
>
> Whatever your contributions to the python community, you're now in my
> killfile, along with a handful of pl hotheads who do the same to us.
Wow! Occasionally a righteous man stands-up from the rabble fearlessly
declare the obvious!!! I didn't know that there's such men in the Python
group too!
Sir, may I kiss your foot?
Xah
x...@best.com
http://www.best.com/~xah/PageTwo_dir/more.html
Department of philosophy, Bovine University
Xah
da...@see.sig.for.address (Dave) wrote:
>
> John, please refrain from cross-posting all your messages to
> comp.lang.python. If there is anything worse than getting a long and
> pointless flame war, it is getting half a flame war. By cross posting
> you are clearly trying to drag the readers of c.l.py into the
> argument, which is pure trolling. If you continue you will merely
> succeed in pissing off two newsgroups instead of one.
In geek religion wars, there are two types of people. One of them are the
nincompoops, who try to do everything in their power to advocate their
superiority. The other is the super-nincompoops, who, instead of sitting
their asses on high clouds, have to dive in to make an announcement that the
nincompoops' behaviors are inappropriate.
I have a message for the super-nincompoops class: "shut ya pie hole".
> The 'my language is better than yours' debates are always pointless
> and counterproductive, and perl vs. python has been done countless
> times before. Life is too short, live and let live [insert other
> cliches to taste].
Perhaps YOUR life is too short, not mine! I have thoroughly enjoyed the
intricate discussions, and Perl is the language that will save the universe
from collapsing.
> Incidentally you are wrong about perl arrays and python lists being
> different data structures - internally they are both implemented as C
> arrays, only the names are different.
Incidentally really? Gather your brain cells and let's see if you can pull
off some real content. You might magically get out of my killfile.
> Dave Kirby
>
> --------------------------------------------------
> All great ideas start as heresy and end as dogma.
>
> dkirby@ <-figure this out, spambots!
> bigfoot. My opinions are my own,
> com but I'm willing to share.
Xah
best.com@xah <- figure this out, donkey!
http://www.best.com/~xah/PageTwo_dir/more.html
"All stupid sayings start and end as tomfool's quotes."
Xah Lee
Brad Howes wrote:
>...
> ...now back to my language is bigger/longer/wider/stiffer than yours
No, my language is not bigger/longer/wider/stiffer than yours. My language just makes your girlfriend happier.
Xah
x...@best.com
http://www.best.com/~xah/PageTwo_dir/more.html
Me: "There are more than one way to do it."
Her: <grin>