Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > How does Ruby compare to Python?? How good is DESIGN of Ruby compared to Python?

Reply
Thread Tools

How does Ruby compare to Python?? How good is DESIGN of Ruby compared to Python?

 
 
Christian Seberino
Guest
Posts: n/a
 
      02-24-2004
How does Ruby compare to Python?? How good is DESIGN of Ruby compared to Python?

Python's design is godly. I'm wondering if Ruby's is godly too.

I've heard it has solid OOP design but then I've also heard there are

lots of weird ways to do some things kinda like Perl which is bad for me.

Any other ideas?

Thanks!

Chris
 
Reply With Quote
 
 
 
 
Greg Ewing (using news.cis.dfn.de)
Guest
Posts: n/a
 
      02-25-2004
Christian Seberino wrote:
> Python's design is godly. I'm wondering if Ruby's is godly too.


Actually, Python's design is Guidoly, which seems to be
almost as good in practice.

As for Ruby -- if it is, Japanese gods seem to have somewhat
different tastes in language design.

Personally I much prefer Python. You'll probably get the same
answer from most people here, since this is a Python newsgroup...

> I've heard it has solid OOP design


It's more rigidly OO in the sense that there are no stand-alone
functions, only methods. But that's just a surface issue. As far
as I can see, Python's foundation is as solidly OO as anything
can get, no less so than Ruby's.

> but then I've also heard there are
> lots of weird ways to do some things kinda like Perl which is bad for me.


Ruby code is liberally sprinkled with @-signs, which tends to
make it look slightly Perl-ish. But again that's a surface
issue, and Ruby is really no more like Perl than Python is.

Some areas of real, important differences I can see are:

* Ruby makes heavy use of passing code blocks around as
parameters, to implement iteration constructs and so forth.
Ruby is very much like Smalltalk in this respect. Python
uses a different mechanism (the iteration protocol) to achieve
these things. Python's way is both more and less powerful
than Ruby's. Ruby makes it easy to define new control
structures which look just like the built-in ones, which
you can't do with Python. On the other hand, Python has
its amazingly powerful generators, for which there is no
direct equivalent in Ruby.

* In Python, functions are first-class, and
methods are implemented in terms of functions. In Ruby,
methods are the fundamental concept, and there are no
first-class functions. The result is that Python lets
you obtain a bound method from an object and use it like
any other function. You can't do that in Ruby. You can
get a method object in Ruby, but you can't call it using
normal calling syntax.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

 
Reply With Quote
 
 
 
 
Joe Mason
Guest
Posts: n/a
 
      02-25-2004
In article <c1h1sb$1it26i$(E-Mail Removed)-berlin.de>, Greg Ewing (using news.cis.dfn.de) wrote:
> * Ruby makes heavy use of passing code blocks around as
> parameters, to implement iteration constructs and so forth.
> Ruby is very much like Smalltalk in this respect. Python
> uses a different mechanism (the iteration protocol) to achieve
> these things. Python's way is both more and less powerful
> than Ruby's. Ruby makes it easy to define new control
> structures which look just like the built-in ones, which
> you can't do with Python. On the other hand, Python has
> its amazingly powerful generators, for which there is no
> direct equivalent in Ruby.


Not built in, but you can implement them in Ruby using continuations
pretty easily. See http://www.rubygarden.org/ruby?RubyFromPython for an
example. The only problem I can see is maybe performance issues, but
the performance characteristics of the languages are pretty different
apart from that, I'd assume.

> * In Python, functions are first-class, and
> methods are implemented in terms of functions. In Ruby,
> methods are the fundamental concept, and there are no
> first-class functions. The result is that Python lets
> you obtain a bound method from an object and use it like
> any other function. You can't do that in Ruby. You can
> get a method object in Ruby, but you can't call it using
> normal calling syntax.


I don't see the distinction. "normal calling syntax" in ruby involves
an object, so "unbound function" isn't a meaningful concept. I mean, if
you get a method the begins with the self parameter, you still need an
object to call it, right? Even if you're calling it as "foo(obj,
params)" instead of "obj.foo(params)". I don't see what the ability to
use the other syntax gets you, except the ability to pass functions
around independantly of objects, which I'm pretty sure you can do with
methods in Ruby anyway.

Joe
 
Reply With Quote
 
MetalOne
Guest
Posts: n/a
 
      02-25-2004
Ruby is easy to learn.
I suggest downloading it.
The distribution comes with ProgrammingRuby.chm which is the online
version of the ProgrammingRuby book.
You can read most of what you need in a couple days.
Then decide for yourself.

Ruby is a fine language, but the community is smaller, the bindings to
external libraries are smaller and the number of extra packages are
smaller.
 
Reply With Quote
 
Dave Brueck
Guest
Posts: n/a
 
      02-25-2004
Joe wrote:
> > * In Python, functions are first-class, and
> > methods are implemented in terms of functions. In Ruby,
> > methods are the fundamental concept, and there are no
> > first-class functions. The result is that Python lets
> > you obtain a bound method from an object and use it like
> > any other function. You can't do that in Ruby. You can
> > get a method object in Ruby, but you can't call it using
> > normal calling syntax.

>
> I don't see the distinction. "normal calling syntax" in ruby involves
> an object, so "unbound function" isn't a meaningful concept. I mean, if
> you get a method the begins with the self parameter, you still need an
> object to call it, right?


No - that's the difference between a bound and unbound method (see below).

> Even if you're calling it as "foo(obj,
> params)" instead of "obj.foo(params)". I don't see what the ability to
> use the other syntax gets you, except the ability to pass functions
> around independantly of objects, which I'm pretty sure you can do with
> methods in Ruby anyway.


As for whether or not Ruby supports this, I'm in the don't-know-don't-care
camp, but to clarify: a bound method "knows" which object instance it belongs
to. Given:

def someFunc(callback):
print callback(5,6)

def functionCallback(a, b):
return a + b

class Foo:
def methodCallback(self, a, b):
return a * b

then both these work:

someFunc(functionCallback)
f = Foo()
someFunc(f.methodCallback)

This is pretty darn useful and IMO quite Pythonic: the creator of the function
and the creator of the callback have to agree on only the most minimal set of
details - just those relating to the calling interface - leaving completely
open any implementation details.

-Dave


 
Reply With Quote
 
Lothar Scholz
Guest
Posts: n/a
 
      02-25-2004
http://www.velocityreviews.com/forums/(E-Mail Removed) (Christian Seberino) wrote in message news:<(E-Mail Removed). com>...
> How does Ruby compare to Python?? How good is DESIGN of Ruby compared to Python?
>
> Python's design is godly. I'm wondering if Ruby's is godly too.
>
> I've heard it has solid OOP design but then I've also heard there are
>
> lots of weird ways to do some things kinda like Perl which is bad for me.
>


At least the design of the Ruby implementation is very very bad.

But you should use google to find more answers to your frequently asked question.
 
Reply With Quote
 
Joe Mason
Guest
Posts: n/a
 
      02-25-2004
In article <(E-Mail Removed)>, Dave Brueck wrote:
> def someFunc(callback):
> print callback(5,6)
>
> def functionCallback(a, b):
> return a + b
>
> class Foo:
> def methodCallback(self, a, b):
> return a * b
>
> then both these work:
>
> someFunc(functionCallback)
> f = Foo()
> someFunc(f.methodCallback)
>
> This is pretty darn useful and IMO quite Pythonic: the creator of the function
> and the creator of the callback have to agree on only the most minimal set of
> details - just those relating to the calling interface - leaving completely
> open any implementation details.


I still don't see how this is notable. Seems perfectly straightforward to
me - I'd just assume that's how it worked except in C++, about which I
never assume anything.

A better example of buond vs. unbound methods is this:

def boundFunc(callback):
print callback(5, 6)

def unboundFunc(obj, callback):
print callback(obj, 5, 6)

def functionCallback(a, b):
return a + b

class Foo:
def methodCallback(self, a, b):
return a * b + self.c
def setc(self, c):
self.c = c

>>> boundFunc(functionCallback)

11
>>> f = Foo()
>>> f.setc(3)
>>> boundFunc(f.methodCallback)

33
>>> unboundFunc(f, Foo.methodCallback)

33

For anyone who does care, the Ruby version is

def boundFunc(callback)
puts callback.call(5, 6)
end

def unboundFunc(obj, callback)
callback.bind(obj).call(5, 6)
end

def functionCallback(a, b)
return a + b
end

class Foo
def methodCallback(a, b)
return a * b + @c
end
def setc(c)
@c = c
end
end

> boundFunc(method(:functionCallback))

11
=> nil
> f = Foo.new

=> #<Foo:0x403119dc>
> f.setc(3)

=> 3
> boundFunc(f.method(:methodCallback))

33
=> nil
> unboundFunc(f, Foo.instance_method(:methodCallback))

=> 33

It's a little more cumbersome to manipulate functions because of the
extra calls to "call" and "bind", because "f.methodCallback" actually
calls the method with no params instead of returning a reference to it.
This is one of the things I dislike about Ruby, but it's not like
unbound methods are missing from the language.

(I was wrong when I said "unbound method" was a concept that had no
meaning to Ruby - it even had a "bind" method to support them. Didn't
know about that until I looked it up just now.)

Joe
 
Reply With Quote
 
John Roth
Guest
Posts: n/a
 
      02-25-2004

"Joe Mason" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In article <c1h1sb$1it26i$(E-Mail Removed)-berlin.de>, Greg Ewing

(using news.cis.dfn.de) wrote:
>
> > * In Python, functions are first-class, and
> > methods are implemented in terms of functions. In Ruby,
> > methods are the fundamental concept, and there are no
> > first-class functions. The result is that Python lets
> > you obtain a bound method from an object and use it like
> > any other function. You can't do that in Ruby. You can
> > get a method object in Ruby, but you can't call it using
> > normal calling syntax.

>
> I don't see the distinction. "normal calling syntax" in ruby involves
> an object, so "unbound function" isn't a meaningful concept. I mean, if
> you get a method the begins with the self parameter, you still need an
> object to call it, right? Even if you're calling it as "foo(obj,
> params)" instead of "obj.foo(params)". I don't see what the ability to
> use the other syntax gets you, except the ability to pass functions
> around independantly of objects, which I'm pretty sure you can do with
> methods in Ruby anyway.


I think you've missed the point here. Python has a concept
of a "callable," that is, some object that can be called. Bound
methods are useful precisely because they carry their instance
around with them and also because they look exactly like any
other callable; there is no special syntax that is required either
to create one or to invoke it.

Unbound methods, on the other hand, require the caller to provide
the instance explicitly which limits their usefulness quite a bit.

John Roth
>
> Joe



 
Reply With Quote
 
Cameron Laird
Guest
Posts: n/a
 
      02-25-2004
In article <c1h1sb$1it26i$(E-Mail Removed)-berlin.de>,
Greg Ewing (using news.cis.dfn.de) <(E-Mail Removed)> wrote:
.
[much good counsel]
.
.
>Ruby code is liberally sprinkled with @-signs, which tends to
>make it look slightly Perl-ish. But again that's a surface
>issue, and Ruby is really no more like Perl than Python is.

.
.
.
While I'm all in favor of distinguishing superficial from
fundamental characteristics, I think the last sentence
above is misleading. Ruby is a direct descendant from
Perl, I'm sure; I thought I had the word from Matz himself
that he deliberately modeled a great deal of Ruby on Perl
(and Smalltalk, of course). Although I can't find the
passage now, I'm confident enough to repeat it here. If
necessary, I expect we can confirm the language's parentage.

If you're saying that good Ruby style often differs from
good Perl 5 style, I heartily agree.
--

Cameron Laird <(E-Mail Removed)>
Business: http://www.Phaseit.net
 
Reply With Quote
 
John Roth
Guest
Posts: n/a
 
      02-25-2004
"Cameron Laird" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In article <c1h1sb$1it26i$(E-Mail Removed)-berlin.de>,
> Greg Ewing (using news.cis.dfn.de) <(E-Mail Removed)> wrote:
> .
> [much good counsel]
> .
> .
> >Ruby code is liberally sprinkled with @-signs, which tends to
> >make it look slightly Perl-ish. But again that's a surface
> >issue, and Ruby is really no more like Perl than Python is.

> .
> .
> .
> While I'm all in favor of distinguishing superficial from
> fundamental characteristics, I think the last sentence
> above is misleading. Ruby is a direct descendant from
> Perl, I'm sure; I thought I had the word from Matz himself
> that he deliberately modeled a great deal of Ruby on Perl
> (and Smalltalk, of course). Although I can't find the
> passage now, I'm confident enough to repeat it here. If
> necessary, I expect we can confirm the language's parentage.


To quote Matz's preface in the pickaxe book:

[begin quote]
I wanted a language more powerful than Perl, and more
object-oriented than Python.

Then, I remembered my old dream, and decided to design my
own language. At first I was just toying around with it at work.
But gradually it grew into a tool good enough to replace Perl.
[end quote]

To try to put it into the Perl lineage misses the point that,
for Matz, being object oriented was a primary goal, and while
Perl is a lot of things, object oriented isn't one of them.

The "funny characters" in Perl are type indicators, in
Ruby they are namespace controls. My personal opinion
(which I suspect isn't shared by very many Pythonistias)
is that Python would be improved by requiring explicit
access to the module and built-in namespaces, rather than
the default searches it uses now. To make that work, of
course, would require editor/ide support.

John Roth
> --
>
> Cameron Laird <(E-Mail Removed)>
> Business: http://www.Phaseit.net



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
A good Ruby book and a good Ruby blog vasudevram Ruby 0 04-15-2007 06:27 PM
Good results with Oly 4/3rds compared to Canon EF lenses? Paul D. Sullivan Digital Photography 26 01-27-2007 01:50 AM
How slow could ruby be compared to Python or Perl? sullivanz.pku@gmail.com Ruby 19 04-10-2006 07:44 PM
RE: Is Perl *that* good? (was: How's ruby compare to it older brother python) jwsacksteder@ramprecision.com Python 22 05-11-2004 05:17 PM



Advertisments