[Python-il] [hackers-il] Re: [Israel.pm] Perl Vs. Python on Various Points
shlomif at iglu.org.il
Mon Jul 13 13:45:44 IDT 2009
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
> 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
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
> > 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.
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
> 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
> 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.
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
More information about the Python-il