The Artima Developer Community
Sponsored Link

Weblogs Forum
Python-Ruby Comparison

12 replies on 1 page. Most recent reply: Aug 25, 2005 1:13 PM by Kay Schluehr

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 12 replies on 1 page
Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Python-Ruby Comparison (View in Weblogs)
Posted: Aug 21, 2005 7:17 AM
Reply to this message Reply
Summary
Ian Bicking creates the first reasonable analysis (that I know of) between the two languages.
Advertisement
Here's the link.

However, if you know of other writings that actually analyze the differences between the two languages (rather than just rant about how great one or the other is), please add them below.


Daniel Santa Cruz

Posts: 1
Nickname: dstcruz
Registered: Aug, 2005

Re: Python-Ruby Comparison Posted: Aug 22, 2005 6:31 AM
Reply to this message Reply
Have you given Ruby a shot? I really respect your views, and was wondering if you had given Ruby some though.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Python-Ruby Comparison Posted: Aug 22, 2005 7:29 AM
Reply to this message Reply
I'm kind of overloaded, so I've been waiting for analyses like what Ian did. It's much easier to do a diff on languages than to learn the whole language yourself then figure out the differences yourself.

The two killer apps that Ruby seems to have going for it (that I know of) are Rails (which is inspiring the Python community by example; although django, which was under development before Rails as far as I know, seems to achieve some of the same goals), and Rake, a "make" replacement which allows you to use Ruby to do anything to solve build problems (a big problem with make, ant etc. are that their creators thought that a little bit of programming syntax was enough. Eventually, however, build systems always need the full power of a programming language).

Ruby has features that appeal to Smalltalk programmers, so that can be more comfortable for those folks.

On the downside, the Ruby libraries are apparently not that mature (yet), and since library reuse is where you get your greatest leverage, that is a significant factor. That will certainly improve with time.

In the meantime, Python continues to add new, interesting, powerful features and libraries, so that keeps drawing me back into the Python fold. My guess is that I'll learn Ruby when I try creating a Rails example -- someday.

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Python-Ruby Comparison Posted: Aug 22, 2005 12:01 PM
Reply to this message Reply
There was a Python equivalent to Rake, too, but I can't find it now. I like the idea of make files with Python-like syntax and looked into the project a while back, but it wasn't ready for real work at that time. Now, I've forgotten what it was called.

I learned Ruby, but I already had a couple years of Python under my belt, so while there were a few things I liked, there wasn't nearly enough gravity to pull me away from Python. The libraries issue is pretty important and Python is pretty hard to beat there (except in the area of GUI, perhaps).

I think I'll have a look at Rake...

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Python-Ruby Comparison Posted: Aug 22, 2005 12:48 PM
Reply to this message Reply
Scons:
http://sourceforge.net/projects/scons/
Is written in Python, but I don't remember how Pythonic the syntax is.

There also seems to be something called PyMake, but I can't see what the status of that project is.

Seems to me it should be possible to build something that has simple make-style targets and dependencies, but that performs all its commands using either Python or shell commands.

Oran Dennison

Posts: 1
Nickname: oran
Registered: Aug, 2005

Re: Python-Ruby Comparison Posted: Aug 23, 2005 1:17 PM
Reply to this message Reply
Here's another fairly good academic comparison, although it did sway me in favor of Ruby...

http://www.cs.washington.edu/homes/kd/courses/pythonruby.pdf

Ian Bicking

Posts: 900
Nickname: ianb
Registered: Apr, 2003

Re: Python-Ruby Comparison Posted: Aug 24, 2005 1:27 AM
Reply to this message Reply
Though I wasn't looking at that paper specifically when I wrote my own, it was one of the articles that I had in mind when to writing the Object Oriented Programming section. To its credit the paper aknowledges that Python's data representation is pure OO. However, I am unimpressed with the general analysis of OO there, which I think focuses on fairly arbitrary definitions of OO -- classes and methods and inheritance. I'm much more concerned with usability and generality, not purity along arbitrary lines. Though Python's core set of concepts (which includes functions) is different from Ruby and Smalltalk, it is no less general, and in practice I think it is much more approachable.

Christopher Dunn

Posts: 2
Nickname: cdunn
Registered: Aug, 2005

Re: Python-Ruby Comparison Posted: Aug 24, 2005 2:57 PM
Reply to this message Reply
Ruby is more of a computer scientist's language. It's more purely OO, as well as more "functional". For example, it has true closures.

If you issue a new function from within a function, in Ruby the new function retains access to the variables from the outer function, but in Python the new function has only its own variables and the globals.

Purists like the Ruby way, but in Python a closure can be created explicitly by issuing an object instead of a function. Just define the __call__() method of the class, and add the closure data to the object. That is clearer to non-programmers.

And that is one of the strengths of Python: You don't need to be a programmer to use. Because of its obviousness to non-programmers, it is a wonderful integration language.

Python's other great strength is the richness of its library, which makes it a wonderful proto-typing language, especially considering its close matching with C++ and the power of Boost.Python.

The languages differ syntactically, which is a matter of taste. Personally, I do not agree that "-3.abs" is clearer than "abs(-3)", and I do not find the extra characters in Ruby (like "|") easy to remember.

I like Ruby, but I think that where it is useful, other languages are better. Smalltalk programmers seem drawn to it, and I think that they should consider Ocaml instead.

Ian Bicking

Posts: 900
Nickname: ianb
Registered: Apr, 2003

Closures Posted: Aug 24, 2005 2:59 PM
Reply to this message Reply
Python has true closure. A long time ago it didn't, but that hasn't been true for some years.

Christopher Dunn

Posts: 2
Nickname: cdunn
Registered: Aug, 2005

Re: Closures Posted: Aug 25, 2005 10:08 AM
Reply to this message Reply
This is a subtle issue. Here is a post I made somewhere else recently that explains the difference:


Anyone interested in this recipe might also like to read a recent book, "Hackers and Painters: Big Ideas from the Computer Age", by Paul Graham (2004).

Though the book is mostly a non-technical discussion of programming principles and practices (generally lionizing Lisp) there is an appendix (pp. 195-99) which compares the __call__ version above to even simpler solutions in other languages.

Though his example is just a generated function with maintained state, rather than a "generator" (ie a function with a "yield" call), it explains exactly why some people appreciate other, more powerful languages.

I disagree with him: The Python example is only slightly more complicated, and it is vastly easier for a non-expert user to comprehend. The implicitly lexical variables do not exactly aid readability.

However, Graham is not unkind to Python, and this book is definitely worth reading for anyone with an interest in the utility of programming languages.

I'm pointing that out because this recipe has caused some big ideas to gel in my mind. After studying this complicated recipe, I suddenly "get" what Python is doing with functions. Tes, the version in the comment is definitely the way I would code it in practice, but I'm glad to see the complex one.

In case you don't have the book, here are his examples. Python first:

class foo:
def __init__(self, n): self.n = n
def __call__(self, i): self.n +=1; return self.n

Obviously, this could yield self.n instead.

The Java solution is a pain, but in Javascript:

function foo(n) {
return function(i) {
return n += 1 }}



Smalltalk has strange syntax, but at least has the transparency of the Python version:

foo: n
|s|
s := n.
^[:i| s := s+i. ]



Perl has an implicit return statement:

sub foo {
my ($n) = @_;
sub {$n += shift}
}



Ruby is the clearest, but with strange delimiters:

def foo (n)
lambda {|i| n += i} end



Lisp is easily the least cluttered:

(defun foo(n)
(lambda (i) (incf n i)))


The author also lists 2 other Python solutions which work, and 2 which do not work:

def foo(n):
class accumulator:
def __init__(self, s):
self.s = s
def inc(self, i):
self.s += i
return self.s
return acc(n).inc

# and

def foo(n):
s = [n] # The list holds a copy of n
def bar(i):
s[0] += i
return s[0]
return bar

And these 2 do *not* work:

def foo(n):
return lambda i: return n += 1

# nor

def foo(n):
lambda i: n += 1

The author guesses that Python will one day allow something like these, but only the Python class-based version allows easy access to n. So in fact, what to some is a flaw in Python can be a feature to others.

I hope somebody learns as much from these examples as I have. Functional programming suddenly makes much more sense to me.

Ian Bicking

Posts: 900
Nickname: ianb
Registered: Apr, 2003

Re: Closures Posted: Aug 25, 2005 12:41 PM
Reply to this message Reply
You are correct in noting that Python closures are not writable, and thus not the same as in some of the other languages. This is related to the lack of variable declaration in Python, though also the rules to figure out what variable is being assigned to; assignments are always treated as local. Ruby can do it otherwise because global values are refered to in a way that is distinct from local values (with leading caps or $).

One of the Python examples is a little peculiar:

def foo(n):
class accumulator:
def __init__(self, s):
self.s = s
def inc(self, i):
self.s += i
return self.s
return acc(n).inc


The closure is redundant in this case; better to do:
class accumulator:
def __init__(self, s):
self.s = s
def __call__(self, i):
self.s += i
return self.s


PEP 342 (http://www.python.org/peps/pep-0342.html -- standards track) will make something like this possible:
def accum(n):
incr = yield # wait to get the first incr to be sent in
while 1:
n += incr
incr = yield n # return the new value, wait for next incr


And used like:
>>> s = accum(0)
>>> s.next() # setup boilerplate :(
>>> s.send(3)
3
>>> s.send(1)
4

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Closures Posted: Aug 25, 2005 1:07 PM
Reply to this message Reply
Chistopher,

it is a well known fact in Python that it is not possible to rebind a name defined in an outer scope of a closure. But this does not imply that the name is not enclosed in the scope of the inner function. In FP closures without the readonly restriction are used to model shared state. Since Python already supports classes this is a redundant feature and I don't see much chance that it will become part of the language spec.

The trivial example and it's solutions you provided are therefore not very instructive for the true solution domain. I would simply pass the n as a keyword argument:


def foo(n):
def bar(i,n=n):
n+=i # state change
return n
return bar


Or shorter without keywords:


def foo(n): # pure functional
lambda i:i+n

Kay

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Closures Posted: Aug 25, 2005 1:13 PM
Reply to this message Reply
Ups! Forget the examples I presented. They enable only one shot.

Kay

Flat View: This topic has 12 replies on 1 page
Topic: I think I am Python Challenged Previous Topic   Next Topic Topic: Messaging may not be the way to Build a Distrbuted System

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use