What's better about Ruby than Python?

[Alex Martelli]

John J. Lee wrote:
   ...
> I'd never noticed that.  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.

I see somebody else already indicated why this isn't so.


> The differences between Ruby and Python are, in the end, about as far
> from significant as it's possible to be (near as I can tell from

Yes, they're extremely similar languages.

>> Ruby does have some advantages in elementary semantics -- for
>> example, the removal of Python's "lists vs tuples" exceedingly
>> subtle distinction.
> 
> You may be right there.  Guido's comment that tuples are mostly
> mini-objects did clarify this for me, though.

Oh, I'm quite "clear" on the issue, I just think it's a design
error to have tuples in Python, that's all (rather than just an
immutable version of lists for hashing purposes, for example).


>> But mostly the score (as I keep it, with
>> simplicity a big plus and subtle, clever distinctions a notable
>> minus) is against Ruby (e.g., having both closed and half-open
> 
> In the end, though, don't you agree that any such judgement is, from
> the pragmatic point of view, pointless once you realise how similar
> the two languages are?

No, I entirely disagree.  I do have to choose one language or the
other for each given project; I do have to choose which language
to recommend to somebody wanting to learn a new one; etc, etc.

> 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?

Non-linguistic considerations such as the above may also have their
weight, in some case.  But they're not huge ones, either.

>> about undistinguishable to anybody and interchangeable in any
> 
> *in*distinguishable.  Ha!  I found a bug.

You're wrong, see e.g. http://dict.die.net/undistinguishable/ :
the spellings with the initial "u" and "i" are just synonyms.


>> If I had to use Ruby for such a large application, I would
>> try to rely on coding-style restrictions, lots of tests (to
>> be rerun whenever ANYTHING changes -- even what should be
>> totally unrelated...), and the like, to prohibit use of this
>> language feature.  But NOT having the feature in the first
>> place is even better, in my opinion -- just as Python itself
> [...]
> 
> 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

As I see others indicated in responses to you, this is highlighted
and recommended in introductory texts.  So why shouldn't many users
apply such "big guns"?

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

And hopefully this WILL be deprecated in 2.4 (pity that there just
was not enough time and consensus to do it in 2.3, but the BDFL
really liked the concept).  Still, the Python usage you mention
is LESS problematic, in that the influence on some_module is
very explicit -- while altering Object (or whatever) in Ruby is
a way to IMPLICITLY AND HIDDENLY influence EVERY other module.
It's a *covert* channel -- a disaster, in large applications.

Thus, the direct Python equivalent might be

import __builtins__
__builtins__.len = someotherfunction

and THAT usage is very specifically warned against e.g. in
"Python in a Nutshell" -- you CAN do it but SHOULDN'T (again, one
can hope to eventually see it "officially" deprecated...!).


Alex