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

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

Expand Messages
  • Gabor Szabo
    I don t understand you Shlomi. By now you should know that any comparison between Perl and Python just leads to some Python fan pulling out the Perl is not
    Message 1 of 6 , Jul 13, 2009
    • 0 Attachment
      I don't understand you Shlomi.

      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.

      Nevertheless let me comment on some of your points,


      On Mon, Jul 13, 2009 at 11:10 AM, Shlomi Fish<shlomif@...> wrote:
      >
      > 1. Syntax as an Indicative of What the Language is Doing:
      > ---------------------------------------------------------
      >
      > He said he didn't like Perl syntax like "push @$array_ref, $val;" because
      > of the sigils. I said I happen to like it because the extra characters
      > convey meaning. By looking at this code I know that $array_ref is an array
      > reference, that it is being treated as an array and that one appends a
      > single ("scalar") value to it. On the other if I see code like this:

      I like the sigils ($ @ %) indicating the data type but I dislike that
      in Perl 5 we need to
      dereference arrays writing @$aray_ref and there even more horrid constructs.
      Luckily in Perl 6 it is cleaned up hence I prefer it over Perl 5.

      Some people still add & in front of the function names even though
      that requirement
      was eliminated 15 years ago.


      >
      > 4. Hiding Code By Using .pyc's
      > ------------------------------
      >
      > The python backend compiles the text-based Python code to bytecode, and
      > caches the result in .pyc files. My partner to the conversation argued that
      > he often uses these .pyc files to "hide" the source code from people he's
      > distributing it to them, so they will be unable to reverse engineer it.
      >
      > I told him that with a symbolic language such as Python, such .pyc files
      > do not provide adequate "protection" as they contain the names of identifiers
      > and other detailed information on the code.

      Let's go to the car analogy.

      Locking your car does not stop someone from steeling it but it makes
      it more difficult.
      It might also be the difference between making you eligible or not to
      receive payment from
      the insurance company.

      <story>
      Actually I have a personal experience with this. A long time ago I had
      a car that cost
      only a few thousand shekels so I did not make the comprehensive insurance.
      Unfortunately I have not installed Rav-bariach-lock either. One night
      some kids stole it,
      used it for a few weeks and crashed it. The police found it and I had
      to handle the disposal
      of what remand from the car. It clearly wasn't a professional car
      stealer - did not take it for
      the 'monetary value' of the car but for the fun value. They were
      script kids. If the car had a
      lock on it they would have moved to the next - easier - target.
      </story>


      Creating byte-code might not stop those who really want to steal your
      code but it will make
      it slightly more difficult and it might make the difference for the
      legal department.

      Talking about obfuscation and Perl on a Python list is just plain
      silly as you could see
      from the other comment. For some reason Python programmers -
      especially those who
      once used Perl - cannot stop themselves from such stupid derogative comments.

      Technically you might be right that obfuscation and bytecode pose the
      same level of
      difficulty for reverse engineering. I don't know. What I know is that
      obfuscation is not an
      accepted practice in the industry and compilation to byte-code is (see
      Java, C#).

      So the fact that Perl 5 cannot be compiled to bytecode is a major drawback in
      every place where a company wants to distribute its code to customers.
      Luckily this is too solved by Perl 6 so if you write in Perl 6 you can
      already compile
      it to Parrot byte-code.

      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
    • Shlomi Fish
      ... 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
      Message 2 of 6 , Jul 13, 2009
      • 0 Attachment
        On Monday 13 July 2009 12:56:55 Gabor Szabo wrote:
        > I don't understand you Shlomi.
        >
        > 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.

        >
        > Nevertheless let me comment on some of your points,
        >
        > On Mon, Jul 13, 2009 at 11:10 AM, Shlomi Fish<shlomif@...> wrote:
        > > 1. Syntax as an Indicative of What the Language is Doing:
        > > ---------------------------------------------------------
        > >
        > > He said he didn't like Perl syntax like "push @$array_ref, $val;" because
        > > of the sigils. I said I happen to like it because the extra characters
        > > convey meaning. By looking at this code I know that $array_ref is an
        > > array reference, that it is being treated as an array and that one
        > > appends a single ("scalar") value to it. On the other if I see code like
        > > this:
        >
        > I like the sigils ($ @ %) indicating the data type but I dislike that
        > in Perl 5 we need to
        > dereference arrays writing @$aray_ref and there even more horrid
        > constructs. Luckily in Perl 6 it is cleaned up hence I prefer it over Perl
        > 5.
        >

        Normally you need only one dereference of some arrow expression. I'm
        personally am not bothered by it too much. I haven't investigated too much of
        how Perl 6 handles the references' syntax (except for the leading digit be the
        same for every access), but it may be worthy of inspection.

        > Some people still add & in front of the function names even though
        > that requirement
        > was eliminated 15 years ago.
        >

        And it's no longer recommended because it over-rides prototypes and does other
        shenanigans.

        > > 4. Hiding Code By Using .pyc's
        > > ------------------------------
        > >
        > > The python backend compiles the text-based Python code to bytecode, and
        > > caches the result in .pyc files. My partner to the conversation argued
        > > that he often uses these .pyc files to "hide" the source code from people
        > > he's distributing it to them, so they will be unable to reverse engineer
        > > it.
        > >
        > > I told him that with a symbolic language such as Python, such .pyc files
        > > do not provide adequate "protection" as they contain the names of
        > > identifiers and other detailed information on the code.
        >
        > Let's go to the car analogy.
        >
        > Locking your car does not stop someone from steeling it but it makes
        > it more difficult.
        > It might also be the difference between making you eligible or not to
        > receive payment from
        > the insurance company.
        >
        > <story>
        > Actually I have a personal experience with this. A long time ago I had
        > a car that cost
        > only a few thousand shekels so I did not make the comprehensive insurance.
        > Unfortunately I have not installed Rav-bariach-lock either. One night
        > some kids stole it,
        > used it for a few weeks and crashed it. The police found it and I had
        > to handle the disposal
        > of what remand from the car. It clearly wasn't a professional car
        > stealer - did not take it for
        > the 'monetary value' of the car but for the fun value. They were
        > script kids. If the car had a
        > lock on it they would have moved to the next - easier - target.
        > </story>
        >

        I think your analogy is more or less valid here, even though I may argue that
        a single car is not analogous to code that you distribute to customers at a
        lot of cost.

        >
        > Creating byte-code might not stop those who really want to steal your
        > code but it will make
        > it slightly more difficult and it might make the difference for the
        > legal department.
        >

        Well, it's fig-leaf protection. It may be good enough for the legal
        department, but it won't really protect your code (which is how fig-leaf
        protection is defined).

        Personally, I think more software companies should trust their customers (like
        FOSS developers trust their users), and realise that what matters is not how
        many people violate the licensing terms, but how many of them would have been
        paying customers:

        http://better-scm.berlios.de/bk/what-bitmover-got-wrong.html

        > Talking about obfuscation and Perl on a Python list is just plain
        > silly as you could see
        > from the other comment. For some reason Python programmers -
        > especially those who
        > once used Perl - cannot stop themselves from such stupid derogative
        > comments.
        >
        > Technically you might be right that obfuscation and bytecode pose the
        > same level of
        > difficulty for reverse engineering. I don't know. What I know is that
        > obfuscation is not an
        > accepted practice in the industry and compilation to byte-code is (see
        > Java, C#).
        >

        Well, in Java and .NET compilation to byte-code may make more sense because
        they are not symbolic languages. However, as my link to the Slashdot
        discussion indicates, reverse engineer Java byte code may be substantially
        easier than reverse engineer real Assembly code.

        In Python, the .pyc's are generated for optimisation and are not meant as a
        reliable way to obscure the code. So relying on it for protecting the source
        code, may be good for covering your ass, but it's not real protection.

        > So the fact that Perl 5 cannot be compiled to bytecode is a major drawback
        > in every place where a company wants to distribute its code to customers.

        The perl 5 virtual machine uses its own internal bytecode, which is documented
        and accessible and can be utilised for such things. I recall that ActiveState
        used to distribute their PerlMx (Perl Mail Exchange - a now defunct spam
        filtering framework) as Perl bytecode. Again - not real protection, but
        possibly enough to satisfy their legal department. So the technology is there.

        Again, I wouldn't recommend doing it, because it's not real protection, but
        neither are Python's .pyc files.

        > Luckily this is too solved by Perl 6 so if you write in Perl 6 you can
        > already compile
        > it to Parrot byte-code.

        Well, there's still a long time until we will have a usable Perl 6 compiler.
        At the moment, Rakudo still has many bugs and omissions and reportedly runs
        600 times slower than perl 5. While I'm looking forward to it, it will be some
        time until we can use Perl 6 in production.

        Compiling to Parrot bytecode may be somewhat better than python's or perl 5's
        bytecode, as far as "protection" is concerned, but I wouldn't count on it
        being hard to reverse engineer either.

        Regards,

        Shlomi Fish

        >
        > regards
        > Gabor

        --
        -----------------------------------------------------------------
        Shlomi Fish http://www.shlomifish.org/
        What Makes Software Apps High Quality - http://xrl.us/bkeuk

        God gave us two eyes and ten fingers so we will type five times as much as we
        read.
      • Gabor Szabo
        ... I am sure companies are worried about someone using their code without paying the license fee but I think they are a lot more worried about someone taking
        Message 3 of 6 , Jul 13, 2009
        • 0 Attachment
          On Mon, Jul 13, 2009 at 1:45 PM, Shlomi Fish<shlomif@...> wrote:
          >
          > I think your analogy is more or less valid here, even though I may argue that
          > a single car is not analogous to code that you distribute to customers at a
          > lot of cost.
          >

          > Personally, I think more software companies should trust their customers (like
          > FOSS developers trust their users), and realise that what matters is not how
          > many people violate the licensing terms, but how many of them would have been
          > paying customers:


          I am sure companies are worried about someone using their code without paying
          the license fee but I think they are a lot more worried about someone
          taking their
          code and selling a competitive product.

          Again something that happened to me:

          I published the content of one of my training courses so people can
          read it and one
          of the high-profile training companies copied it and uses it directly
          competing against
          me with a much better marketing department.

          Interestingly I happen to know someone who was a manager in the parent
          company of
          that training company and he said something like
          "copying others material is an industry standard in Israel".
          as if that will make me happier.

          Gabor
        • Shlomi Fish
          ... Yes. ... I assume the licensing terms that the material was made available under did not allow commercial use. In that case, you have the right to press
          Message 4 of 6 , Jul 13, 2009
          • 0 Attachment
            On Monday 13 July 2009 14:07:04 Gabor Szabo wrote:
            > On Mon, Jul 13, 2009 at 1:45 PM, Shlomi Fish<shlomif@...> wrote:
            > > I think your analogy is more or less valid here, even though I may argue
            > > that a single car is not analogous to code that you distribute to
            > > customers at a lot of cost.
            > >
            > >
            > > Personally, I think more software companies should trust their customers
            > > (like FOSS developers trust their users), and realise that what matters
            > > is not how many people violate the licensing terms, but how many of them
            > > would have been paying customers:
            >
            > I am sure companies are worried about someone using their code without
            > paying the license fee but I think they are a lot more worried about
            > someone taking their
            > code and selling a competitive product.
            >

            Yes.

            > Again something that happened to me:
            >
            > I published the content of one of my training courses so people can
            > read it and one
            > of the high-profile training companies copied it and uses it directly
            > competing against
            > me with a much better marketing department.
            >
            > Interestingly I happen to know someone who was a manager in the parent
            > company of
            > that training company and he said something like
            > "copying others material is an industry standard in Israel".
            > as if that will make me happier.
            >

            I assume the licensing terms that the material was made available under did
            not allow commercial use. In that case, you have the right to press charges
            against this company, receive damages and/or prevent them from making further
            use of your material without permission. The law (and the common ethical
            conduct) are on your side.

            Naturally, suing someone is very resource consuming, and so may not be an
            option for you.

            Another option would be for you to make this fact public (with all the
            relevant facts and details) in hope that it will tarnish the other company's
            reputation. Again, this should be thoughtfully considered and may backfire.

            I should note that I made my the material of my "Perl for Newbies" series (
            see http://www.shlomifish.org/lecture/Perl/Newbies/ ) available under the
            Public Domain and I encourage people to make any use of them that they wish. I
            would still appreciate a monetary donation , attribution , or releasing
            derived works to the public too, but I don't necessitate them. But I agree
            with Gabor that he has been done an injustice because it is within his right
            to restrict commercial use of his material, and even some Creative Commons
            licences are doing that.

            Regards,

            Shlomi Fish

            > Gabor
            > _______________________________________________
            > Python-il mailing list
            > Python-il@...
            > http://hamakor.org.il/cgi-bin/mailman/listinfo/python-il

            --
            -----------------------------------------------------------------
            Shlomi Fish http://www.shlomifish.org/
            Stop Using MSIE - http://www.shlomifish.org/no-ie/

            God gave us two eyes and ten fingers so we will type five times as much as we
            read.
          • 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 5 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 6 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.