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

[Christian Seberino]

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

[Greg Ewing (using news.cis.dfn.de)]

Re: How does Ruby compare to Python?? How good is DESIGN of Rubycompared to Python?

Christian Seberino wrote:[color=blue]
> Python's design is godly. I'm wondering if Ruby's is godly too.[/color]

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...
[color=blue]
> I've heard it has solid OOP design[/color]

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.
[color=blue]
> but then I've also heard there are
> lots of weird ways to do some things kinda like Perl which is bad for me.[/color]

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

[Joe Mason]

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

In article <c1h1sb$1it26i$ 1@ID-169208.news.uni-berlin.de>, Greg Ewing (using news.cis.dfn.de ) wrote:[color=blue]
> * 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.[/color]

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.
[color=blue]
> * 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.[/color]

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

[MetalOne]

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

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.

[Dave Brueck]

Re: How does Ruby compare to Python?? How good is DESIGN ofRubycompared to Python?

Joe wrote:[color=blue][color=green]
> > * 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.[/color]
>
> 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?[/color]

No - that's the difference between a bound and unbound method (see below).
[color=blue]
> 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.[/color]

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(callba ck):
print callback(5,6)

def functionCallbac k(a, b):
return a + b

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

then both these work:

someFunc(functi onCallback)
f = Foo()
someFunc(f.meth odCallback)

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

[Lothar Scholz]

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

seberino@spawar .navy.mil (Christian Seberino) wrote in message news:<bf23f78f. 0402241443.678b f6c8@posting.go ogle.com>...[color=blue]
> 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.
>[/color]

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.

[Joe Mason]

Re: How does Ruby compare to Python?? How good is DESIGN of Rubycompared to Python?

In article <mailman.100.10 77717447.8594.p ython-list@python.org >, Dave Brueck wrote:[color=blue]
> def someFunc(callba ck):
> print callback(5,6)
>
> def functionCallbac k(a, b):
> return a + b
>
> class Foo:
> def methodCallback( self, a, b):
> return a * b
>
> then both these work:
>
> someFunc(functi onCallback)
> f = Foo()
> someFunc(f.meth odCallback)
>
> 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.[/color]

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(callb ack):
print callback(5, 6)

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

def functionCallbac k(a, b):
return a + b

class Foo:
def methodCallback( self, a, b):
return a * b + self.c
def setc(self, c):
self.c = c
[color=blue][color=green][color=darkred]
>>> boundFunc(funct ionCallback)[/color][/color][/color]
11[color=blue][color=green][color=darkred]
>>> f = Foo()
>>> f.setc(3)
>>> boundFunc(f.met hodCallback)[/color][/color][/color]
33[color=blue][color=green][color=darkred]
>>> unboundFunc(f, Foo.methodCallb ack)[/color][/color][/color]
33

For anyone who does care, the Ruby version is

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

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

def functionCallbac k(a, b)
return a + b
end

class Foo
def methodCallback( a, b)
return a * b + @c
end
def setc(c)
@c = c
end
end
[color=blue]
> boundFunc(metho d(:functionCall back))[/color]
11
=> nil[color=blue]
> f = Foo.new[/color]
=> #<Foo:0x403119d c>[color=blue]
> f.setc(3)[/color]
=> 3[color=blue]
> boundFunc(f.met hod(:methodCall back))[/color]
33
=> nil[color=blue]
> unboundFunc(f, Foo.instance_me thod(:methodCal lback))[/color]
=> 33

It's a little more cumbersome to manipulate functions because of the
extra calls to "call" and "bind", because "f.methodCallba ck" 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

[Cameron Laird]

Re: How does Ruby compare to Python?? How good is DESIGN of Rubycompared to Python?

In article <c1h1sb$1it26i$ 1@ID-169208.news.uni-berlin.de>,
Greg Ewing (using news.cis.dfn.de ) <wmwd2zz02@snea kemail.com> wrote:

[John Roth]

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


"Joe Mason" <joe@notcharles .ca> wrote in message
news:slrnc3ob0q .i6n.joe@gate.n otcharles.ca...[color=blue]
> In article <c1h1sb$1it26i$ 1@ID-169208.news.uni-berlin.de>, Greg Ewing[/color]
(using news.cis.dfn.de ) wrote:[color=blue]
>[color=green]
> > * 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.[/color]
>
> 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.[/color]

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[color=blue]
>
> Joe[/color]

[John Roth]

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

"Cameron Laird" <claird@lairds. com> wrote in message
news:103qa53taj uhfdb@corp.supe rnews.com...[color=blue]
> In article <c1h1sb$1it26i$ 1@ID-169208.news.uni-berlin.de>,
> Greg Ewing (using news.cis.dfn.de ) <wmwd2zz02@snea kemail.com> wrote:
> .
> [much good counsel]
> .
> .[color=green]
> >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.[/color]
> .
> .
> .
> 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.[/color]

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[color=blue]
> --
>
> Cameron Laird <claird@phaseit .net>
> Business: http://www.Phaseit.net[/color]

[Stephen Horne]

Re: How does Ruby compare to Python?? How good is DESIGN of Rubycompared to Python?

On Wed, 25 Feb 2004 20:42:38 GMT, Joe Mason <joe@notcharles .ca> wrote:
[color=blue]
>In article <mailman.100.10 77717447.8594.p ython-list@python.org >, Dave Brueck wrote:[/color]
[color=blue][color=green]
>> someFunc(functi onCallback)
>> f = Foo()
>> someFunc(f.meth odCallback)
>>
>> 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.[/color]
>
>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.[/color]

I don't know how widespread it is among very high level languages, but
there is a reason (in the not-that-high-level sense) that C++, and
other 3GLs with classes hacked on don't. I'm assuming object Pascals
and Basics (esp Delphi and VB) count here, though don't sue me if I'm
wrong - I'm not familiar with object support in either.

A bound method needs more information that the address of the function
that implements it. It also needs the address of the object that it
applies to, stored along with the function address. So a bound method
may look like a function when it is called, but in low level
implementation detail, it is not the same thing. In the Python
internals, I imagine there is a bound method type which contains
pointers to both the object and the unbound method.

The thing is that a bound method amounts to a restricted version of
currying - in effect, you have curried the 'self' parameter.

With currying, you can define a more sepecialised function using a
more general one by specifying some subset of the parameters. A simple
Python-like syntax may be...

def original_fn (a, b, c) :
pass

specialist_fn = original_fn (, 2, )

specialist_fn (1, 3)

The currying in the assignment statement supplies parameter b, with
the remaining parameters a and c not being provided until the call.

To implement a curry'd function, you need a closure in addition to the
original function address - a record recording the values of the
parameters that have been supplied so far, and which parameters have
yet to be supplied. Just as you need the object bound-to as well as
the method to implement a bound function.

Imperative 3GLs kept functionality and data pretty thoroughly
separated - hence a lot of the OO fuss. Currying is standard in
functional languages. But currying predates object orientation by a
long time. In fact, I'm pretty sure it was invented about a century
ago as math (lambda calculus) rather than as programming, though I
could easily be confused.

Anyway, from this perspective, the bound method is an interesting
in-between concept. I've sometimes wondered if full currying support
may have been a better choice, but then a bound method is much more
efficient simply because it's simpler - not to mention avoiding some
syntactic difficulties I ignored above.


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Joe Mason]

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

In article <103qa59gj6h57f 8@news.supernew s.com>, John Roth wrote:[color=blue]
>
> "Joe Mason" <joe@notcharles .ca> wrote in message
> news:slrnc3ob0q .i6n.joe@gate.n otcharles.ca...[color=green]
>> In article <c1h1sb$1it26i$ 1@ID-169208.news.uni-berlin.de>, Greg Ewing[/color]
> (using news.cis.dfn.de ) wrote:[color=green]
>>[color=darkred]
>> > * 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.[/color]
>>
>> 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.[/color]
>
> 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.[/color]

Ah. Finally I see - I just misread "bound" as "unbound" in the original
post. I wondered why Greg brought up unbound methods and then gave me
examples of bound ones...

Joe

[Joe Mason]

Re: How does Ruby compare to Python?? How good is DESIGN of Rubycompared to Python?

In article <t5fq30l29nidjh 1tsksm8jlld03ff 3av5o@4ax.com>, Stephen Horne wrote:[color=blue]
> I don't know how widespread it is among very high level languages, but
> there is a reason (in the not-that-high-level sense) that C++, and
> other 3GLs with classes hacked on don't. I'm assuming object Pascals
> and Basics (esp Delphi and VB) count here, though don't sue me if I'm
> wrong - I'm not familiar with object support in either.[/color]

I didn't think Pascals and Basics supported function pointers at all,
but I haven't used them since high school, so maybe I just didn't
encounter them at the time.
[color=blue]
> Anyway, from this perspective, the bound method is an interesting
> in-between concept. I've sometimes wondered if full currying support
> may have been a better choice, but then a bound method is much more
> efficient simply because it's simpler - not to mention avoiding some
> syntactic difficulties I ignored above.[/color]

I've always found the performance differences between functional and imperative
languages fascinating (well, ever since I found out about it) - on the
one hand, pure functional languages can prove facts about the code
mathematically, so in theory the compiler can optimize much more away.
But on the other hand, supporting all the extra function state they need
is very costly.

Of course, hybrid languages like Python and Ruby have the worst of both
worlds - side effects everywhere AND extra function baggage to pass
around.

Joe

[Cameron Laird]

Foundations of computing languages (was: How does Ruby compare to Python?? How good is DESIGN of Rubycompared to Python?)

In article <t5fq30l29nidjh 1tsksm8jlld03ff 3av5o@4ax.com>,
Stephen Horne <steve@ninereed s.fsnet.co.uk> wrote:

[Cameron Laird]

Re: Foundations of computing languages (was: How does Ruby compare to Python?? How good is DESIGN of Rubycompared to Python?)

In article <103qr5nhpiojv2 5@corp.supernew s.com>, I griped:[color=blue]
>In article <t5fq30l29nidjh 1tsksm8jlld03ff 3av5o@4ax.com>,
>Stephen Horne <steve@ninereed s.fsnet.co.uk> wrote:
> .
> .
> .[color=green]
>>separated - hence a lot of the OO fuss. Currying is standard in
>>functional languages. But currying predates object orientation by a
>>long time. In fact, I'm pretty sure it was invented about a century
>>ago as math (lambda calculus) rather than as programming, though I
>>could easily be confused.[/color]
> .
> .
> .
>Ouch! I'm old enough to take some of this personally.
>Unless you're making some extremely recondite point
>(about Skolem's influences?), "a century" is too rough
>an approximation for me. Church and Kleene introduced
>the lambda calculus in the '30s; Schoenfinkel, then
>Curry, invented currying the decade before.[/color]