[Python-il] [hackers-il] Re: [Israel.pm] Perl Vs. Python on Various Points

Beni Cherniavsky cben at users.sf.net
Mon Jul 13 22:32:47 IDT 2009


On Mon, Jul 13, 2009 at 13:45, Shlomi Fish<shlomif at iglu.org.il> wrote:
> On Monday 13 July 2009 12:56:55 Gabor Szabo wrote:
>> By now you should know that any comparison between Perl and Python just
>> leads to some Python fan pulling out the "Perl is not readable" meme.
>> It is totally worthless to talk in public about this. There is always
>> the bad apple to ruin any normal discussion.
>
> Yes, I guess I know that. It still doesn't prevent the rest of the discussion
> from being high-quality and interesting. It's sad that many Pythoneers need to
> state this meme, again and again, (despite the fact that they should know
> better by now) but it doesn't rule out an intelligent and insightful
> discussion.
>
I do want to address that meme productively.
If you catch me degenerating to a troll, feel free to apply sunlight
and I'll to freeze to stone ;-)


First, it's important to clarify that Python fans don't pull the
readability meme to be nasty (at least not initially).
For us, it is honestly the most important thing we can say about Perl
vs. Python.
You could show us a 100 perl features, and we'd still say "but Python
looks better"!
We feel the difference is very real, and very important.

You know Perl & Python and prefer Perl, so obvisouly it's not a
universal assement.
This might be a bit like Lisp parens - some people love them, some hate them.
Lispers fought the "Lisp is unreadable, it all looks the same" meme for decades.
But there is an undeniable reality to the problem: it scares a lot of people.


The second observation I have to make concerns the "semantic gap".
It's a notion I saw once in someone's defense of some esoteric
language, can't find it now.
"Semantic gap" is the distance between how you think about the
problem, and how your code looks.
Obvisously the smaller this gap is, the better - any distance adds
friction, distraction and bugs.

It seems to me that many of the intricacies of Perl's syntax increase
the semantic gap.
(Please read mitigating comments below before replying point-by-point.)

push @array, $val;
    I meant push, of course it's scalar into array, why did I have to
mention "@" and "$"?
$array_ref = [1, 2];
    I meant an array, the "$" is an outright lie!
$length = @array;
    I meant take length of array, but all I wrote was "$" and "@".
$length = scalar @array;
    Better style, but why did I say "scalar" when I meant "length"?
@a = @b;
%a = %b;
    1-deep-copy, but I never said "copy".
$a_ref = $b_ref;
    no copy, but looks similar.
$a = <>;
...
$total += $a;
    I meant convert string to number, why didn't I say it anywhere?
    Also, what does it do if it's not a valid number?
    Where did I say it should silently do that?
    Why didn't I write "<> || 0" if that's what I meant?
open ...;
     What does it do if it fails?  Continues?
     I wrote "open", I didn't mean "maybe open".
open ... || die;
     This ensures that open does its work.  Why do I have to say it?

     What I'm getting is that code should either do exactly what I
said, or crash.
     If I want to recover from errors, I should explicitly write the
recovery path.
     Silent defaults == execution paths invisible on casual reading.

$a > $b;
$a gt $b;
    I meant compare values, why do I mention the type?
    If it implies conversion, it's non-obvious (see above);
    if it doesn't imply conversion, why do I have to mention it?
%b2a = reverse %a2b;
    Happens to work neatly, but not because that's what "reverse" does.
    It's converted to a flat list, the list is reversed, and parsed into a hash.
    You have to think about the process.  (OK, this one is an idiom)
while (($key, $value) = each %hash)
    I meant "foreach", why did I write a while?
while(<>)
    I meant "foreach", why did I write a while?
sub s {
  my ($a, $b) = @_;
  ...
}
    I meant "sub s($a, $b) { ... }", why do I write it this ugly way?

[BTW, Perl 6 is much better!  It fixes all problems that were rooted
in historical accident rather than deliberate choice.
Eventually I gave up on it, but for lesser reasons...]

Of course, with experience these become second nature to you.
You write and read idioms, and you know exactly what they mean.

So it's not so much of a practical question as phylosophical - do you
care how your idioms look to the non-initiated?
How close is it to English?  How much brain cells do you need to
transparently read and write these idioms?
Note that these are ideological questions.  If a non-obvious syntax +
deeper training idioms give you more power, why not?

The Python answer is "because, period": we believe in "Readability counts".
The second answer is proof-by-example: if Python manages a cleaner
syntax with comparable power, it's a win.


On a deeper level of semantic gap, the above "petty" examples don't matter.
The real semantic gap is in domain-specific things.
The question is not how you manipula lists, it's how you manipulate FooFrobs.
So the real question is - does the language allow writing a great
FooFrobs library?

This depends on syntax like function definition and calling, class
definition and use,
namespace mechanics, higher-order facilities, control abstractions, etc.
These are harder to evaluate, so I won't even try to list examples.
I do think Python is very good on this scale too.

On this point,  http://greenokapi.net/talks/ReadablePerl.pdf is a great read.
Shows perl is not bad either.

-- 
Beni <cben at users.sf.net>


More information about the Python-il mailing list