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

Gabor Szabo szabgab at gmail.com
Mon Jul 13 12:56:55 IDT 2009

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 at iglu.org.il> 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.

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.

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.


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

More information about the Python-il mailing list