What's better about Ruby than Python?

[Andrew Dalke]

John J. Lee
> Greg Ewing has pointed out a similar trivial
> wart: brackets and backslashes to get multiple-line statements are
> superfluous in Python -- you could just as well have had:
>
> for thing in things:
>     some_incredibly_long_name_so_that_i_can_reach_the_end_of_this =
>       line
>
> where the indentation of 'line' indicates line continuation.

Hmm. Start with

    for a in some, incredibly, long, list, so, it, hides, the, end,:
        qwerty_etaoin_shrdlu_glub_glub()
        g()

Drop the colon one line and it would then be legal to write

    for a in some, incredibly, long, list, so, it, hides, the, end,
        qwerty_etaoin_shrdlu_glub_glub():
        g()

As it is now, you'll have to write

    for a in (some, incredibly, long, list, so, it, hides, the, end,
        qwerty_etaoin_shrdlu_glub_glub()):
        g()

or perhaps the less recommended

    for a in some, incredibly, long, list, so, it, hides, the, end, \
        qwerty_etaoin_shrdlu_glub_glub():
        g()

Both provide a little more clue that the expression goes on
into the next line.

Not really a counterpoint, just an observation.

> the two languages are?  If somebody sneakily switched Python and Ruby
> in the middle of the night (so that suddenly many more people use
> Ruby, and much more code was written in Ruby than in Python), you'd
> stick with Ruby, wouldn't you?

I was in a field, bioinformatics, dominated by Perl code.  (It
still is.)  But I decided Python was better in various ways - easier
to read, easier to build larger data structures, and easier for
non-software developers (scientists) to use.

A few years ago I looked at Ruby.  I think my criteria for
selecting Python over Perl is still true for Python over Ruby,
in that it has too many special characters (like @ and the
built-in regexpes), features (like continuations and code
blocks) which are hard to explain well (I didn't understand
continuations until the Houston IPC), and 'best practices'
(like modifying base classes like strings and numbers)
which aren't appropriate for large-scale software
development.

So the answer would likely still be yes.

> I mostly agree, but I think you could be accused of spreading FUD
> about this.  Does anybody *really* choose to alter string-comparison
> semantics under everybody else's nose in Ruby??  That would be like
> doing

Good question, since I repeated it above.

In the into to Ruby docs (or the book?) it mentions that there
are no functions in Ruby, only methods, and that when you
wrote something which looks like a function it's really a
private method of the base Object.  Eg, it does change
methods of the fundamental base class.

(I took it to mean that Ruby's claim to be unrepentantly OO
was overly strong.)

I don't have any experience programming Ruby to know
what people do for large projects.  I will point out that
the Ruby book in one of the first few chapters says:

http://www.rubycentral.com/book/tut_classes.html
> In Ruby, classes are never closed: you can always add
> methods to an existing class. This applies to the classes
> you write as well as the standard, built-in classes. All
> you have to do is open up a class definition for an
> existing class, and the new contents you specify will
> be added to whatever's there.

and later on
http://www.rubycentral.com/book/ospace.html
> You can add code to a running process. You can
> redefine methods on the fly, change their scope from
> public to private, and so on. You can even alter basic
> types, such as Class and Object.
>
> Once you get used to this flexibility, it is hard to go
> back to a static language such as C++, or even to
> a half-static language such as Java.

and I found a tutorial showing how to do the same thing
http://www.math.hokudai.ac.jp/~gotoken/ruby/ruby-uguide/uguide14.html
> In subclass, we get changing behavior of the instances
> by redefine the superclass methods.

(It appears this is a translation from a Japanese tutorial.)

Both are in introductory material, and neither make a
suggestion about its inappropriateness for anything other
than debugging.

> import some_module
>
> def evil_replacement_function(): return blah()
>
> some_module.important_function = evil_replacement_function
>
>
> in Python, wouldn't it?

And that is frowned upon, and as I recall there's some
thought to preventing that in "Python 3.0" for performance
reasons.  Though I've needed to patch code that way.
(It may be that I misheard too.)

It isn't talked about in any of the introductory materials
for Python that I recall reading.

                    Andrew
                    dalke at dalkescientific.com