Nicholas,
Well
put. I come from a physics FORTRAN background and when I decided to learn
C and start using it I heard the same arguments: it's too hard to
read.
It's a
silly argument to use against a language. It's like an English-only
speaker claiming he won't learn Greek because he doesn't understand it
:-)
I've
been programming Perl for about 10 years and Python about 6 months. Most
of what Python programmers find counter-intuitive about Perl seem perfectly
reasonable to me and I find something in Python quite counter-intuitive although
I understand the rationale.
For
the non-Perl people here, let me defend Perl by saying it is VERY good at what
it was built for and not so good (but passable) at what it was not built
for.
What
it is good at:
Very rapid development of small
scripts
Replacing sed/awk/ksh/etc for
scripting Manipulating
strings
System administration
tasks
What
it is only passable at
Large scale team
development
OOP
Most
of what Python developmers complain about in Perl are aimed at the rapid
development thing. Perl is very terse which allows you do quickly script
up small filters and data miners. I still use Perl for this and don't
think that will ever change.
Someone also complained about the "many way to
exit" issue. Personally, I love that and use it to clarify my code.
On a normal if statement I will put the test first:
(test) &&
(stuff-to-do);
whereas if the test will affect code flow in a more
major way I use the inversion, as with:
return if
(test);
It
allows me to quickly re-read my older scripts and understand the code flow
faster.
Having
said all that, I'm also a big fan of Python which I can see will be very good at
the two things Perl isn't so good at. However (and I know most here will
disagree) there's still things I don't like about Python. My top two
are:
1.
Lack of closure on flow statements.
I've
already been bitten by:
if
test:
do this
do that
where
"do that" should have been out-dented. For a non-Python programmer, this
"feature" can lead to some very non-intuitive coding should someone be so
perverse as to write it :-)
2.
Lack of "use strict" semantics. I know that pychecker can supposedly do
this but I still believe it belongs in the language.
Don't
try to defend them. I've read all the arguments but I just don't agree
with the design choice.
Jeff
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 03, 2005 8:43 AM
To: tutor@python.org
Subject: Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 03, 2005 8:43 AM
To: tutor@python.org
Subject: Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Well, here's my $0.02.
I would recommend caution regarding the trashing of Perl. One thing I've been very impressed with on this list (and other segments of the Python community) is the _fairly_ cordial relationship between the supporters of the two languages. Contrast that to a lot of PHP literature I've seen, which doesn't even acknowledge that Perl exists. My theory is that many who use PHP got kicked around by trying to learn Perl, and bitterness set in. But that's a digression... Anyway, I'm on the fence as to whether I want to learn Python (not exactly a "core competency" for statisticians, but I do line the numerical computation capabilities which look _much_ better than those of Perl), and I wouldn't want this negativity to push me (or others) away.
>...
Nicholas Montpetit
Deluxe Business Services
651-787-1008
_______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
