Bruce Eckel wouldn't know why to switch from Python to Ruby

C

cyberco

Bruce Eckel (author of amongst other popular books 'Thinking in Java')
has doubts why anybody would switch from Python to Ruby. An interesting
read:

http://www.artima.com/weblogs/viewpost.jsp?thread=141312

To quote him:

"The person I want to hear from is the core Python expert, someone who
knows that language incredibly well, who has decided that Ruby is just
so much better that all the mature Python libraries and community
expertise doesn't hold a candle to the value of moving to Ruby. That
person would be able to make a compelling, feature-by-feature argument"

Any Python experts here? :)
 
R

Robert Klemme

cyberco said:
Bruce Eckel (author of amongst other popular books 'Thinking in Java')
has doubts why anybody would switch from Python to Ruby. An
interesting read:

http://www.artima.com/weblogs/viewpost.jsp?thread=141312

Thanks for the interesting read!
To quote him:

"The person I want to hear from is the core Python expert, someone who
knows that language incredibly well, who has decided that Ruby is just
so much better that all the mature Python libraries and community
expertise doesn't hold a candle to the value of moving to Ruby. That
person would be able to make a compelling, feature-by-feature
argument"

Any Python experts here? :)

They probably forgot all their Python once they started with Ruby... ;-)

robert
 
D

David Balmain

I've done some programming in Python. I have to say that it's really
difficult trying to compare the two languages. Saying one is better
than the other seems pointless to me. Really it just comes down to
which language fits your brain the best. And even then, why limit
yourself to one. As the pragmatic programmes espouse, it really helps
to learn as many languages as you can.

Dave
 
S

Steve Litt

Bruce Eckel (author of amongst other popular books 'Thinking in
Java') has doubts why anybody would switch from Python to Ruby.
An interesting read:

http://www.artima.com/weblogs/viewpost.jsp?thread=141312

To quote him:

"The person I want to hear from is the core Python expert,
someone who knows that language incredibly well, who has decided
that Ruby is just so much better that all the mature Python
libraries and community expertise doesn't hold a candle to the
value of moving to Ruby. That person would be able to make a
compelling, feature-by-feature argument"

Any Python experts here? :)

I'm nowhere near a Python expert (nor a Ruby one) but I'll tell you
one thing -- with Python you can make a private class member only
by prepending a double underscore, and there are no protected class
members at all. I think the encapsulation is better in Ruby.

Python's an excellent language, and I really appreciate its
subordination by indentation (see
http://www.troubleshooters.com/tpromag/199908/index.htm#_readability
for reasons).

SteveT
 
R

rcoder

Eckel's article is getting pretty long in the tooth at this point -- I
remember reading it back when I was a Python user several years ago,
and it actually delayed my swith to Ruby for a few months, at least. I
probably don't qualify as a Python expert, but after being exposed to
both for non-trivial projects, there are definitely some differences
that make me prefer Ruby.

First, because all object "slots" in Python are public, (stupid
conventions like underscore prefixes aside) you see a lot of code like
this:

obj.setFoo("bar")

This is because 'obj.foo = "bar"' is a direct assignment, with no
method call involved. Since that's an encapsulation no-no, you get a
bunch of long-winded setFoo and getFoo methods all over the place,
which gives me nasty flashbacks to my days writing Java code. (Note:
this is probably getting better now with the standard decorator syntax
making automatic slot wrapper code generator more acceptable in the
Python world.)

Second, the crippled 'lambda' form (you can't include multiple
statements, since Python imposes its fugly statement/expression
separation) means you either a) give up on some very elegant potential
uses of first-order functions, or b) pollute your namespace with a
bunch of throw-away definitions that should be anonymous. Blocks and
proc/lamba objects feel more expressive, at the cost of having to use
the #call or #[] methods to actually invoke them.

Also, while I'm less than proud to admit it, a few of the "Perl-isms"
in Ruby, such as the =~ operator, simply seem more natural to me than
their Python equivalents. I try to avoid using the special syntax and
"magic" globals like $1, $2, et. al., but having spent so much time
wearing a sysadmin hat, (and we all know that means reading and hacking
on Perl code) it's nice to just be able to toss out regexp-based
one-liners when the urge/need arises.

Finally, metaprogramming in Ruby has always been a more straightforward
and common practice than in Python. The combination of
{class,module,instance}_eval, blocks, symbols (as a compact
representation of method and attribute names), and import/subclass
callbacks just makes more sense, IMHO, than metaclasses and multiple
inheritance, which are more or less essential for idiomatic Python
metaprogramming.

I do miss a few things: most importantly, list comprehensions, and
imported modules simply being another object/namespace to be used with
normal dot-notation. Python has also had a clean syntax for keyword
arguments in method calls for some time, and while I'm pretty
comfortable with the implicit hash-conversion model, it still feels
hacking compared to real kwargs.

Regardless, I agree with the folks earlier in the thread who've said
that you should pick the language that fits your brain better. For
recovering Java programmers, that may well be Python, as the heavy use
of inheritance and explicit setters and getters won't require any major
shift in design practices. On the other hand, if you're coming from
Perl, or maybe even C++, where the style is more fluid, Ruby will
probably feel more efficient, since you end up writing less boilerplate
code, and using a flatter class hierarchy.

-Lennon
 
M

Matt Lawrence

"The person I want to hear from is the core Python expert, someone who
knows that language incredibly well, who has decided that Ruby is just
so much better that all the mature Python libraries and community
expertise doesn't hold a candle to the value of moving to Ruby. That
person would be able to make a compelling, feature-by-feature argument"

I'm not sure that Ruby really is so much better than Python that a Python
expert would want to switch. Python is really good in many ways.
Starting from scratch, not knowing either, I'm glad I went with Ruby, but
if I had gone with Python, I'm not sure I would switch.

-- Matt
Nothing great was ever accomplished without _passion_
 
J

Jamis Buck

Excellent comparison, Lennon. Thanks for taking the time to post this.

- Jamis

Eckel's article is getting pretty long in the tooth at this point -- I
remember reading it back when I was a Python user several years ago,
and it actually delayed my swith to Ruby for a few months, at least. I
probably don't qualify as a Python expert, but after being exposed to
both for non-trivial projects, there are definitely some differences
that make me prefer Ruby.

First, because all object "slots" in Python are public, (stupid
conventions like underscore prefixes aside) you see a lot of code like
this:

obj.setFoo("bar")

This is because 'obj.foo = "bar"' is a direct assignment, with no
method call involved. Since that's an encapsulation no-no, you get a
bunch of long-winded setFoo and getFoo methods all over the place,
which gives me nasty flashbacks to my days writing Java code. (Note:
this is probably getting better now with the standard decorator syntax
making automatic slot wrapper code generator more acceptable in the
Python world.)

Second, the crippled 'lambda' form (you can't include multiple
statements, since Python imposes its fugly statement/expression
separation) means you either a) give up on some very elegant potential
uses of first-order functions, or b) pollute your namespace with a
bunch of throw-away definitions that should be anonymous. Blocks and
proc/lamba objects feel more expressive, at the cost of having to use
the #call or #[] methods to actually invoke them.

Also, while I'm less than proud to admit it, a few of the "Perl-isms"
in Ruby, such as the =~ operator, simply seem more natural to me than
their Python equivalents. I try to avoid using the special syntax and
"magic" globals like $1, $2, et. al., but having spent so much time
wearing a sysadmin hat, (and we all know that means reading and
hacking
on Perl code) it's nice to just be able to toss out regexp-based
one-liners when the urge/need arises.

Finally, metaprogramming in Ruby has always been a more
straightforward
and common practice than in Python. The combination of
{class,module,instance}_eval, blocks, symbols (as a compact
representation of method and attribute names), and import/subclass
callbacks just makes more sense, IMHO, than metaclasses and multiple
inheritance, which are more or less essential for idiomatic Python
metaprogramming.

I do miss a few things: most importantly, list comprehensions, and
imported modules simply being another object/namespace to be used with
normal dot-notation. Python has also had a clean syntax for keyword
arguments in method calls for some time, and while I'm pretty
comfortable with the implicit hash-conversion model, it still feels
hacking compared to real kwargs.

Regardless, I agree with the folks earlier in the thread who've said
that you should pick the language that fits your brain better. For
recovering Java programmers, that may well be Python, as the heavy use
of inheritance and explicit setters and getters won't require any
major
shift in design practices. On the other hand, if you're coming from
Perl, or maybe even C++, where the style is more fluid, Ruby will
probably feel more efficient, since you end up writing less
boilerplate
code, and using a flatter class hierarchy.

-Lennon
 
C

Chad Perrin

I'm not sure that Ruby really is so much better than Python that a Python
expert would want to switch. Python is really good in many ways.
Starting from scratch, not knowing either, I'm glad I went with Ruby, but
if I had gone with Python, I'm not sure I would switch.

Keep in mind that I'm an absolute non-expert in both Ruby and Python
when I say this. I know Perl better than both (and still rather like
it), and I'm not even an expert in that. However, this is my
impression:

Ruby and Python are both excellent languages. Ruby is incrementally
better than Python in a fair number of ways. Python is incrementally
better than Ruby -- as far as I have been able to determine, in very few
ways. In both cases, it's only incrementally better, nothing
earth-shattering. They're close enough that the determining factor, if
you have a preference, is to choose the language that "feels" best. Of
course, I could easily be wrong about any of this.

Since Python source code makes my eyes bleed, I'll stick with Ruby.
 
G

gabriele renzi

Steve Litt ha scritto:
I'm nowhere near a Python expert (nor a Ruby one) but I'll tell you
one thing -- with Python you can make a private class member only
by prepending a double underscore, and there are no protected class
members at all. I think the encapsulation is better in Ruby.

OTOH encapsulation may be considered better in python since you can be
(quite) sure that __methods and class variables won't break when
redefined by accident in a subclass.

Ruby vs Python is mostly a matter of taste, bith are fine languages, and
I second Robert Hicks' impression that there were overreactions to
Eckel's article from some people.
 
G

gabriele renzi

rcoder ha scritto:
Eckel's article is getting pretty long in the tooth at this point -- I
remember reading it back when I was a Python user several years ago,
and it actually delayed my swith to Ruby for a few months, at least. I
probably don't qualify as a Python expert, but after being exposed to
both for non-trivial projects, there are definitely some differences
that make me prefer Ruby.

First, because all object "slots" in Python are public, (stupid
conventions like underscore prefixes aside) you see a lot of code like
this:

obj.setFoo("bar")

This is because 'obj.foo = "bar"' is a direct assignment, with no
method call involved.

I think you'have been away from python far too long, recent python (3 or
4 versions I think_) has a nice thing called properties.
Basically you can declare "foo" to have setters and getters when you
need it, and still threat them in the same way (i.e. "obj.foo = bar"
becomes a method call). 80% of the times someone writing a setFoo or
getFoo is doing it because (s)he was a java/c++ developer.

OTOH I notice that you're aware of the decorator syntax which is far
more recente, so maybe this thing just slipped away :)
 
D

Doug H

gabriele said:
rcoder ha scritto:

I think you'have been away from python far too long, recent python (3 or
4 versions I think_) has a nice thing called properties.
Basically you can declare "foo" to have setters and getters when you
need it, and still threat them in the same way (i.e. "obj.foo = bar"
becomes a method call). 80% of the times someone writing a setFoo or
getFoo is doing it because (s)he was a java/c++ developer.

Properties in python don't work with subclasses, however.

#python:

class A(object):
def __init__(self):
self.x = 0
def getX(self):
return self.x
def setX(self, val):
self.x = val
X = property(fget=getX, fset=setX)

class B(A):
def getX(self):
return self.x + 1

b = B()
print b.X # 0 instead of 1, uh oh

#######################

#ruby:

class A
attr_accessor :X
def initialize
@X = 0
end
end
class B<A
def X
@X+1
end
end

b = B.new
puts b.X # 1
 
D

Doug H

That should have been
return super(B, self).getX() + 1
instead of
return super(B, self).getX + 1
Didn't notice error.
 
D

Devin Mullins

Woah! Thread-ahoy. Sorry if I'm duplicating content here:

Robert said:
I don't think he has "doubts" about someone switching. He wants to see
a detailed comparison between the two from someone who knows. I read
his piece and aside from Rails he wants to know "why Ruby?"
His piece comes off as nothing but vitriol, ad hominem, and rhetoric to
me. I choose not to get involved in the conversation. Other people
reacted differently, it seems.

Nonetheless, the Python vs Ruby question comes up a lot, and is somewhat
legitimate. I only played with Python for a little over a week. Here's
my (very) rough opinion:
- Ruby feels more object-oriented to me. Doing things the
object-oriented way was *extremely* easy. Everything is object.method
syntax (or, even cooler, delegated to a method, like the for...in syntax).
- There's no extra code for packaging up code into a library, and no
conceptual overhead for method/class extraction.
- No frickin' __underscores__!
- It's hooks for dynamic classivity make more sense to me.

Of course, this is pretty much all personal.

Devin
 
G

gabriele renzi

Devin Mullins ha scritto:
Everything is object.method
syntax (or, even cooler, delegated to a method, like the for...in syntax).

just to say for..in is delegated to a method in python too, and they
even delegate "if obj" to a method call :)
 
D

Daniel Schierbeck

gabriele said:
Devin Mullins ha scritto:

just to say for..in is delegated to a method in python too, and they
even delegate "if obj" to a method call :)

That's so cool. We need that. Now. Generally, though, I think Python's
__underscore__ convention is pretty annoying, though I can see why you
wouldn't want to add predefined semantics to general words like "new",
"get", etc.


Cheers,
Daniel
 
R

rcoder

Thanks for reminding me -- I have indeed been away from Python since
"way back" in the 2.1 days or so, and while I vaguely recall seeing
discussion of properties, it was after I had moved to Ruby, so it
really didn't jump out and grab me, as the interest was mostly within
the Python community.

Decorators, on the other hand, got a lot of attention in the language
community at large, since they were so comically controversial when
first added to the language.

Regardless, I suspect you'll still find a great deal of code like I
described out there "in the wild," since many non-trivial applications
implemented in Python target several older versions, and the syntax
changes for most of the 2.X updates were non-trivial.

(Mildly OT observation: one of the interesting side-effects of Python's
early adoption by Red Hat was that a single, canonical version of the
runtime was distributed with each release of the OS, and the system
depended on it heavily. This meant that a lot of Python-based
applications had to be written to the oldest Python packaged by Red Hat
for the OS versions they wanted to support, rather than the oldest
release a Python user would be likely to have installed. I suspect that
something similar is already starting in the Ruby world, as Rails has
already caused problems for people trying to upgrade to 1.8.3 and
1.8.4.)

-Lennon
 
T

tony summerfelt

cyberco wrote on 12/20/2005 10:57 AM:
To quote him:
"The person I want to hear from is the core Python expert, someone who

ruby has one thing going for it that python doesn't: ruby's oo doesn't
seem 'tacked on' like it does in python.

a newbie trying to choose between ruby and python (with oo being their
main priority) has an easy choice: ruby, because it's oo from the
ground up...

as for a switch, i seriously doubt any 'core python expert' will even
touch ruby. and by placing that as a requirement he has cemented his
belief that he won't be convinced...

i found that one of the first things a python programmer will ask when
you mention ruby is "does it have tuples? does it have dictionaries?"
as if programming efficiently required them.
 
G

gabriele renzi

tony summerfelt ha scritto:
Doug H wrote on 12/20/2005 6:42 PM:



is it just me or did that ruby code look a lot cleaner?

I think everyone can agree :)

But the python approach is maybe a little more pragmatic, in most use
cases you'd write this in ruby:
class Foo
attr_accessor :foo
def initialize foo
@foo = foo
end
end
end
while in python it would be:
class Foo:
def __init__(slf,foo):
slf.foo=foo

relying on the fact that you could translate variable access into an
accessor method when needed withouth breaking the interface.
OTOH some hardcore-OO people could object that allowing access to
instance variables by default may be a bad habit.
tomayto tomahto, I'd say.
 
J

Jeff Wood

------=_Part_1670_30253719.1135277417184
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... be careful, you're gonna bring down the python coding police ...

Although not a physical requirement of the runtime, you named your first
variable in the class method slf ... the python community would eat you
alive for that ...

They prefer ( and *ALL* their docs make sure to tell you over and over )
that the first parameter of the class method be named self.

... Dive into python and every other tutorial on the topic actually stops t=
o
make sure you understand this ...

I find it humorous ... and a bit retentive ... but, to each their own.

j.

tony summerfelt ha scritto:

I think everyone can agree :)

But the python approach is maybe a little more pragmatic, in most use
cases you'd write this in ruby:
class Foo
attr_accessor :foo
def initialize foo
@foo =3D foo
end
end
end
while in python it would be:
class Foo:
def __init__(slf,foo):
slf.foo=3Dfoo

relying on the fact that you could translate variable access into an
accessor method when needed withouth breaking the interface.
OTOH some hardcore-OO people could object that allowing access to
instance variables by default may be a bad habit.
tomayto tomahto, I'd say.


--
"Remember. Understand. Believe. Yield! -> http://ruby-lang.org"

Jeff Wood

------=_Part_1670_30253719.1135277417184--
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,020
Latest member
GenesisGai

Latest Threads

Top