Hi Jeff,
> 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 :-)
Now that's well put.
> 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
I'll second your thoughts on Perl's shortcomings. What brought me to Python was the shortcomings in Perl that you've mentioned, along with Python's better numerical computation and GUI creation capabilities. If people on the list are to criticize Perl, I wish they would stick to the things that are Perl shortcomings for people who understand Perl. I'm OK with that, but I can't stand by and let people criticize something just because they don't understand it.
I don't know anything about Python, so I'll reserve judgement until I do. I am confident that I will learn to like Python as much (or maybe even more :-) ) than I like Perl, and then I'll be able to choose the best tool for the task at hand.
> 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:
I like the "there's more than one way to do it" thing as well. Your example below is very illustrative of that concept.
> (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.
One thing I really like about Python is the community: you folks are very friendly and helpful. I look forward to learning as much as I can about Python from this list!
Thanks,
-Nick
_______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
