[Tutor] Are you allowed to shoot camels? [kinda OT]

[Nicholas.Montpetit at deluxe.com]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tutor/attachments/20050203/27cc5a1f/attachment.htm