Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • Beni Cherniavsky
    ... 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,
    Message 1 of 6 , Jul 13, 2009
    • 0 Attachment
      On Mon, Jul 13, 2009 at 13:45, Shlomi Fish<shlomif@...> 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@...>
    • Gabor Szabo
      Hi Beni, ... There is a difference when you say: For me Python is more readable than Perl Python is more readable than Perl Perl is NOT readable or Perl
      Message 2 of 6 , Jul 14, 2009
      • 0 Attachment
        Hi Beni,

        On Mon, Jul 13, 2009 at 10:32 PM, Beni Cherniavsky<cben@...> wrote:

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

        There is a difference when you say:

        "For me Python is more readable than Perl"
        "Python is more readable than Perl"
        "Perl is NOT readable" or "Perl is write only".

        The first one is ok.
        The second one is already crossing the line.
        The third one is outright nasty. Don't even try to convince me otherwise.

        Oh and when you try to say in all kinds of words like
        "For us readability is important" is just plain sounds as FUD.
        I could keep saying "For us working code is important" or I could
        say "For us freedom is important".


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

        Yeah, the unknown 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.)

        I don't feel myself competent to answer point-by-point nor do I think it is
        relevant. There are cases where I agree that Perl isn't intuitive enough
        but there are a lot of other cases where I think the same arguments could be
        used just in the opposite direction.

        I think it boils down a lot to how your brain works but more importantly
        to what you are used to.


        > [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...]

        It is hard to keep up with the development of Perl 6 but we are getting closer.
        I am giving a training class next month in Lisbon and I believe in a year or two
        we will see it getting in production. You can already write applications in it.


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

        Indeed. One of the biggest problems of Perl is that it was (and still
        is) used by
        many people who don't know how to write code. They were copy pasting
        bad code examples or code examples that are are only working to keep backword
        compability for the last 22 years. Companies are hiring people with very little
        experience and telling them to write production code without even the
        involvement
        of one experienced Perl programmer.

        IMHO it happens a lot less in Python.


        regards
        Gabor

        --
        Gabor Szabo http://szabgab.com/blog.html
        Test Automation Tips http://szabgab.com/test_automation_tips.html
        Perl 6 Tricks and Treats http://szabgab.com/perl6_tricks_and_treats.html
      Your message has been successfully submitted and would be delivered to recipients shortly.