What's TOTALLY COMPELLING about Ruby over Python?

[Graham Fawcett]

Negative points earned by using 'frickin' and 'kewl'.

But with an earnest answer to your question - I started evaluating
Ruby about two and a half years ago. For me at the time, the "big
deals" in comparison to Python were:

An excellent answer and a great read, Jeffrey. Thanks.

-- Graham

 

[David Garamond]

Ruby is still more closely related to Perl than it is to Python.

I think for many people, it all boils down to this. Whoever hates Perl
will find Python more interesting. Whoever loves Perl, or uses/has used
Perl, will find Ruby more welcoming.

I for one am a Perl programmer. I have tried to use Python as much as I
could for several months but just could not get as productive as I am in
Perl. Hell, I could not even put 'if ... else ...' on the same f*cking
line!

Ruby
uses all of those shortcut expressions that I find terrible, like $_.

Ruby _does_ try hard to be a better Perl. This includes providing $_ and
many other Perl stuffs. However, the more I use Ruby over time, the less
I use those.

What I like about Ruby is that, despite it brings many features from
Perl, it still manages to be pretty clean design-wise. The features are
often layered on top of the OO system (e.g: /.../ is a shortcut for
creating a Regexp object). And they are all optional to use. Surely one
is not forced to use it. But I understand that there are people who just
can't stand the fact that those features _exist_ in the language.

Ruby uses other punctuation marks to mark what different variables,
with name, $name, @name, and @@name all being different. While it's
nice to differentiate between local, global, instance, and class
variables, all of these extra punctuation 'shortcuts' get in the way
of readability.

Ah, but this improves readability for me. Some people might also argue
that all those underscores in Python code reduces readability. And how
many threads are lost for people complaining about having to write
'self.foo' all the time? ;-)

Ruby still has too much shell-script nature inside of it.

Yes. And I love it

in Ruby expression type is command expansion, or `foo`, where foo is a
shell command. (You can also use %x, as in %x{echo "Hello There"}).
Putting `uname -v` in your code will execute the Unix 'uname' command.
The exit status of the command is in the cheerful global variable $?.
As a result, I wonder how well Ruby works as an embedded language.

Not very badly, I think. mod_ruby, eruby, pl-ruby, jruby, ... Though the
last one is nowhere near usable as Jython right now.

(NameSpace::Example::CONST or NameSpace::Example.new). Man, the more
I write, the more I really appreciate the simplicity of Python. We
will do funny things with __underscores__, but even that's pretty
consistent.

And what's not consistent about :: for namespace separator, $ for global
vars, @ for class vars, and so on?

Python also has the nice feature of compiling/caching modules, which
can speed things up. I don't know if Ruby re-evaluates all code every
time you start a Ruby program up, but I haven't really seen an
equivalent to Python's '.pyc' and '.pyo' (optimized, generated when
running with the -O option in Python) files.

This is a purely implementation issue, not the issue with the language
itself. Currently Ruby does not have a VM yet, so it does not have
bytecode compilation. But it will in Ruby 2.0. The current
implementation of Ruby (Ruby 1.x) is admittedly not very fast, but it's
already much faster & efficient than Python for some things (like
creating and destroying objects/classes).

Ruby does have some nice things going for it, and I think that people
looking for a good object oriented Perl would be happy with it.
Personally, I think that Python is more mature, has better design
influences (Modula and ABC instead of Perl and Smalltalk).

Ruby is also largely influenced by LISP.

def mult(n, fact)
n * fact
end

the last statement in an expression is what's returned. You *can* use
a return statement. But it's nice that Python always requires it

This is also one of the thing I hate in Python

 

[Peter Hansen]

Jeffrey P Shell wrote:

[an excellent, lengthy article contrasting Python and Ruby]

Article saved permanently. This is the only good thing to
come out of this thread so far. Thanks Jeffrey!

-Peter

 

[Andrew Dalke]

David Garamond:

Ah, but this improves readability for me. Some people might also argue
that all those underscores in Python code reduces readability. And how
many threads are lost for people complaining about having to write
'self.foo' all the time? ;-)

What if you had your editor expand '@' into 'self.'? (Not something
I would do.)

And how many Ruby threads are lost for people complaining about

Not very badly, I think. mod_ruby, eruby, pl-ruby, jruby, ... Though the
last one is nowhere near usable as Jython right now.

When I looked at Ruby a few years ago, I had concerns about
how its thread system (a platform independent/non-native) system
would interact with, say, POSIX threads or with an in-proc COM
server. I never found out the answer for that.

I also had concerns with its non-ref-count based garbage collection
for C extensions, because the C/Fortran libraries I use most often
for chemistry only pass opaque integer tokens around, and not raw
pointers, so there's no way for Ruby to know when to dealloc
things or what the proper deallocation order would be.

And what's not consistent about :: for namespace separator, $ for global
vars, @ for class vars, and so on?

Python gets away with doing the :: and @ with just a name and
a period.

'x' is local or global
'x.y' is the 'y' thingy in 'x', and 'x' could be a module, a class,
or an instance

So the inconsistency, from a Python view, is that the "get something
from something else" is written in different ways depending on
the source of the data.

The current
implementation of Ruby (Ruby 1.x) is admittedly not very fast, but it's
already much faster & efficient than Python for some things (like
creating and destroying objects/classes).

How is that tested? I hear that new-style classes for Python are
faster than old ones. Still, I decided to test out object creation
on a machine which has an older version of Python and of Ruby
installed.

%python -V
Python 2.2.2
%ruby --version
ruby 1.6.5 (2001-09-08) [i386-freebsd4.4]
%
%cat t.py
class Qwerty:
def __init__(self, name):
self.name = name

for i in xrange(1000000):
Qwerty("shrdlu")

%cat t.rb
class Qwerty
def initialize(name)
@name = name
end
end

for i in 0...1000000
Qwerty.new("shrdlu")
end
%time python t.py
3.303u 0.000s 0:03.42 96.4% 774+1008k 0+0io 0pf+0w
%time ruby t.rb
3.466u 0.185s 0:04.25 85.6% 5+889k 0+0io 0pf+0w
%

I deliberately chose Python code known to be slow.
Here's the faster version

%cat t.py
class Qwerty:
def __init__(self, name):
self.name = name

def main():
for i in xrange(1000000):
Qwerty("shrdlu")

main()
%time python t.py
2.929u 0.000s 0:03.36 86.9% 773+1008k 0+0io 0pf+0w
%

Faster because 'i' is in local namespace (simple offset
lookup in the list of local variables) vs. global namespace
(dictionary lookup). Deliberately chosen because I don't
know if Ruby has similar differences.

Andrew
(e-mail address removed)

 

[Nils Kassube]

A nice feature of Ruby is that exceptions are resumable like in
Smalltalk, ie. you can have a "retry" statement in your exception
handling that allows you to "try again".

http://www.rubycentral.com/book/tut_exceptions.html

 

[Roy Smith]

A nice feature of Ruby is that exceptions are resumable like in
Smalltalk, ie. you can have a "retry" statement in your exception
handling that allows you to "try again".

http://www.rubycentral.com/book/tut_exceptions.html

I suppose this is nice, but does it really give you anything you
couldn't get in a slightly different way by just enclosing the whole try
construct in a loop?

while 1:
try:
do stuff
break
except:
fix the problem

If "do stuff" throws an exception, the "fix the problem" code runs and
then you try "do stuff" again. It even suffers from the same potential
infinite loop problem the Ruby version has

 

[Nils Kassube]

I suppose this is nice, but does it really give you anything you
couldn't get in a slightly different way by just enclosing the whole try
construct in a loop?

You are correct. The exception handling in Python is as powerful as in
Ruby. However, Ruby's way seems more beautiful to me. Another example:
in Python you have to nest multiple try/except statements, in Ruby you
can have multiple rescue blocks. It just looks better. (For my eyes.)

 

[Christos TZOTZIOY Georgiou]

All of the Ruby collections implement a .each method, which is essentially
a version of the Visitor pattern. If I want to do something to every element
in a list or a dict (or any kind of collection,) all I have to do is say
something
like (using Python syntax):

collectObj.each(<method name>)

You can do similar things in Python, just wrap your collection in a
class. Check this module:

http://www.sil-tec.gr/~tzot/python/predicates.py

See the test cases after the line
if __name__ == "main":

Does this work for you? Esp. the do method.

PS I don't believe that the my final test labeled "Tricky" works, but
RSN I'm going to work on it

 

[Christos TZOTZIOY Georgiou]

Erik has been in my killfile forever, from other newsgroups. I even had to
put him back in after letting him out. I thought a year would have been
enough, but apparently not.


So, you're guilty by association. Goodbye!

Brandon,

I have no reason to call you names, and I won't bother pretending to be
a practical psychologist laying out my opinion about your social
interoperability; however, I will give your sense of humour a test

You have reported that you once in a while lose your killfile[1] because
of newsreader changes, "OS" (quotes intended to humour MS Windows)
reinstallations etc. A way to do comparisons between two languages is
to test them on practical matters. So, based on that periodical loss of
killfile, and on your keen-ness of informing your "victimfiles", I have
an idea for you.

Write a program in Python and Ruby that reproduces anytime your killfile
by googling your posts and selecting those containing a combination of
the words "killfile", "killfiling", "goodbye" and possibly "plonk!"
(don't know if you use that one); these are replies to people you
killfiled.
In the process, taste the languages. Request for support in the groups
(disabling temporarily your newly recreated killfile . Join the
communities. Share the experience. Answer yourself your own questions
--and CC the groups in that answer!

I can't talk for Ruby, but I have lived the above for Python (and for a
long time just by lurking in the group; we're different in that, but I
don't imply I'm better than you). Ruby sounds interesting, but Python
has my heart (yes, geeks fall in love with computer languages, just like
with any other human product for which a lot of craftsmanship has been
invested).

Now, after all the sweet talk, I'll show you my true teeth (I'm a faulty
lying human sun of a beach after all) and tell you: "Stop believing
you're a leader and a lone wolf; there can't be two of us"

Cheer up, man. If people disappoint you, don't shut them off your
world; try charming them, for a change.


[1] It was you who reminded me the word "killfile"; I really had
forgotten about it and *plonk* etc, because c.l.py (ok, and a.h.bou)
have been the only ng's I invest time in lately...





....and PS: <me looking at the director>: "was that OK? or did I sound
too hippy? perhaps we should lose the San Francisco background and,
people, somebody stop the Ten Years track, OK??!"

 

[Christos TZOTZIOY Georgiou]

Ten Years track

and I meant Ten Years AFTER.

 

[Christos TZOTZIOY Georgiou]

Just imagine what will happen when every
clp regulars will be in Brandon's kill file...

"Where is everybody?"

 

[Christos TZOTZIOY Georgiou]

Bottom line is that people that uses Python have a better sex life than
those that use other languages.

OK, who added viagra.py in the standard library?