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

[Joe Mason]

Say I modify your example so that we only have one Func which accepts
either a bound or unbound (functionCallback and Foo definitions are
unchanged):

print callback(*(extra_args+(5,6)))



Python doesn't care what type of callable it is passed, so long as it
somehow ends up with the right arguments to call it. Can Ruby handle this
case?

Sure, you'd just have to check if "callback" is of class Method or
UnboundMethod, and call bind on the first member of extra_args if
necessary. Again, Python does this for you, so it's definitely a
difference in the language, but it's not impossible (or even difficult).

With Ruby, you'd probably use blocks instead of functions for most
things that need this anyway.

Joe

 

[Ville Vainio]

MetalOne> Ruby is a fine language, but the community is smaller,
MetalOne> the bindings to external libraries are smaller and the
MetalOne> number of extra packages are smaller.

So, basically, it's probably not worth the trouble. It's a less mature
implementation of pretty much the same ideas.

If you are jonesing for a new language to play with, you could as well
play with Lisp. At least you would learn something new.

 

[A.M. Kuchling]

If you are jonesing for a new language to play with, you could as well
play with Lisp. At least you would learn something new.

That's pretty much my reaction to Ruby, too. It's kind of neat, and if I
was a Perl person I'd go use Ruby instead of waiting for Perl 6, but it
isn't so different from the existing scripting languages. If your interest
is in learning new ways of programming that turn your head around, you'd
need to look farther afield (Haskell, ML, Lisp, etc.).

--amk

 

[Paul Prescod]

...
> Down in the depths of the compiler, the simplest way to
> implement (C-style) functions is just to total up all the
> parameters and local space it will need and lay out a
> stack frame.

We're talking about Python and the Python compiler generates Python
bytecodes, not machine code!

...hybrid languages like Python and Ruby and Java and C#, then. It's
the combination of first-order functions *and* side effects that kills
you. (I don't know enough Java/C# to know if they have nested functions
and "function pointers" or equivalent - it actually wouldn't surprise me
if Java doesn't.)

Python function calling was never even remotely close to machine
function calls for a variety of reasons (primarily the fact that we're
talking about an interpreter rather than a compiler).

You may well be right that Python _would_ pay a cost for nested
functions if its function model was not already substantially more
complicated, sophisticated and expensive than C's. But there are all
sorts of reasons that Python function calls are slow and I frankly think
that nested scopes are the least of them:

* Python functions use a stack that is different than the C stack
(that's why stackless is even possible)

* Python functions have complicated calling conventions (varargs,
optional args, keyword args)

* Python functions are called through a protocol that supports other
types of "callables"

* Python integers etc. must be unboxed after the function call to do
anything useful with them

All of these performance-sucking features were in Python long before
nested functions.

Paul Prescod

 

[Joe Mason]

We're talking about Python and the Python compiler generates Python
bytecodes, not machine code!

I wasn't anymore, which is why I changed the thread title.

Python function calling was never even remotely close to machine
function calls for a variety of reasons (primarily the fact that we're
talking about an interpreter rather than a compiler).

That's a good thing to point out, though. I didn't mean to imply that
the first-order-function price was the main, or even an important, thing
that made Python slower than C. (I actually said that a couple of
times, and kept snipping it because it kept coming out sounding like I
was dumping on Python for being slow. Should've kept it in.)

Joe

 

[Mark 'Kamikaze' Hughes]

That's pretty much my reaction to Ruby, too. It's kind of neat, and if I
was a Perl person I'd go use Ruby instead of waiting for Perl 6, but it
isn't so different from the existing scripting languages.

The primary virtue of Perl used to be that it was the only language
with decent regexp support. But now everyone has good regexp support.

If your interest
is in learning new ways of programming that turn your head around, you'd
need to look farther afield (Haskell, ML, Lisp, etc.).

And I'd second either OCaml or Haskell as good languages if you want
to learn something new, while still being useful for real work. Pure ML
is rather awful to do real work in, though it can be done if you're
sufficiently functional-minded. OCaml is a pragmatic compromise of ML
with programming reality. Haskell, too, is a fairly pragmatic design.
I don't think you should deploy either one where someone else might have
to maintain your code, but they're educational.

Self would be another good educational language, but its current
implementation is not very portable.

 

[David MacQuigg]

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

This question was recently asked in the UserLinux mailing list, in
connection with our selection of Python as the primary scripting
language. I put together a page of links to other good discussions
and documents http://userlinux.com/cgi-bin/wiki.pl?RubyPython and got
some comments from the Ruby mailing list
http://www.google.com/groups?hl=en&...l67d7j1beguaqg24uc2tmgvtefl1%404ax.com&rnum=1

I was considering only the language aspects of the comparison, leaving
aside the number of users, projects, libraries, etc. I had to sift
through tons of stuff in the mailing lists look for examples of
anything beyond personal preferences for one style over another. I
came up with two fundamental differences ( see the link above ):
1) Ruby seems to have a slight advantage in handling complex sequences
of string operations, especially operations that can be stated
concisely as a string of method calls. I say slight advantage,
because the missing string and list methods could easily be added.
2) Ruby allows you to change the fundamental behavior of core classes
and operations. If you want string comparisons to be
case-insensitive, for example, you can modify the language to make
that happen. In Python, you make a subclass of string, and over-ride
the __eq__ method -- not as convenient if what you are trying to do is
change the behavior of a large body of already written code.

Alex Martelli, the source of example 2 above, pointed out that this is
not a deficiency of Python, but a deliberate design choice, making
Python more suitable for production work, but less advantageous as an
experimental language. In a production environment, we really *don't*
want to make it easy to redefine the behavior of the string class ( as
opposed to over-riding it in your own class ). We all need to share a
common language.

There is also a frequently stated difference between the use of code
blocks in Ruby and Generators in Python, but I was never able to find
an example where the Python code couldn't be made equivalent to Ruby.
The example on the wiki page above shows that the two differ only in
calling style. My tenetative conclusion is that there must be some
impressive difference in the way these features work internally, but
to the user it's just a matter of personal preference -- Do you want
to say:
fibUpTo(1000) { |f| print f, " " }
or
for f in fibUpTo(1000): print f,

If there are any Ruby experts here, please take a look at this
generator example. If there really is some fundametal difference
relevant to the user, I would like to know.

-- Dave

 

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

I don't see the distinction. "normal calling syntax" in ruby involves
an object, so "unbound function" isn't a meaningful concept.

Which is just what I was trying to say, really. Ruby doesn't
have functions, only methods. I'm not saying one is better
than the other, just pointing out the difference.

 

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

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).

I'm just going by what I see in the language. Beneath the
syntax, I see a lot that's very Smalltalk-like in Ruby.
I don't see anything that's fundamentally Perl-like,
on the other hand.

 

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

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.

Some Basics would let you use the result of an expression as a
line number in a GOTO or GOSUB, just in case there weren't already
enough ways to turn your code into spaghetti. Those that didn't
usually had ON...GOTO and ON...GOSUB statements that could be used
to achieve much the same effect.

Pascal lets you pass a procedure as a parameter to another
procedure (but not store it in a variable, due to scope issues).
It's likely this wouldn't have been mentioned in an introductory
Pascal course, however, as it would have been considered a
somewhat esoteric feature.

Later Wirth languages (Modula, Oberon) do let you have procedure
variables. But they can only point to top-level procedures, not
nested ones. One step forward, one back...

 

[JanC]

I'm just going by what I see in the language. Beneath the
syntax, I see a lot that's very Smalltalk-like in Ruby.
I don't see anything that's fundamentally Perl-like,
on the other hand.

From what I remember from the Ruby-talk at FOSDEM, Ruby was influenced by
several languages, including Smalltalk (OO features), Perl ("do what I
mean") and Python.

So the Perl influence has a lot to do with syntax: there are several ways
to express te same (e.g. blocks of code).