Python vs. Perl, which is better to learn?

[Jason Voegele]

Alex Martelli <aleax at aleax.it> wrote in message news:<kwyA8.694$CN3.28157 at news2.tin.it>...
> Jason Voegele wrote:
>         ...
> > On the other hand, the ability to call functions without parentheses
> > is not so clear-cut.  Some believe that it leads to less readable
> > code.  Others (such as myself) view it as essential for supporting the
> > Uniform Access Principle.  Usually I'll leave the parentheses off of a
> 
> "Properties" do UAP better, and meanwhile you get uniformity at ANOTHER
> level: all methods are also attributes and you can deal with them as
> you deal with other attributes.

[snip Alex's excellent discussion of properties wrt uniform access]

I haven't used any of the new (2.2?) features of Python, so I'm
speaking from a position of ignorance.

Ruby has similar features with attr_accessor and friends, except that
Ruby makes all class/instance variables "private" (note though, that
private in Ruby is somewhat different than private in C++ and Java). 
I presume that your arguments regarding Python's properties also apply
to Ruby's 'attr's?  (Not trying to start a rb vs. py thing here, just
trying to understand).

> > method call if it takes no arguments, which allows me to switch
> > between using a variable and using a method more easily.  I also find
> > it easier to read in such cases.  I find empty parentheses() as you
> > find in C++, Java, and Python rather ugly (a "call" statement in
> > disguise, as it were), although at least in Python and C++ they are
> > actually an overridable operator, whereas in Java they are just
> > gratuitous syntax.
> 
> Yes, you can't take a reference to a method in Java (while you can
> in Python, and also, sort of, in C++, though it's a "method
> pointer" there, and rather unwieldy).  Calling is indeed an OPERATOR,
> while the lack of operator means "a reference to this thingy over
> here".  Now THAT is uniformity: naming something always gets a
> reference to that thing -- if and when you want to DO something
> with that reference, you express that "something".  Properties let
> you control the 'dot-operator' selectively and with very fine grain.

Yes, this is a very useful feature.  The analogous (although not quite
equivalent) technique in Ruby is using Method or Proc objects that
support a "call" method.  "Callable" objects in Ruby are those that
have a "call" method, rather than a () operator.

The Ruby approach requires a little more work to get "a reference to
this thingy over here".  In Python, you do this by simply naming the
thing (x.foo, as opposed to x.foo()).  Ruby's default behavior is to
call the method with that name (x.foo and x.foo() are the same thing).
 To get foo as an object, you must ask for it:  x.method(:foo).  Thus,
x.method(:foo).call is a round-about way of saying x.foo().

> > In addition, I'll leave the parentheses off of function calls that are
> > conceptually similar to keywords.  For example, Ruby's "raise" method
> > (which raises an exception), or an "assert" method from a testing
> > framework, or attr_accessor and friends.
> 
> Given that raise and assert are statements in Python (Ruby is more
> flexible by having them as methods, though Python's design choice
> has its own little pluses too -- interesting tradeoffs), I can hardly
> criticize you for "wanting" them to be in Ruby too:-).

I never expected to be psycho-analyzed by a c.l.py bot. :-)  Cute.

> Actually, it's when a callable HAS arguments that it may be least
> disruptive to allow it to be called without parentheses, just by
> "juxtaposition" to its arguments.  I do admit I love Haskell's
> way of expressing "f a b c", so clean -- no noisy parentheses nor
> commas for the typical case.  Of course, it DOES require the
> "implicit currying" concept, so that e.g. f a may return a function
> that then takes b and returns a function that ... -- delightful,
> but perhaps not all that applicable unless the compiler has some
> strong information about what callable takes what arguments:-).

Yes, several functional languages have these delightful "operations on
relations" kind of features, function composition, etc.  I think
Smalltalk's cascading messages are the closest OO analogue.
 
> For a compiler lacking such knowledge, I opine that unformly
> mandatory parentheses as "call-operator" is probably simplest
> and thus preferable -- though I sympathize with the drive to
> avoid "useless pixels on the screen"[...]

I'll respect that opinion, though I respectfully disagree. :-) 
Personally, I like the Eiffel mechanism the best (read only
attributes, no parens for empty method calls, selective export, etc.).
 Unfortunately, Eiffel is still lacking a "property set" equivalent
(i.e. x.foo = bar), although it has been discussed for an upcoming
version, and methods have only recently become "objectifiable".

> One day I'd really love to co-author a *balanced* comparison
> of Python's and Ruby's pluses and minuses -- "co-author" 'cause
> I'd need to find a partner in crime who admires Python but
> still prefers Ruby, just as I admire Ruby but still prefer
> Python -- and one "into" Ruby's triviae and minutiae as well
> as overall philosophy as much as I'm "into" Python's.  Oh well, one day...

I'd really like to see such a balanced comparison co-authored by
someone as obviously knowledgeable as yourself.  If you're truly
interested, you'll find several very qualified Ruby enthusiasts, that
also know enough Python for the job, on comp.lang.ruby.

Thanks for the (typically) excellent post.

-- 
Jason Voegele
"We believe that we invent symbols. The truth is that they invent us."
    -- Gene Wolfe, The Shadow of the Torturer