Perl Vs Python

[Derek Thomson]

John Smith wrote:
> Hello:
>   do Perl & Python do similar things?
>   What should be the rationalle to one or the other?
> Thanks.
> 
> 

Please note: 1) there is no comp.lang.perl group, just 
comp.lang.perl.misc; 2) do *not* crosspost these "please compare these 
technologies" things to both groups at once - people will think you are 
trolling.

Aside from that, in general, I agree with the replies here.

In addition, I made a posting comparing the two when someone was 
apparently rudely trolling comp.lang.perl.misc. Someone actually asked 
"why should learn Python, anyway?"

Since I've not posted it to comp.lang.python before, and it took me a 
while to bash it out, here it is. This is purely based on my experience 
and biases, but here it is, for what it's worth.

Please note that I use, and like, Perl and Python to about an equal 
extent. Really!

Here we go:


Eric J. Roode wrote:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 >
 > Derek Thomson <derek at wedgetail.com> wrote in 
news:3da91047$0$23169$afc38c87
 > @news.optusnet.com.au:
 >
 >
 >>Why do you ask? Why does it have to be mutually exclusive? Can't you
 >>like and use both? I am also using, right now, in some capacity, C,
 >>Java, Tcl, Lisp (my Emacs functions!) and I've done a fair bit of C++ in
 >>the past.
 >
 >
 > I agree.  I use (mostly) Perl, C, and various webbish languages (html,
 > javascript, etc); it's pretty obvious which language is appropriate when.
 >
 > [dons flameproof suit]
 >
 > I confess my ignorance of python.  Every now and then I think "maybe I
 > should learn it"... but then I think "Perl does everything I can imagine
 > doing, why bother learning python?"
 >
 > [for the record, I often think "Maybe I should learn java", then I 
start to
 > do so, then I realize "Man! This is hard! Perl does all of this so much
 > easier!"]
 >
 > So anyhow, for someone who's ignorant of python, what's it good at?  The
 > same sorts of things as Perl?  If so, why bother learning it?  If 
not, what
 > are its strengths over Perl, and what are Perl's strengths over python?

Under the syntactic hood, I believe they are more similar than they are
different - relative to most other popular languages.

They are both dynamic (ie you can create code (including new classes) at
run-time, and you can explore any data structure, dynamically), and both
have what I'm going to call an "open" object model - by that I mean that
it is simple, dynamic (of course), and is OO at run-time ie. no
information about objects or classes is thrown away during compilation
(C++ is not really OO at all at run-time, and Java only allows
reflection into the class information the VM has - but no modification).

Python has a large number of features you will recognize from Perl -
like lists (analogous to arrays in Perl), hashes, operations for
selecting and transforming lists, and a lot of the idioms transfer
pretty cleanly between them.

Now, the differences. As I see them. Python's syntax (and therefore much
of it's semantics) are minimalist. There fewer syntactic elements, and
fewer ways to put them together in interesting ways. This has the
advantage that it's easier to learn and for anyone to read (if the Perl
code isn't well commented).

For example, Python doesn't allow hash slicing, so you can't do this:

my %hash = {};
@hash{@list} = (1) x @list;

... to create a set for fast membership testing. So all those neat
little idioms Perl has for hash transformation are out. In Python list
slices must be contiguous, so you can't do nifty one-line list
shuffling, either. Pythoners will say all this is a feature. In Python,
you would say something like:

hash = {}
for item in list:
    hash[item] = 1

... to do the same thing. Again, clearer for the non-initiated. Some say
that where Perl has "more than one way to do things", Python has "only
one way to do one thing". That is of course, not true, but that's the idea.

Notice also that there are no "funny" character "$@%" in front of
variables in Python, and it doesn't have different kinds of braces for
different kinds of indexing. Everything in Python is a reference, so you
don't have this typing problem. Therefore you can't get the contexts
wrong. On the other hand, this means that there is no context, so the
compiler can't work out what you're trying to do.

So, for something like:

$hash->{$name}->[$index] = 42

... if there was no reference to an array in the hash at $name, one
would be created. In Python, you have to check, and create one, if
you're not sure, like in Java or C++. (And then you have to make sure
the list is large enough for the index, as well). Assuming the lists are
always MAX_INDEX in length then, to keep it simple:

if name not in hash:
    hash[name] = [0] x MAX_INDEX

hash[name][index] = 42

... or something along those lines.

This doesn't really come up too often, but when it does, I certainly
miss it! Again, the Pythoner will say that this sort of thing is best
made explicit.

Now, the big one: the object model. Python has exactly one object model.
Perl supplies only the bare bones support for objects, and you can layer
a number of alternatives on that, if you like (for example, the fields
module, or the very interesting Class::Contract module).

The advantage to this is that all classes are guaranteed to work
together properly, even in the face of inheritance. Will a "standard"
Perl class be able to inherit a Class::Contract class? I doubt it. I can
barely get standard Perl classes to inherit from each other nicely
without clashing :) So, the object model is nice and clean and simple,
but doesn't allow much in the way of interesting innovation. I think
Class::Contract would be straight out impossible in Python.

So, some would claim that all this simplicity and standardization make
Python more amenable to larger projects. I don't know that this is
necessarily true, as I am working on both Python and Perl
multi-programmer projects at the moment, and I don't think in either
case the language itself has been an issue. Of course we use warnings
and strict in Perl, so this make Perl much safer from the silly errors
that might give it a poor reputation in terms of maintainability.
(Python, in short, always warns and is always strict). I admit these are
still quite small projects (a few developers each), but it does show
that we *can* read each others code. Perhaps this argument for Python
holds better for larger projects, and where you can't guarantee that
every programmer will have learned all the ins-and-outs of a complex and
subtle language like Perl. I don't know, I'd welcome any further
discussion on this topic of applying both Perl and Python to really
large projects.

Then there's the support. Perl's is better, no doubt about it. More
developers, and a much larger base of *supported* third party modules on
CPAN. Much of the important stuff in terms of extra modules is there for
   Python, I just find it isn't always supported as well as I'd like. YMMV.

So, what was the question again? ;)

Ah yes, why learn Python if you know Perl? Because you'll be exposed to
new ways of doing things, which will actually shed new light on your
Perl programming. I don't think I'd have come as far with OO Perl if not
for Python's example of a "one true way" scripting object model (and of
course Conway's excellent OO Perl book). This cuts both ways - Pythoners
could learn a thing or two from Perl - I've often found a class in
Python I *never* would have if I hadn't been thinking "there *must* be a
way to do this as easily as in Perl" and didn't give up until I found
it. Sometimes I find things that even more experienced Pythoners didn't
know about, following this procedure.

Also, it may be worth trying if your team is traditionally scripting
language resistant (it's much gentler and familiar seeming), or if your
project is larger and you're convinced that Python is better for that,
or if you want to integrate with Java.

So, Java. Perl really can't win here, as Python has the amazing Jython.
Which is Python implemented in Java, basically. Your Python object
methods can be called from Java code. Your Java classes can call Python
object methods. Seamlessly. Out of the box. Apart from a few
differences, Python implemented in C is the same as Python implemented
in Java. So, you can implement a Swing GUI in Python. Write tests for
your Java classes in Python. Stub out classes in Python to be
implemented "properly" later. Even just write the performance critical
classes in Java, and do the rest (traditionally the layer you want to be
highly flexible) in Python. Perl can't compete here, unless someone
implements Perl itself in Java. Given the complexity of Perl, that's
probably not going to happen. So in this case Python's simplicity is a
clear win - as it allow implementation on new platforms to spring up
more easily.

I ported Fnorb (the Python ORB) to Jython with almost no effort - once I
had removed the little bit of C code in Fnorb. I am seriously impressed
with it.

A final note. Python is also *much* easier to integrate with C, as well.
The C API is just much cleaner than Perl XS, which is very complex. And
it also fits very well with objects in C++, and Perl XS definitely can't
do this very well. So if my task were basically just to provide a
scripting interface to some C or C++ code, I'd probably go for Python. I
wrote a framework to explore the differences between XA implementations
in various databases in Python in about half a day - and it was also
interactive, which helped a lot when trying to track down inconsistent
behaviours (Python comes with a nice interactive shell).

And that's about it, from my personal perspective. YMMV.

The whole thread can be viewed at 
<http://groups.google.com.au/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=3DB07301.D87964CA%40earthlink.net&rnum=46&prev=/groups%3Fq%3D%2522derek%2Bthomson%2522%26start%3D40%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26scoring%3Dd%26selm%3D3DB07301.D87964CA%2540earthlink.net%26rnum%3D46>

Regards,
Derek.