Hi,

Gabriel Lima wrote:

> The question I am formulating is related to Python (as Python seems to
> be the closest match,
> due to its OOP features, and being both scripting languages), but it is
> not related to whether
> Ruby is better than Pyhon, but rather to the question of if the
> differences really are so great,
> that the switch is worth it.

The answer largely depends on your interests and needs.

> Python has the undeniable advantage of:
> * more libraries.
> * more books (3-4 for Python, one coming up for Ruby).
> * more online documentation.
> * a larger established user base (hey, programming alone is no fun).
> * at least one "killer app" (I am of course talking about Zope).
> * more commercial support (several companies are using Python/JPython
> internally).

On all these counts, Perl has the "undeniable advantage" over Python. (Of
course Perl has long ago transcended the need to cite a "killer app". :-)
But this is 'undeniable advantage" only in the most general sense (with
unspecified weightings and magnitudes), which may or may not be relevant
in many cases (such as your's). And of course we are dealing with moving
targets here. And the more fundamental issue is what is more satisfactory
overall for your purposes and timeframe.

> So, having all of the above present., is Ruby really a "so much" better
> language to the extent
> that it is worth it to make the switch?

For me, Ruby was "enough" better to switch to Ruby, but Python wasn't good
enough to switch from Perl.  For me, the future prospects for Ruby matter
just as much as its present capabilities. I started using NAWK and later
Perl when they were comparatively new and relatively unknown. Even when
the pitiful (by later Perl book standards) Perl 4 book came out, it still
wasn't obvious to most people that Perl was going to be a gigantic
success. (I still use Perl for things that others need to take over.) Part
of the "is is worth it" question has to do with anticipated future returns
on the learning investment, but this is both highly uncertain, and varies
considerably across individual cases.

This (out of date and soon be superseded) excerpt from


http://cseng.aw.com/bookdetail.qry?ISBN=0-201-71089-7&ptype=3369&orurl=&ctype=&catid=&seriesid=&catpage=


is probably the best available general answer that can be given to your
question without knowing much more about your situation.

=============================================================

Programming Ruby: The Pragmatic Programmer's Guide

                    David Thomas and Andrew Hunt

                    Preface


This book is a tutorial and reference for the Ruby programming
language. Use Ruby, and you'll write better code, be more productive,
and enjoy programming more.

These are bold claims, but we think that after reading this book
you'll agree with them. And we have the experience to back up this
belief.

As Pragmatic Programmers we've tried many, many languages in our
search for tools to make our lives easier, for tools to help us do our
jobs better. Until now, though, we'd always been frustrated by the
languages we were using.

Our job is to solve problems, not spoonfeed compilers, so we like
dynamic languages that adapt to us, without arbitrary, rigid rules. We
need clarity so we can communicate using our code. We value
conciseness and the ability to express a requirement in code
accurately and efficiently. The less code we write, the less that can
go wrong. (And our wrists and fingers are thankful, too.)

We want to be as productive as possible, so we want our code to run
the first time; time spent in the debugger is time stolen from the
development clock. It also helps if we can try out code as we edit it;
if you have to wait for a 2-hour make cycle, you may as well be using
punch cards and submitting your work for batch compilation.

We want a language that works at a high level of abstraction. The
higher level the language, the less time we spend translating our
requirements into code.

When we discovered Ruby, we realized that we'd found what we'd been
looking for. More than any other language with which we have worked,
Ruby stays out of your way. You can concentrate on solving the problem
at hand, instead of struggling with compiler and language issues.
That's how it can help you become a better programmer: by giving you
the chance to spend your time creating solutions for your users, not
for the compiler.

Ruby Sparkles

Take a true object-oriented language, such as Smalltalk. Drop the
unfamiliar syntax and move to more conventional, file-based source
code. Now add in a good measure of the flexibility and convenience of
languages such as Python and Perl.

You end up with Ruby.

OO aficionados will find much to like in Ruby: things such as pure
object orientation (everything's an object), metaclasses, closures,
iterators, and ubiquitous heterogeneous collections. Smalltalk users
will feel right at home (and C++ and Java users will feel jealous).

At the same time, Perl and Python wizards will find many of their
favorite features: full regular expression support, tight integration
with the underlying operating system, convenient shortcuts, and
dynamic evaluation.

Ruby is easy to learn. Everyday tasks are simple to code, and once
you've done them, they are easy to maintain and grow. Apparently
difficult things often turn out not to have been difficult after all.
Ruby follows the Principle of Least Surprise---things work the way you
would expect them to, with very few special cases or exceptions. And
that really does make a difference when you're programming. We call
Ruby a transparent language. By that we mean that Ruby doesn't obscure
the solutions you write behind lots of syntax and the need to churn
out reams of support code just to get simple things done. With Ruby
you write programs close to the problem domain. Rather than constantly
mapping your ideas and designs down to the pedestrian level of most
languages, with Ruby you'll find you can express them directly and
express them elegantly. This means you code faster. It also means your
programs stay readable and maintainable.

Using Ruby, we are constantly amazed at how much code we can write in
one sitting, code that works the first time. There are very few syntax
errors, no type violations, and far fewer bugs than usual. This makes
sense: there's less to get wrong. No bothersome semicolons to type
mechanically at the end of each line.  No troublesome type
declarations to keep in sync (especially in separate files). No
unnecessary words just to keep the compiler happy. No error-prone
framework code.

So why learn Ruby? Because we think it will help you program better.
It will help you to focus on the problem at hand, with fewer
distractions. It will make your life easier.

What Kind of Language Is Ruby?

In the old days, the distinction between languages was simple: they
were either compiled, like C or Fortran, or interpreted, like BASIC.
Compiled languages gave you speed and low-level access; interpreted
languages were higher-level but slower.

Times change, and things aren't that simple anymore. Some language
designers have taken to calling their creations ``scripting
languages.'' By this, we guess they mean that their languages are
interpreted and can be used to replace batch files and shell scripts,
orchestrating the behavior of other programs and the underlying
operating system. Perl, TCL, and Python have all been called scripting
languages. What exactly is a scripting language? Frankly we don't know
if it's a distinction worth making. In Ruby, you can access all the
underlying operating system features. You can do the same stuff in
Ruby that you can in Perl or Python, and you can do it more cleanly.
But Ruby is fundamentally different. It is a true programming
language, too, with strong theoretical roots and an elegant,
lightweight syntax. You could hack together a mess of ``scripts'' with
Ruby, but you probably won't. Instead, you'll be more inclined to
engineer a solution, to produce a program than is easy to understand,
simple to maintain, and a piece of cake to extend and reuse in the
future. Although we have used Ruby for scripting jobs, most of the
time we use it as a general-purpose programming language. We've used
it to write GUI applications and middle-tier server processes, and
we're using it to format large parts of this book. Others have used it
for managing server machines and databases. Ruby is serving Web pages,
interfacing to databases and generating dynamic content. People are
writing artificial intelligence and machine learning programs in Ruby,
and at least one person is using it to investigate natural evolution.
Ruby's finding a home as a vehicle for exploratory mathematics. And
people all over the world are using it as a way of gluing together all
their different applications. It truly is a great language for
producing solutions in a wide variety of problem domains.

Is Ruby for Me?

Ruby is not the universal panacea for programmers' problems. There
will always be times when you'll need a particular language: the
environment may dictate it, you may have special libraries you need,
performance concerns, or simply an issue with training. We haven't
given up languages such as Java and C++ entirely (although there are
times when we wish we could).

However, Ruby is probably more applicable than you might think. It is
easy to extend, both from within the language and by linking in
third-party libraries. It is portable across a number of platforms.
It's relatively lightweight and consumes only modest system resources.
And it's easy to learn; we've known people who've put Ruby code into
production systems within a day of picking up drafts of this book.
We've used Ruby to implement parts of an X11 window manager, a task
that's normally considered severe C coding.  Ruby excelled, and helped
us write code in hours that would otherwise have taken days.

Once you get comfortable with Ruby, we think you'll keep coming back
to it as your language of choice.

<SNIP, SNIP, SNIP>
=============================================================

Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)