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?

 
 
Joe Mason
Guest
Posts: n/a
 
      02-26-2004
In article <Xns949B61515EFD1duncanrcpcouk@127.0.0.1>, Duncan Booth wrote:
> 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):
>
>>>> def Func(callback, *extra_args):

> print callback(*(extra_args+(5,6)))
>
>
>>>> Func(functionCallback)

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

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

> 33
>>>>

>
> 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
 
Reply With Quote
 
 
 
 
Ville Vainio
Guest
Posts: n/a
 
      02-27-2004
>>>>> "MetalOne" == MetalOne <(E-Mail Removed)> writes:

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.

--
Ville Vainio http://tinyurl.com/2prnb
 
Reply With Quote
 
 
 
 
A.M. Kuchling
Guest
Posts: n/a
 
      02-27-2004
On 27 Feb 2004 10:36:39 +0200,
Ville Vainio <(E-Mail Removed)> wrote:
> 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
 
Reply With Quote
 
Paul Prescod
Guest
Posts: n/a
 
      02-28-2004
Joe Mason wrote:

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



 
Reply With Quote
 
Joe Mason
Guest
Posts: n/a
 
      02-28-2004
In article <(E-Mail Removed)>, Paul Prescod wrote:
> Joe Mason wrote:
>
>>...
> > 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!


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
 
Reply With Quote
 
Mark 'Kamikaze' Hughes
Guest
Posts: n/a
 
      03-01-2004
A.M. Kuchling <(E-Mail Removed)>
wrote on Fri, 27 Feb 2004 07:42:42 -0600:
> On 27 Feb 2004 10:36:39 +0200,
> Ville Vainio <(E-Mail Removed)> wrote:
>> 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.


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.

--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"Doing the impossible makes us mighty." -Captain Malcolm Reynolds, Firefly
 
Reply With Quote
 
David MacQuigg
Guest
Posts: n/a
 
      03-01-2004
On 24 Feb 2004 14:43:03 -0800, http://www.velocityreviews.com/forums/(E-Mail Removed) (Christian
Seberino) wrote:

>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&l...com%26rnum%3D1

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

 
Reply With Quote
 
Greg Ewing (using news.cis.dfn.de)
Guest
Posts: n/a
 
      03-02-2004
Joe Mason wrote:
> 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, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

 
Reply With Quote
 
Greg Ewing (using news.cis.dfn.de)
Guest
Posts: n/a
 
      03-02-2004
Cameron Laird wrote:
> 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, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

 
Reply With Quote
 
Greg Ewing (using news.cis.dfn.de)
Guest
Posts: n/a
 
      03-02-2004
Joe Mason wrote:
> 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...

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

 
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