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

Shlomi Fish shlomif at iglu.org.il
Mon Jul 13 15:47:48 IDT 2009


On Monday 13 July 2009 15:12:16 Tal Einat wrote:
> On Mon, Jul 13, 2009 at 12:57 PM, Shlomi Fish wrote:
> > On Monday 13 July 2009 12:00:23 Tal Einat wrote:
> >> > 1. Syntax as an Indicative of What the Language is Doing:
> >> > ---------------------------------------------------------
> >> > I said I happen to like it because the extra characters convey
> >> > meaning.
> >>
> >> Perl has very few built-in types; I recall numbers, strings, arrays,
> >> hashes and functions. When you need to use anything else you are
> >> forced to use references, which are indistinguishable from numbers and
> >> require "casting" their targets' values back to their actual type.
> >
> > References are not numbers. They are different types of scalars. You can
> > tell them apart using perldoc -f ref . You may be able to add a reference
> > to a number, without a lot of meaning, or perform other arithmetic
> > operations, but it's not encouraged.
>
> My point here was that because references are scalars like numbers and
> strings, and references are used quite often, knowing that something
> is a scalar means that it is either a "simple" scalar (number, string,
> undef) or a reference (which can point to anything), so it isn't
> obvious what type of underlying data it represents. My experience with
> Perl found me using references very often, which made the sigils less
> informative and more of a burden.

I see. Well, you can tell what a reference is by how it is used. ->[], ->{}, -
>(), ->method() , etc. are all different. It will be better in Perl 6, where 
one can pass non-scalar variables (@array, %hash, etc.) to functions by 
reference, as well as call methods on them directly. Hopefully, we'll see some 
of this in perl 5 too.

>
> >> In Python every class defines its own
> >> comparison methods (if relevant), which Python uses when evaluating
> >> "==" and friends. I can use "==" and ">=" and ">" to compare various
> >> types of containers, such as lists, sets, tuples and dicts, and these
> >> comparisons are simple and obvious. Besides making the code clean and
> >> readable, things like this make learning Python less tedious.
> >
> > Can I also overload the meaning of these for my own containers? This may
> > cause unexpected results. This is also the case for Perl with
> > overloading.
>
> Yes, you can. However, doing so for non-trivial comparisons is highly
> discouraged.
>
> The main point is that the comparison operators simply work for all of
> the built-in classes as well as those in the standard library.
> Normally you doesn't really have to think about such issues at all
> since the normal comparison operators just do what you would expect.
>

I see.

> >> > 4. Hiding Code
> >>
> >> Usually you just don't want someone to have your original version of
> >> the code, so they don't copy/paste and develop their own product based
> >> on your code.
> >
> > Well, Richard M. Stallman and other free software zealots will disagree
> > with you on this. ;-) Even Python itself is distributed along with the
> > original version of the code, so other people can copy/paste and develop
> > their own product based on the code. Its licence even permits changing
> > the licence of the code, including making it proprietary.
>
> I should have added "excluding open-source software" or something
> before that... :)
>

My point was that even if you are distributing non-FOSS software (which is 
within your rights), you should still not depend on hiding your source code 
(especially in language that don't easily allow it) as a way of protecting it. 
Like I said, it's fig-leaf protection at best.

> >> For this purpose obfuscation and/or compiling to
> >> byte-code are enough.
> >
> > You may be right. However, I was under the impression that my
> > conversation partner wanted even better protection.
>
> That is hard to achieve with any language! There are many decompilers
> for C/C++ which do a pretty good job even on highly optimized code,
> not just Java. 

Really? I'm surprised that the C/C++ decompilers are so advanced. I expected 
the current state of the art to be less than that.

> The only way to ensure someone doesn't know what your
> software is doing is to not have the software run on his computer.
>

Right.

> >> (Obligatory: Writing in Perl is all the obfuscation one would ever need
> >> ;)
> >
> > That's an old joke and was never particularly funny or true.
>
> Actually I was trying to have a serious conversation, and just
> mentioned the usual trolling with a wink to show that I'm not like
> that. No hard feelings I hope?
>

No, none. But next time try to be more explicit, or alternatively not throw 
oil into the fire at all.

Regards,

	Shlomi Fish


> - Tal
> _______________________________________________
> Python-il mailing list
> Python-il at hamakor.org.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.


More information about the Python-il mailing list