Python vs. Perl

Jonathan Gardner gardner at sounddomain.com
Thu May 24 19:37:54 EDT 2001


On Thursday 24 May 2001 01:56 pm, Thomas Wouters wrote:
> On Tue, May 22, 2001 at 03:09:51PM -0700, Jonathan Gardner wrote:
>
> [ Jonathan discovers Python is a great programming language ]
I already knew that Python had to have something. This email is my quest to 
figure out what it is.

>
> > What does Python have that makes it so great? Why should I spend time
> > to become intimate with it? I am looking for comments from people that
> > actually have used Perl or C/C++ extensively, and I am looking for
> > comments that go beyond the FAQ.
>
> You've gotten quite a few responses alread, but I'd like to elaborate on a
> point that Martijn only grazed: Python is incredibly easy to extend. The
> API is fairly simple and very powerful (almost all 'builtin' modules and
> types are implemented using that API, without 'special knowledge') and the
> Python implementation itself is very clear and clean[*]. This makes Python
> (its C code) not just fun to play with, it also makes it very portable.

This point should be stressed more and more. What use is a langauge if it 
cannot do something useful? And almost everything useful has already been 
done in C. Case in point: I am working on a game on the sideline. I NEED all 
the graphics stuff to be done in C, PERIOD. But all the higher level rules 
and interfaces and stuff, who cares what speed they run at, so I want to 
program that in a different langauge.

What I end up with is my specialized C graphics engine, with a scripting 
language interface. I was trying to do perl... and I ended up here.

> And if that isn't enough reason, there's more! Writing code in Python is
> very easy, because you can write code almost as fast as you can type.

Is it true? I've heard rumors of Python programmers programming as fast as 
they can write...

Counterpoint: I don't think it can always be considered a good thing to write 
code as fast as you can type, because that means you should probably be using 
a function or something to do what you are doing. If you are typing the same 
thing over and over again, you aren't programming - you are typing something 
that should be typed once and used multiple times, right?

Therefore, if I am using a language that REQUIRES me to type the same thing 
over and over again, it means it is a TEDIOUS language to program in, not 
necessarily a good one.

I tend to belong in the camp that each line of code has at least a minute of 
dedicated thought that goes into it. The programmer should ask himself, "Is 
this exactly what I want to be doing? Is this comparison a '<' or a '<='? Is 
this off by one? Do I want this element in the front ore the end, or am I 
pulling it off by the front or the end? Does this function return one value 
or two, and which one am I looking for? Which order do I sort in? No matter 
what language you are in, you have to be very careful about the details. 
Thus, you SHOULDN'T be writing code as fast as you can type. You should be 
worrying whether or not you wrote the expression down exactly as you meant it.

Compare, for instance, the amount of time the editor or columnist spends 
writing and analyzing a column versus the amount of time someone spends to 
write an email to a friend. If the reporter can write as fast as he can type, 
he must either not be writing something important, or he must be making a lot 
of mistakes. A serious reporter will spend time to research his facts, 
double-check for mistakes, and finding appropriate quotes, etc. Thus, he will 
spend a lot of time writing a few lines of text, because the thing he is 
doing has a lot more gravity than a casual email to a fried.

> Most of the times it isn't necessary to
> translate it back into C 'for speed', especially if you want or need to use
> dicts (hashes.) Python's dicts are just hard to beat.

I know C/C++ is poorly suited for hashes/dicts/maps, BUT the STL's map is 
AFAIK very similar to a hash/dict. I use it frequently, along with stacks, 
lists, arrays, and strings from the STL. Besides, the problem in this aspect 
of C/C++ is not that you can't do it, it's just that everyone keeps 
reinventing the wheel. Once you program a hash or a dict in C once, you 
should never have to do it again, right?

Also, I don't think anyone can claim that Python's dicts are better than 
Perl's hashes or C++ STL's map. Well, maybe Perl's hashes are a little better 
because you can do so much stuff with it in so many ways...

> Tim Peters (aka the timbot, watch for his postings in a cinema near you)
> likes to explain how implementing an algorithm in Python rather than C or
> more arcane (or should I say 'obscure', Tim ? :) languages, allows him to
> find out why the algorithm sucks without wasting too much time on it. That
> alone is a very good reason to use Python :)
>

Agreed. I do a lot of experimental stuff in Perl, and I never code in C or 
C++ until I know exactly what I am doing.

> And-if-you-miss-the-perl-oneliners--grow-up-or-check-the-FAQ-again-ly y'rs,
> ;-)

Grow up? Who idolizes Monty Python? =)

>
> [*] Of course the code base could be cleaner, but it's a damned bit cleaner
> than the cleanest bit of code I ever saw. And if you believe in source as
> documentation, the Python source is the best reference manual for its own
> API. You can see which functions are actually *used*, rather than
> documented ;)

I have to admit, it is extremely easy for anyone who knows any language to 
read. I am picking it up at a remarkable rate. The documentation within the 
code is not a new idea, but the way Python handles it is looks very clean.

As with any language, the documentation can never be better than the zealots 
who write documentation. Perl has Perldoc, which was supposed to be the 
answer to the world's crisis, but it's not very good unless you USE it.

And C/C++ has their comments, and with a good program you can create 
documentation from the comments. (Doxygen is my fav!)




More information about the Python-list mailing list