Python vs Perl (was Re: Changing case of file names?)

Andrew Kirkpatrick andykirk at ubermonkey.net
Thu May 4 06:39:48 CST 2006


Michael Cohen wrote:
>   One of the corner stones of python programming is "there is only one way to
> do it" whereas perl like to boast "there is more than one way to do it". I
> think this is the fundamental philosophical difference between the two
> languages.

Perl's "more than one way" is all about freedom, the price of which is 
vigilance. But it also has strict mode in which all variables must be 
declared, warnings mode which lets you know about many suspect 
constructs and diagnostics which almost takes the place of a pedantic 
tutor. Its got a lot of history and baggage and is far from perfect. I 
think Python isn't so different in that sense. I like them both, but if 
one deserves bashing they both do.

>   Python has very simple and _consistant_ syntax, where as perl has anything
> but a consistant syntax.  

The syntax is fairly consistent, but the semantics aren't so much:
http://www.thescripts.com/forum/thread24988.html
http://toykeeper.net/warts/python/?mode=answer
http://www.ericw.org/rants/showrant.psp?rant=python
http://www.beust.com/weblog/archives/000277.html

>   The perfect example is scalar/list context - having to remeber unrelated
> things about a function to know how its supposed to work consumes lots of brain
> power.

This is true, but the same holds for remembering which variable is of 
which type in python, versus perl's $, @, % and & for scalars, arrays, 
hashes and functions respectively. Rebinding a variable from one type to 
another is more common in python, whereas in perl &glob, $glob, @glob 
and %glob don't clobber one another.

Having regexes, file, directory and process handling in the core of Perl 
means common tasks are kept simple. In Python I keep scratching my head 
wondering which module the function I want is in - I look for sleep 
under thread, glob under os, etc. Large programs are made of many small 
tasks, and if they are kept simple to implement it can help keep the 
overall complexity tractable.

> Another problem in perl syntax is the inconsistant syntax for different
> pieces of functionality. Whereas normal languages put functionality in
> libraries accessible with a consistant syntax, perl puts different
> functionality in different syntax:

The syntax is inconsistent in some ways, but flexibility is the aim and 
it shines through. One might learn the syntax of python in a day, but 
one will only learn the essential syntax of perl in a day. Over the next 
5 years one will continue to be surprised, with decreasing frequency, at 
some new turn of phrase. This can serve to keep things fun, but 
production code calls for more clarity and less tricks.

>   This is one of my favourite quotes from the perlfunc man page:
> 
>        Remember the following important rule: There is no rule that relates the
>        behavior of an expression in list context to its behavior in scalar con
>        text, or vice versa.  It might do two totally different things.  Each
>        operator and function decides which sort of value it would be most appro
>        priate to return in scalar context.  Some operators return the length of
>        the list that would have been returned in list context.  Some operators
>        return the first value in the list.  Some operators return the last value
>        in the list.  Some operators return a count of successful operations.  In
>        general, they do what you want, unless you want consistency.
> 
>   So to learn perl is a steep curve because you need to learn one kind of
> syntax after another.  

Yes and no... perl will comply more with the expectations of a 
shell/sed/awk, even C user, as it was forged in the trenches of admins 
fighting the good fight(!). Python will probably gel better with a user 
of basic and maybe pascal, as they are all teaching languages which aim 
for clean syntax. Perl has a vast set of libraries with good and bad 
examples, but the well written ones are pretty consistent in their use. 
Buried in that perlfunc quote is the kernel of the matter - 'most 
appropriate'. If its worrisome, just remember the scalar return value 
and avoid list context.

>   Another huge perl wart is autovivification - the magical instantiation of
> objects by the interpreter on demand.

That doesn't happen if you follow the advice of every perl book, and 
'use strict' for anything non-trivial.

>   In fact when you dable in enogh perl code you will appreciate the marvelous
> creation that is the perl parser. There are some cases where the parser will
> even get confused in its own syntax and miss-parse perfectly correct code - i
> came across it a couple of times. It really is a marvelous bit of code to be
> able to make sense from such a complex grammer. (Perl code can not be
> represented by standard LR grammer because its inconsisntant - much like visual
> basic actually).

Except visual basic is a barren wasteland like newspeak, while perl is 
rich with tradition like english. I haven't seen any visual basic poetry 
contests :)

>  And finally, let us all face the reality that perl is a dead language. (duck
> :-). Perl 6 has a totally different syntax to perl 5 and looks much like (oh
> no) python. changing the -> to ., the . to + etc. So if you want to stick with
> perl in the long run you _will_ have to relearn a new syntax if and when perl 6
> is released.

Syntax changes like that are cosmetic. Perl6 will have a lot of features 
  including Perl5 support, and a much richer syntax than Python... one 
of the reasons its still over the horizon :\ And its far from dead - if 
there has been a slump in usage its mainly due to the rise of PHP in the 
web space and Java in the enterprise. Neither of which serves well as 
glue for everything from console one liners to replicated corporate 
databases.

On freshmeat.net:
# Perl    (3613 projects)
# Python  (2340 projects)

The CPAN has 38,000+ modules, sure some do the same things in different 
ways, some are good and others bad - the same goes for any language: 
http://cpantools.com

Its hard to tell with Python, though it predates Perl it has no central 
repository of modules. The most comprehensive list I could find has a 
few hundred: http://cheeseshop.python.org/pypi/

> It is possible to produce readable perl code, but it just takes a lot more
> effort and experience because you need to be on the lookout all the time. And
> the reader needs to be very well versed in perl as well - knowing all the
> syntactic nooks and crannies. Python allows most programmers with basic
> experience to pick it up and read it without even needing to think about it,
> even if they have Java/C/C# (or even perl) background.

I don't think it takes a lot more effort to write clean perl, you stick 
to straightforward constructs and if you do that there is no need to be 
on the lookout all the time. Then the reader doesn't need to be very 
well versed in perl either.

> I write all my code to be readable by that less-than-gifted first-year
> high-school student. (Quite often it turns out to be me 6 months from now).

I do the same in Perl and it looks a lot like C, parentheses around 
every function call, consistent indenting and comments explaining the 
rare tricky bit. And from Perl I can inline 
C/C++/Python/PHP/Guile/Java/Ruby/Lua or even assembler if the rare need 
arises. There be power in that there line noise :)

A quick reminder, I'm a fan of both languages. Now lets all bash PHP!

Andy

P.S. Here's some crazy line noise - sorry for the spoiler but it 
generates a random maze, solves it, and renders an animation of the 
solution in an AVI file:
http://perlmonks.org/index.pl?node_id=542489

-- 
I cannot do it without computers.
  - William Shakespeare, "The Winter's Tale"



More information about the linuxsa mailing list