Changing case of file names?

Michael Cohen michael.cohen at netspeed.com.au
Thu May 4 01:42:17 CST 2006


DSL,

  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.

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

  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. 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:

  a=foo(bar)    -  A function call
  a -f "bar"    -  File access functionality
  s/foobar/bar/ - Regular expressions.
  
  etc, etc

  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.  

  Normal languages seperate syntax to functionality. For example the
python syntax is very consistant and can be learned in a couple of hours tops.
Then the functionality comes with the use of libraries:

  import re
  re.sub("foo","bar","foobar")
  
  import os
  os.access("/etc/passwd")

  not to mention usable exception handling, and object orientation which both
are huge hacks in perl.

  Another huge perl wart is autovivification - the magical instantiation of
objects by the interpreter on demand. This leads to really hard to track bugs
due to simple typos and can lead to performance problems if done incorrectly.
Seems like a good feature when you first hear about it - but it really does get
in the way.

  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).

 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.

Notice that I didnt talk about algorithms at all here - I totally agree with
your algorithm statement.

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.

This is one of my favourite Linus Torvalds quote:

if you have a complex function, and you suspect that a
less-than-gifted first-year high-school student might not even
understand what the function is all about, you should adhere to the
maximum limits all the more closely.

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).

Michael. 
  
On Thu, May 04, 2006 at 09:44:23AM +0930, David Lloyd wrote:
> 
> Michael,
> 
> >   Risking a flame war, if you want to invest the time to learn a new
> >   language you better spend your time learning python. I used to be a
> >   "perl monger" but realised that unfortunately my brain has limited
> >   capacity to wrestle with unreadable code , and yes - i do need to
> >   read my code next week quite often.
> 
> Simply because you can walk in front of trains and get squashed does not
> imply that you do. Simply because one is incapable of producing readable
> Perl code does not imply that Perl code needs to be unreadable.
> 
> If you implement an inefficient algorithm in Python, it will be
> ineffecient in Perl, C, Jav, C++ or C#.
> 
> DSL


More information about the linuxsa mailing list