Perl Vs Python

Derek Thomson dthomson at
Thu Feb 27 22:57:49 CET 2003

Bo M. Maryniuck wrote:
> On Thursday 27 February 2003 14:35, Derek Thomson wrote:
>>I read other's Perl code, and people read mine with no problem.
> I read pure i386 Assembler too. So what?

Sigh. You said you couldn't read your Perl code one year later, and 
implied that this was the fault of the language. It is not, it's a 
problem with your code.

>>Rubbish. I suspect you're just parroting something you've read somewhere.
> Are you are troll (tongue)? 

No, I just know both languages, therefore I know what I'm talking about.

> Perl OO is strange if you came from C++ or Java or 
> Python world. 

No, it isn't. It wasn't to me, or anyone else that I know.

> Question: what diferent between Perl 6 and Perl 5?
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 
> If by "object oriented" you mean force people to only do object-orientation, 
> then no, Perl is not object-oriented. But if you think object-oriented stuff 
> is cool in its place, then definitely Perl is "object-oriented". When Perl 5 
> came out, I basically sat down and said this is my first chance and my last 
> chance to do it over right. So what are all the buzzwords I want to be 
> compliant with? The sub-buzzwords under "object-oriented" were very important 
> to me.
>   -- Larry Wall
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 

What does this demonstrate? Only that Perl is multi-paradigmatic.

>>For a start, compilation != encryption. 

> Who talking about encryption? I just want to provide a 
> bytecode, nothing more.

You want to hide your intellectual property from the customer. You've 
suggested bytecode, but that simply isn't going to be good enough. The 
only way is encryption of some kind.

>>you have to accept that the only way to prevent the user "stealing" your
>>IP is through contracts and licenses. 
> *Teoretically* yes. Can you elaborate your _practical_ experience here? It 
> would be nice (since you like a FACTS).

It's fairly simple logic: In the end, anyone can get your IP as you just 
*gave* it to them! Legal barriers against such theft are the only way in 
the end. Why do you think all software comes with licenses that forbid 
such theft? If compiling were perfect for protection, that wouldn't be 
needed. Sure, obfuscation (like shipping only the bytecode), may stop 
the casual reader, but if you've got something worth stealing then 
obviously the tiny bit of effort required to read it is worth putting in.

Only ignorant managers think that "compiling" somehow magically 
"encrypts" the source so that their IP is protected, and I have lots of 
practical experience getting the idea that this is idiotic through their 
skulls ...

>>Secondly, you *can* do this for Perl. You use the B::Bytecode backend
>>plugin to generate byte code for any given sample of Perl code. You can
>>also "freeze" the Perl process after it's finished compiling your
>>source, and ship that executable.
> Cool. Thank you. Probably I missed it since I write much more in Python and 
> porting the rest from the Perl to the Python. (-:

It does help to know what you're talking about before opening your mouth ...

>>I could construct obfuscated examples in Python if I so desired.
> But even here it is much more readable (if you know LISP), than Perl's one:

No, it isn't. But that *is* a pretty cool example of unreadable Python.

>>As for the 100 line limit, I have no such problem, and I've never met
>>any capable programmer who did. I use it for "big applications", and
>>there are many examples of such things, so your argument is provably
> Well, you *can* write anything in Perl, sure. Probably I explain incorrectly 
> what I meant. We had write lots of really big software (like Internet Banking 
> with card authentication etc) in Perl. But I would not like to repeat it 
> again. Just to quickly understand a code what it means, you should spent much 
> more time. If you like flamebait, like "$foo vs. $bar" then you'll always 
> answer "Rules $your_favorite, suxx $all_else", but then I pass. If you like 
> "Everything is cool", then I think you can write your "very-cool-big-project" 
> even on Bourne Shell so flag in your hands.

You were saying it doesn't work, based on your experience, and you're 
doing it again. Just because you failed, doesn't mean everyone else has. 
I could just as easily say, "We had written lots of [big] software (like 
[example]) in Python. But I would not like to repeat it again". This is 
almost content-free, and says more about the author than the tool ...

If you want to criticize, do so sensibly. You're just parroting 
arguments you've seen elsewhere. If you want to promote Python, don't do 
this, as any Perl programmer seeing this rubbish is going to roll their 
eyes, sigh loudly, and assume Python advocates are just clueless. That 
doesn't do Python any good.


More information about the Python-list mailing list