Python for Perl programmers?

[Alex Martelli]

Chris S. <chrisks at NOSPAM.udel.edu> wrote:
   ...
> I've read that Ruby is actually more akin to Perl than Python. From a

Knowing a lot of Python and a little Ruby, I concur with this
assessment.

> Ruby wiki, "[Matsumoto] chose the name to reflect the language's Perl
> heritage". Granted, Python definitely deserves your attention, but if
> you're a die-hard Perl user, you may also want to take a look at Ruby.

You might want to take a look at Ruby anyway, particularly after a look
at Python, because it's quite instructive to see what they do in similar
ways, and what in very different ways.  In the end, they reach
essentially equivalent power by pretty different routes.  Yes, Ruby does
show some weird aspects of Perl heritage (the ability to use control
characters as variable names, the fact that REs are mixed into the
language rather than elegantly placed into their own module, etc, etc),
but I think they are, mostly, rather minor things.  I don't think any
Perl programmer will choose a language based on whether or not they can
use control-T as a variable name, or whether they have to 'import re' in
modules that will use regular expressions, and the like.

I have already mentioned this in the past, but, let me repeat, since I
think the point is important...: my main reason for preferring Python
_for production code_ is essentially that Python has a strong cultural
bias towards uniformity, while Ruby shares Perl's cultural appreciation
of diversity.  I shudder at the thought of consulting for a project
reveling in diversity, where each programmer does his or her own thing:
that's quite the opposite of how I think a multi-person project should
proceed, with egoless programming, no code ownership, and other such
Extreme Programming values.  (One technical aspect where Ruby shows its
appreciation for "doing your own thing": you can alter the behavior of
builtin objects, for example to ensure that strings will compare equal
in a case-insensitive way; this may of course wreck havoc with libraries
you may be using that do NOT aspect such alteration of a built-in type's
behavior, but meanwhile you DO get to do your own thing to a much larger
extent than in Python, where built-in types can't be changed this way).

If you're just fooling around, or for somebody programming by himself
without much need to communicate with others nor share code, I can well
see that these pro-diversity biases and choices might well be a plus.  I
am more interested in large systems which do require teams of
programmers, good communication, etc, so I stick with Python.  But I
also keep looking for a serious motivation to use Ruby "in production"
in order to get better acquainted with it.

Most important, to me, is that having both languages around afford
maximal opportunity for each to follow a crucial precept: *to thine own
self be true*.  Misguided types who come to this group to whine and
harangue against Python's _design principles_ (most often, ones
connected to the cultural bias towards uniformity) should just move to
Ruby and stop whining here -- they'd be happier, and so would we.  If
there are similar whiners on Ruby lists complaining about Ruby's embrace
of vast diversity, they might, conversely, be happier with Python.

Rather than trying to remove any real choice, by pushing every language
towards being the same as each other, it's MUCH more clever to accept
that each language (if well designed) stems from a certain set of design
principles, and strive to recognize them: if you like the underlying
principles, you may love the language, if it embodies them well; if you
loathe the principles, use another language -- the better the language
embodies those principles you loathe, the worse off you'll be in using
that language!-).  Python is quite up front about its design principles;
just fire up any interactive Python interpreter and type at the prompt:

   >>> import this


Alex