Why would I learn Python over other languages?

[GGarramuno]

"Delaney, Timothy C (Timothy)" <tdelaney at avaya.com> wrote in message news:<mailman.155.1089354925.5135.python-list at python.org>...
> Charif Lakchiri wrote:
> 
> > I have setup up Python on my system and played around a bit with, and
> > I have to admit that it's surprisingly simple and easy to get things
> > done with it. However, in my "quest" for interpreted oo scripting
> > languages, I also came across a language called Ruby. I know it's a
> > lot to ask, but I would really appreciate a few words, no great
> > detail, comparing Python to Ruby from those of you who have
> > experience with both. 
> 

Well, asking something like this is likely to result in flames and
language wars.

Anyway, to answer you...

I have had about 2 years experience with Python and about 1 with Ruby
so far.
Previous to that I have used all the following languages: Basic, TCL,
Perl, C,
C++ over the course of 15 years.  
Ruby has since become my preferred scripting language for home use,
albeit I am still somewhat hesitant to fully recommend it for work. 
Why?  Because albeit I find Ruby's syntactically and semantically
superior to Python, I find its current implementation still lacking in
some areas (performance, mainly).

Ruby is a scripting language that borrows the best features of Python,
Perl and Smalltalk.
Most of the things that make Python great also apply to Ruby.

As for the differences...

History
-------

Ruby is a much newer language than Python, by about 3 or so years.
As such, Ruby is perhaps much closer to the state python1.5 was some
years ago:
a tad of an obscure language, a small and helpful community (some of
them also
coders of the language), a smaller library and documentation and a big
promise for growth.  Just as python in those times, Ruby is going a
big rewrite to become Rite (Ruby2), which still does not have a clear
date of arrival.
Ruby was born in Japan and as such, it is extremely popular there. 
Its
Japanese user community usually dwarves that of python.  The opposite
is true
of python in the US and, most likely, in most Western countries.
>From monitoring the ruby list for over year, I am starting to notice a
clear increase in the number of people trying and asking questions
about Ruby.  The number of posts are still about 1/2 or less of what
the Python newsgroup receives, thou.

Developement
------------
The creator of Ruby is paid by his employer to develop Ruby full-time,
but this is not the case of many of his collaborators.  The Ruby
community still lacks the support of something such as ActiveState or
even of a proper Ruby Foundation.
As such, development on Ruby does seem to move slower.  But, as a
counterpart, the language is more dynamic and is still continuously
improving its syntax, in more creative ways than python, imo.  There
is also less fear of changing things drastically if users request it,
as there is in general less legacy code to keep backwards
compatability with (but this is already changing).

Documentation
-------------
Ruby's introductory documentation "Programming Ruby" is free and
personally I found it much more accessible than most Python docs I
used to learn python from.
While I learnt Ruby in just a day and was able to port one of Damain
Conway's most complex Perl scripts in 3 days, I found myself still
struggling with python after a week (and was also frustrated with its
syntax coming from a Perl background at the time).  I was never able
to easily port any Perl library to Python without a full re-write
(perhaps this is a good thing from most python users' pov).
That being said, Ruby's documentation of its libraries is much worse. 
Partly the reason for this is that some of its documentation was
originally written in Japanese and not all of it has been translated
(albeit the upcoming Ruby1.9 will add over 300 pages of
documentation).
The Ruby community has also not 100% settled on a standarized way of
online documentation of code, as both an old rdoc format and a new ri
format still
remain.


Syntax
------

Unlike Python, Ruby does not rely on whitespace as a syntax delimiter,
but
instead relies on blocks, mostly defined as begin,do/end and {} (for
some stuff both can be used, but for others, you have to use one or
the other.  This helps shape ruby code in a particular way, that is
surprisingly legible, imo).  Some people think this is better and
cleaner to read than python is, albeit if you are a python guy, the
"end" keyword will feel absolutely redundant.

Ruby does not use any underscore methods that python's internals are
fond of (__init__, etc), which in the opinion of many are ugly to
read.

Unlike Python, Ruby's syntax is also more amenable to writing
one-liners, as it allows writing them even when you have conditionals,
and supports an almost identical syntax as Perl (-ne, etc).  Sysadmins
will probably like this better, albeit performance of ruby for most
sysadmin tasks is really far behind perl.

Ruby offers a more flexible syntax than Python, allowing for example
the
ability to call functions without parenthesis.  Ruby also makes it
much easier
to define meta-languages within ruby (something that it is quite
difficult if
not impossible in python).  While Ruby does not adhere to the Perl
mantra of "there's more than one way to do it", it certainly does not
restrict you as much as python in your syntax.  Thus, you can have
constructs in Ruby like:
         a = 1 if x == 1
as well as:
         if x == 1
             a = 1
         end

Ruby also provides support for some often requested language
constructs such as "unless".

Ruby provides built-in regular expressions as objects for string
matching identical to python, without all the r// or backslash mess. 
For matching at least, it also allows using them in a much more
similar way to the ease of use of Perl.
Thus, you can have the simplicity of things like:
     if a =~ /Python/
         puts "Not ruby"
     end
Currently, Ruby's regex also support Perl's special $&, $*, etc.
variables, making it much easier to port Perl's libraries to Ruby than
to Python
(However, in the interest of keeping Ruby readable, these variables
will soon disappear and only their full english counterparts will
remain, making ruby closer to python than to perl in this area).
As the Ruby OO-regex (and class support) shares more than a hint of
python, porting python code to ruby is also very painless.

Unlike Python, Ruby's syntax DOES force (or at least strongly hints
you due to warnings), to follow a certain convention.  Thus, CONSTANTS
are uppercase, Classes and Modules are mixed case and variables are
lowercase, and class instance variables are @lowercase.

Unlike Python, Ruby was also born with blocks and closures from the
start and these features are used to great effect in most Ruby code. 
GUI toolkits, for example, benefit greatly from this, even more so
than in Perl.

Ruby's main printing and string formating mechanism shares
similarities to Python and can actually mimic it almost fully. 
However, Ruby also allows running full expressions within its double
quoted strings with a #{stuff} syntax to print variables and even run
expessions from within quoted strings.  This is extremely much more
powerful and leads to extremely much more readable code than python's
use of %s and similar, imo.  This is by far THE most clever form of a
printf equivalent and improvement I've ever found in any language.

Types
-----
Ruby does not suffer from the mixup that is Tuples and Lists. 
Instead, all
objects in ruby can be frozen to prevent their modification.  Most
people find
this behavior more consistant.
Ruby's integers promote to long integers automatically (fixnum/bignum
in ruby), so there is no need for checking for overflows or similar. 
On the negative side, integer arithmetic is likely slower in Ruby (but
with 64-bit machines this is likely to change).
Ruby's use of ranges is much simpler in syntax than python, albeit a
tad less powerful in one or two minor aspects.
Ruby's string class has fewer methods than in python, by default,
albeit many modules add those as ruby string add-ons.

OO
--

Unlike Python, Ruby was born with OO from its origins.  This shows in
a number
of minor and sometimes not so minor things (that usually have to be
experienced to see the difference):

Class methods in ruby do not require being defined with self
as a parameter, which tends to denote Perl and Python's non-OO
origins.

Ruby changes the self.var notation for just @var.  Albeit looking like
Perl's @var construct, the meaning is QUITE different and Ruby DOES
NOT suffer from Perl's $,@,%,\$,\@,\% mess.

Ruby's class variables are private by default and it provides simple
constructs to create accessors/writers for them.  This is usually
considered more correct OO behavior.

Ruby is in general much more consistant in its use of methods.  While
in python
you may find yourself doing things like:
    type(obj)
    dir(obj)
    len(obj)
Ruby always uses an OO approach for everything, so you would have
a.class(), a.methods(), a.length(), etc.  This makes learning Ruby
much easier and makes the whole language feel much more consistant
overall.

Ruby's OO is based on single inheritance only, but it provides a
method of
mixins similar to Java that allows you to obtain some (but not all) of
the
benefits of multiple inheritance.  Some people find multiple
inheritance to really not belong in scripting languages, while others
find lack of MI a huge drawback.

Ruby supports aliases of methods, which is an extremely powerful
feature, with no easy counterpart in python, afaik.
This allows you both a way to redefine other methods but keep their
behavior
under another method name as well as a way to offer the same
functionality under different names.  As such, ruby standard library
supports for example calling a.size() or a.length() as synonyms.

Unlike Python, Ruby was also born with iterators and continuations
from its origins, and these are also used in their library.  I still
think python's approach to these are pretty ugly to read.

Ruby support private, protected and public constructs for methods,
albeit the meaning is slightly different than in C++.

Ruby supports a very clean exception mechanism in the form of
raise/rescue/else/ensure like Python's
raise/try/except,raise/try/finally, but it also supports a
non-exception way of unwinding the stack in the form of catch/throw
constructs.  This makes it more elegant to exit extremely nested
constructs than python, without having to create dumb exceptions.

Due to some of the above, Ruby's standard library is also much more OO
oriented than python's, in the opinion of many.


GUI Toolkits
------------
Most of the toolkits available in Python are available in Ruby.  The
standard toolkit is Tk, just as in Python, with more or less the same
benefits and drawbacks.
The FOX Toolkit is also heavily used and it is one of the toolkits
with best Ruby support (and comes standard with Windows
distributions).
Support for other toolkits (Qt, FLTK, etc) is also available at pretty
much the same level as for python.

Web
---
Not really my area of expertise here, but Ruby is considered a tad
worse than python overall.
mod-ruby provides the same functionality that mod-python, albeit it is
not as popular.  I've heard mod-ruby may suffer in scalability, but
cannot confirm this myself.
There is nothing quite as good as zope in the Ruby world.
Ruby provides the best XML support of any language, afaik and it does
offer one or two other things that I think could be useful for web
development.

Java
----
While I have not tried it, JRuby seems quite as capable as JPython to
me, but just not as popular.

Threads
-------
Ruby provides portable light threads built-in within the language, but
not for threads provided by the OS.  Currently only unix systems can
easily take advantage of system threads easily.  Many people consider
this a drawback of Ruby and quite important to have for real world
applications and large scale applications that run on windows or need
to be multiplatform.

Unicode
-------
Ruby currently does not provide full support for Unicode, albeit it
does provide support for several other character sets.  Unicode
support is schedule to be done probably for 1.9, or a tad later.

Core
----
Looking at Ruby's C core you will notice one thing.  It is really,
really small compared to python or perl.  It is also much more
readable, if you ask me.
Ruby's C API is extremely consistant with how you use the language as
a user.
Unlike Python, Ruby relies on garbage collection instead of reference
counting and its macros are much simpler than Python's.
Ruby's garbage collector is not that good and as such Python will
currently easily beat it in both performance and memory usage.
Ruby currently cannot be compiled to bytecode, unlike python, which
probably does effect its performance (albeit not as much as I
expected).

Extending/Embedding
-------------------
Embedding Ruby is overall easier than embedding python, but Ruby does
not provide re-entrant interpreters (Python didn't either, at least
some years ago, not sure now).
Extending Ruby with a C library is in general much easier than python
due to the lack of reference counting, mainly.  However, trying to
have ruby use a library that uses multiple inheritance is very
difficult if not impossible.
SWIG support for Ruby is almost as complete as python today.

Performance
-----------
Ruby's performance is usually worse than Python due to garbage
collection, the lack of bytecode and due to the ability of classes to
be modified on the fly.  Python's C code for string handling is also
better.
There is nothing quite like stackless python or psyco yet in the ruby
community.
However, my impression is that ruby is overall a tad faster than
Python for object creation (probably due to the lack of multiple
inheritance).
Of course, all performance issues are rather subjective and vary with
each
version and revision of the languages as well as the task at hand (and
the knowledge of the language, too).

Libraries
---------
Being a newer language, Ruby does not have as many libraries as python
and certainly nowhere near the number of libraries of Perl.
The Ruby community is only now settling on a standard way of
distributing libraries that shares somewhat the simplicity and
elegance of using Perl's CPAN (and actually improves on it in a bunch
of areas), but you will still find most modules being disted today
mainly as zip/gzip files that you need to install running a setup.rb
script.

License
-------
Ruby's licensing is open source (GPL and loose LPGL), but a little bit
of a mess, as portions of Ruby's core code have been borrowed from
other places.
For example, Ruby's regex library is really Perl's so it shares its 
Artistic License (albeit this will be gone in 1.9), instead of Ruby's
license.  I'm no legal expert so I am not sure how tricky this is for
closed source applications (probably not much of an issue).

.... And by now, I re-read the original mail that said "no great
detail".  Sorry.