By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,855 Members | 1,970 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,855 IT Pros & Developers. It's quick & easy.

What's TOTALLY COMPELLING about Ruby over Python?

P: n/a
I'm realizing I didn't frame my question well.

What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes you jump
up in your chair and scream "Wow! Ruby has *that*? That is SO FRICKIN'
COOL!!! ***MAN*** that would save me a buttload of work and make my life
sooooo much easier!"

As opposed to minor differences of this feature here, that feature there.
Variations on style are of no interest to me. I'm coming at this from a C++
background where even C# looks like an improvement. ;-) From 10,000 miles
up, is there anything about Ruby that's a "big deal" compared to Python?

One person mentioned Japanese documentation. I'm sure that's Totally Kewl
to the Japanese....

--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

Jul 18 '05 #1
Share this Question
Share on Google+
54 Replies


P: n/a
Brandon J. Van Every wrote:
What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes you jump
up in your chair and scream "Wow! Ruby has *that*? That is SO FRICKIN'
COOL!!! ***MAN*** that would save me a buttload of work and make my life
sooooo much easier!"


Code blocks, although I'd rather go to the source and steal them from
Smalltalk.

Python now has most of the parts to implement code blocks, perhaps not
exactly like Smalltalk, but enough to make them useful. What is lacking
is a syntax to be able to create lambdas with multiple statements. And
perhaps a syntax without using the keyword lambda, as some people seem
to have an allergic reaction to it.

Daniel

Jul 18 '05 #2

P: n/a
Daniel Dittmar wrote:

Brandon J. Van Every wrote:
What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes you jump
up in your chair and scream "Wow! Ruby has *that*? That is SO FRICKIN'
COOL!!! ***MAN*** that would save me a buttload of work and make my life
sooooo much easier!"


Code blocks, although I'd rather go to the source and steal them from
Smalltalk.


What is it about code blocks that would let "save *me* a buttload of work
and make *my* life sooooo much easier"?

If one can't answer that, one shouldn't expect to be able to answer whatever
the heck it is Brandon has in mind (which is clearly not much), since
only he has any idea what it is he wants, and we're not even sure about that...

-Peter
Jul 18 '05 #3

P: n/a
On Monday 18 August 2003 12:07 pm, Brandon J. Van Every wrote:
I'm realizing I didn't frame my question well.

What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes you
jump up in your chair and scream "Wow! Ruby has *that*? That is SO
FRICKIN' COOL!!! ***MAN*** that would save me a buttload of work and make
my life sooooo much easier!"


Nothing.

-Dave

Jul 18 '05 #4

P: n/a
Brandon J. Van Every wrote:
What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes you jump
up in your chair and scream "Wow! Ruby has *that*? That is SO FRICKIN'
COOL!!! ***MAN*** that would save me a buttload of work and make my life
sooooo much easier!"


The simple fact that *you* are not active on c.l.ruby?
A time-saver, certainly ;-)

--
Real e-mail address is 'cHVAdm8ubHU=\n'.decode('base64')
Visit my Homepage at http://www.homepages.lu/pu/

Jul 18 '05 #5

P: n/a
"Brandon J. Van Every" wrote:
I'm realizing I didn't frame my question well.

What's ***TOTALLY COMPELLING*** about Ruby over Python?


comp.lang.ruby doesn't have Brandon Van Every.

--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ I dream things that never were and say, "Why not?"
\__/ John F. Kennedy
Jul 18 '05 #6

P: n/a
Erik Max Francis wrote:
What's ***TOTALLY COMPELLING*** about Ruby over Python?


comp.lang.ruby doesn't have Brandon Van Every.


LOL

Istvan.

Jul 18 '05 #7

P: n/a

Brandon> I'm realizing I didn't frame my question well. What's
Brandon> ***TOTALLY COMPELLING*** about Ruby over Python? What makes
Brandon> you jump up in your chair and scream "Wow! Ruby has *that*?
Brandon> That is SO FRICKIN' COOL!!! ***MAN*** that would save me a
Brandon> buttload of work and make my life sooooo much easier!"

Apparently, not much in this crowd, otherwise most of us would have switched
to Ruby by now. Try asking the Ruby folks. They will probably be able to
come up with some answers for you.

Skip

Jul 18 '05 #8

P: n/a

"Peter Hansen" <pe***@engcorp.com> wrote in message
news:3F***************@engcorp.com...
Daniel Dittmar wrote:

Brandon J. Van Every wrote:
What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes you jump up in your chair and scream "Wow! Ruby has *that*? That is SO FRICKIN' COOL!!! ***MAN*** that would save me a buttload of work and make my life sooooo much easier!"
Code blocks, although I'd rather go to the source and steal them from
Smalltalk.


What is it about code blocks that would let "save *me* a buttload of work
and make *my* life sooooo much easier"?


It's not so much code blocks. It's that Ruby's syntax gives you one code
block for
free in every method call. And the Ruby library is organized so that the
facility
is useful, which Python's isn't (or at least, it isn't as useful.)

All of the Ruby collections implement a .each method, which is essentially
a version of the Visitor pattern. If I want to do something to every element
in a list or a dict (or any kind of collection,) all I have to do is say
something
like (using Python syntax):

collectObj.each(<method name>)

In Python, that's either a lambda (which restricts what you can do with it,)
or a named function (which is overkill a huge amount of the time.) And you
have to worry about distinctions between functions and methods. In other
words, it's a mess compared to Ruby.

Now, you can say: "We've got that with map()." Well, we've got it when
your inputs are either lists (or implement the correct protocol) but the
result is a list, it's not an internal modification to the object's state.

You can also say: we can do that with for. Well, duh. For is a
statement, not a method call.

To continue on this vein, Ruby directly implements Visitor, Observer,
Delegate and Singleton. I don't particularly like the way it does some
of them, but Python can't claim any one of the four!

Granted, you can do a clean singleton using new style classes and the
__new__() method, but (as of 2.3) it's not anywhere in the core
documentation
that I could find. Observer is simply a couple of classes. Visitor I've
discussed above, and I'll leave Delegate for the reader.
If one can't answer that, one shouldn't expect to be able to answer whatever the heck it is Brandon has in mind (which is clearly not much), since
only he has any idea what it is he wants, and we're not even sure about that...

It might be better to simply take the question at face value, rather than
slanging Brandon. I don't find the personalities to add anything of value
to the conversation.

John Roth
-Peter

Jul 18 '05 #9

P: n/a
On Mon, 18 Aug 2003 12:20:50 -0600, Andrew Dalke wrote:

And this sort of post is making your troll mark almost indelible.


Brandon is not a troll. He is very serious in his quest to find a good
'alternative' language. Look him up on Google.

Regards,
Henk Burgstra
Jul 18 '05 #10

P: n/a
John Roth wrote:

"Peter Hansen" <pe***@engcorp.com> wrote:
What is it about code blocks that would let "save *me* a buttload of work
and make *my* life sooooo much easier"?


It's not so much code blocks. It's that Ruby's syntax gives you one code
block for
free in every method call. And the Ruby library is organized so that the
facility
is useful, which Python's isn't (or at least, it isn't as useful.)

All of the Ruby collections implement a .each method, which is essentially
a version of the Visitor pattern. If I want to do something to every element
in a list or a dict (or any kind of collection,) all I have to do is say
something
like (using Python syntax):

collectObj.each(<method name>)

In Python, that's either a lambda (which restricts what you can do with it,)
or a named function (which is overkill a huge amount of the time.) And you
have to worry about distinctions between functions and methods. In other
words, it's a mess compared to Ruby.

Now, you can say: "We've got that with map()." Well, we've got it when
your inputs are either lists (or implement the correct protocol) but the
result is a list, it's not an internal modification to the object's state.

You can also say: we can do that with for. Well, duh. For is a
statement, not a method call.


So what you seem to be saying is that Ruby has some features which
in some cases can save some time or somewhat simplify code that when
written in Python would take slightly longer or be slightly more
complicated. (This probably underemphasizes the value you place on
such a thing, but I think that's the gist of it.)

While I do acknowledge that Python is often touted as a great solution
over other languages just because it saves time and simplifies the
resulting solutions, I'm not clear on why these few small differences
would amount to a *TOTALLY COMPELLING* reason, to anyone, to use Ruby
over Python.

-Peter
Jul 18 '05 #11

P: n/a
[John Roth, among others, wrote]

[Snip: Some stuff about good things that Ruby does]

As someone who has never seen or written a line of Ruby, I find it
most interesting that of all the positive points being made about
Ruby, no-one has posted a single line of Ruby code.

Whenever people are making points about python, they usually post
illustrative snippets of python. Fair enough, it's a python newsgroup,
so maybe Ruby code doesn't belong.

But I am interested to read others opinions of what Ruby has/does that
python hasn't/doesn't. The support for continuations certainly sounds
interesting. Some code snippets would really help, for illustrative
purposes.

but-python-does-almost-everything-that-*i*-need-ly y'rs.

--
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan: http://xhaus.com/mailto/alan
Jul 18 '05 #12

P: n/a
Andrew Dalke wrote:
Brandon J. Van Every:
What's ***TOTALLY COMPELLING*** about Ruby over Python?
Nothing.

I think several people have been very explicit in saying
that Ruby has some advantages over Python, and vice versa,
that in most cases it's a wash, but that there's nothing 'TOTALLY
COMPELLING" about Ruby.


That's the answer I was expecting to hear.
You need to acquire critical reading skills.
No I do not. I was seeking clear verification, and I got what I was looking
for. I suggest that you need to acquire imagination skills. You can't seem
to wrap your head around legitimate reasons for asking a question.
And this sort of post is making your troll mark almost indelible.


I'm tired of knee-jerkers like you. Welcome to my killfile!

--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

Jul 18 '05 #13

P: n/a
Jeff Epler wrote:
Of course, without Python users, he wouldn't have much fun,
would he, with nobody stupid enough to stand up to defend Python and
"get trolled". So even the troll should be glad that there's nothing
"totally compelling" about Ruby over Python.
I don't want to get sucked into an issue that I have little to no interest
in. So I will observe rhetorically: some of you people waste a *lot* of
energy on games of "who's a troll." Mabye it's time for you to establish a
c.l.p.advocacy newsgroup, to siphon those energies in a particular
direction? But hey, it's your newsgroup.
Jeff
PS I'd just like to state for the record that neither Python nor Ruby
have a totally compelling advantage compared to the following

K&R C


Even as one who hasn't converted to Python yet, that statement is clearly
insane.

--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

Jul 18 '05 #14

P: n/a
Patrick Useldinger wrote:
Brandon J. Van Every wrote:
What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes
you jump up in your chair and scream "Wow! Ruby has *that*? That
is SO FRICKIN' COOL!!! ***MAN*** that would save me a buttload of
work and make my life sooooo much easier!"


The simple fact that *you* are not active on c.l.ruby?
A time-saver, certainly ;-)


I wonder how large my c.l.p killfile is now?

--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

Jul 18 '05 #15

P: n/a
Istvan Albert wrote:
Erik Max Francis wrote:
What's ***TOTALLY COMPELLING*** about Ruby over Python?
comp.lang.ruby doesn't have Brandon Van Every.


Erik has been in my killfile forever, from other newsgroups. I even had to
put him back in after letting him out. I thought a year would have been
enough, but apparently not.
LOL

Istvan.


So, you're guilty by association. Goodbye!

--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

Jul 18 '05 #16

P: n/a
Brandon J. Van Every wrote:
I wonder how large my c.l.p killfile is now?


Humour is a sign of intelligence; being able to joke about oneself even
more so. Try it!
;-)

--
Real e-mail address is 'cHVAdm8ubHU=\n'.decode('base64')
Visit my Homepage at http://www.homepages.lu/pu/

Jul 18 '05 #17

P: n/a
"John Roth" <ne********@jhrothjr.com> writes:
[...]
It's not so much code blocks. It's that Ruby's syntax gives you one
code block for free in every method call.
I don't know what that means. Care to explain a bit more?

[...] All of the Ruby collections implement a .each method, which is essentially [...] like (using Python syntax):

collectObj.each(<method name>) [...] You can also say: we can do that with for. Well, duh. For is a
statement, not a method call.
I don't understand. Why does this matter?

I guess you could implement this in Python if you had a burning
desire, using __metaclass__ (caveat: never having had such a desire,
I've never used metaclasses, so I may be wrong).

To continue on this vein, Ruby directly implements Visitor, Observer,
Delegate and Singleton. I don't particularly like the way it does some
of them, but Python can't claim any one of the four!

[...]

And so...?
John
Jul 18 '05 #18

P: n/a
"Brandon J. Van Every" wrote:
Erik has been in my killfile forever, from other newsgroups. I even
had to
put him back in after letting him out. I thought a year would have
been
enough, but apparently not.


There's been at least four of five times where Brandon has claimed to
have put me in his killfile; he keeps "forgetting." Not that that is
terribly surprising coming from someone who is so fond of telling people
about the contents of his killfile.

--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ I want a martini that could be declared a disaster area.
\__/ Capt. Benjamin "Hawkeye" Pierce
Jul 18 '05 #19

P: n/a
Brandon J. Van Every wrote:
Andrew Dalke wrote:
Brandon J. Van Every:
(snip)
And this sort of post is making your troll mark almost indelible.

I'm tired of knee-jerkers like you. Welcome to my killfile!


Lol ! A certified troll killfiling regular posters ! At this point, it
becomes something like Mastery - with a great 'M'.

Bruno

PS : Brandon, please make my day and tell me : did I won my place in
your killfile too ?-)

Jul 18 '05 #20

P: n/a
Istvan Albert wrote:
Erik Max Francis wrote:
What's ***TOTALLY COMPELLING*** about Ruby over Python?

comp.lang.ruby doesn't have Brandon Van Every.

LOL


LOL 2

Bruno
(yes, I want to be in Brandon's killfile. It's the new game on clp :
being in Brandon's killfile. Just imagine what will happen when every
clp regulars will be in Brandon's kill file...)

Jul 18 '05 #21

P: n/a


Bottom line is that people that uses Python have a better sex life than
those that use other languages.
That is ***TOTALLY COMPELLING*** enough for me to use Python.

--ajr

I'm realizing I didn't frame my question well.

What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes you jump up in your chair and scream "Wow! Ruby has *that*? That is SO FRICKIN'
COOL!!! ***MAN*** that would save me a buttload of work and make my life
sooooo much easier!"

As opposed to minor differences of this feature here, that feature there.
Variations on style are of no interest to me. I'm coming at this from a C++ background where even C# looks like an improvement. ;-) From 10,000 miles up, is there anything about Ruby that's a "big deal" compared to Python?

One person mentioned Japanese documentation. I'm sure that's Totally Kewl
to the Japanese....

--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

Jul 18 '05 #22

P: n/a
John Roth
All of the Ruby collections implement a .each method, which is essentially
a version of the Visitor pattern. If I want to do something to every element in a list or a dict (or any kind of collection,) all I have to do is say
something like (using Python syntax):

collectObj.each(<method name>)
Does that mean 'apply the method to each element of my
collection?'? Does it return a new container or modify things
in-place? Is it applied recursively?

Does it work on strings? Are characters in Ruby also strings?
If so, and if .each is recursive, what's the bottom case?
And you
have to worry about distinctions between functions and methods. In other
words, it's a mess compared to Ruby.
Where does that distinction come into play? A method is a bound
function, kinda like a curried function with self.

I find C++ methods more confusing, because a reference to a
class method is unbound, when I almost always want it bound.
Now, you can say: "We've got that with map()." Well, we've got it when
your inputs are either lists (or implement the correct protocol) but the
result is a list, it's not an internal modification to the object's state.
Ahh. Are strings in Ruby mutable or immutable? ... Yup,
looks like it's mutable. From the FAQ

def downer(string)
string.downcase!
end
a = "HELLO"
downer(a)
puts a #=> "hello"

In which case it makes more sense for this in Ruby than in
Python, since

"ABCDEFG".each(f)

can't do that much unless f modifies state, either as a bound
method or tweaking global variable.

Given that rather fundamental difference, an each method
in Python + code blocks wouldn't be any more powerful
than a for statement. The following is possible

def each(container, f):
for i, x in enumerate(container):
container[i] = f(container[i])

but then it requires the container be indexable, which
is stronger than just being iterable.

How do Ruby's associative arrays work when the string used
as the key is mutated in-place? Is it copy-on-write?
To continue on this vein, Ruby directly implements Visitor, Observer,
Delegate and Singleton. I don't particularly like the way it does some
of them, but Python can't claim any one of the four!
The Python approach to a Singleton is called a 'Borg' class.
Described by Alex Martelli, it looks like
class Borg: .... shared_state = {}
.... def __init__(self):
.... self.__dict__ = Borg.shared_state
.... x1 = Borg()
x1.a = "Albuquerque"
x2 = Borg()
x2.a 'Albuquerque'


The other way to get singletons is with a factory function,
which under Python wouldn't look different than a normal
constructor. I looked at some Java code recently and
wanted to suggest a factory implementation only to realized
that would require a lot of 'new' removals.
Granted, you can do a clean singleton using new style
classes and the __new__() method,
See Alex's discussion at
http://aspn.activestate.com/ASPN/Coo...n/Recipe/66531

as for why singleton (so that 'x1 is x2') is less important
than many consider. Though I know I can't recall needed a
singleton for my code. Maybe I have a different code style?
I've noticed a tendency of mine towards functional programming...

Anyway, others consider Borg a workaround for Python's
until-2.3 unability to support singletons, as with
http://mail.python.org/pipermail/pyt...il/096382.html

As for Observer, etc., I know they are simple classes so I
don't consider them all that important as a differentiator.
It might be better to simply take the question at face value, rather than
slanging Brandon. I don't find the personalities to add anything of value
to the conversation.


Despite my best attempts, I find it almost impossible to slag someone
without including information to back up my view. Eg, I thought my
numbers and trends of mentions of other programming languages was
pretty interesting, but I guess it was of no value to you. :(

Andrew
da***@dalkescientific.com
Jul 18 '05 #23

P: n/a
JZ
"Ruby still looks to me like a language that was invented because you
couldn't (rationally) use objects or references in Perl, so it has
Perl-ish syntax, which I don't think is very helpful (someday I may
learn it, but Python continues to be far more compelling to me)"

Bruce Ecklel http://mindview.net/FAQ/FAQ-008

Jul 18 '05 #24

P: n/a

"Peter Hansen" <pe***@engcorp.com> wrote in message
news:3F***************@engcorp.com...
John Roth wrote:

"Peter Hansen" <pe***@engcorp.com> wrote:
What is it about code blocks that would let "save *me* a buttload of work and make *my* life sooooo much easier"?
It's not so much code blocks. It's that Ruby's syntax gives you one code block for
free in every method call. And the Ruby library is organized so that the
facility
is useful, which Python's isn't (or at least, it isn't as useful.)

All of the Ruby collections implement a .each method, which is essentially a version of the Visitor pattern. If I want to do something to every element in a list or a dict (or any kind of collection,) all I have to do is say
something
like (using Python syntax):

collectObj.each(<method name>)

In Python, that's either a lambda (which restricts what you can do with it,) or a named function (which is overkill a huge amount of the time.) And you have to worry about distinctions between functions and methods. In other
words, it's a mess compared to Ruby.

Now, you can say: "We've got that with map()." Well, we've got it when
your inputs are either lists (or implement the correct protocol) but the
result is a list, it's not an internal modification to the object's state.
You can also say: we can do that with for. Well, duh. For is a
statement, not a method call.


So what you seem to be saying is that Ruby has some features which
in some cases can save some time or somewhat simplify code that when
written in Python would take slightly longer or be slightly more
complicated. (This probably underemphasizes the value you place on
such a thing, but I think that's the gist of it.)

While I do acknowledge that Python is often touted as a great solution
over other languages just because it saves time and simplifies the
resulting solutions, I'm not clear on why these few small differences
would amount to a *TOTALLY COMPELLING* reason, to anyone, to use Ruby
over Python.


I don't know either. I do know of several posters on the XP
lists, however, who have switched from Python to Ruby, and
I doubt that it was corporate pressure in any of their cases.

If you're interested (which most of the posters here are not -
I'm certainly not) you might check with them. I'm sure Phlip, for
one, would be more than happy to say why he switched, and what
made the difference.

John Roth
-Peter

Jul 18 '05 #25

P: n/a

"Doug Tolton" <dt*****@yahoo.com> wrote in message
news:e7********************************@4ax.com...
On Mon, 18 Aug 2003 16:22:01 -0400, "John Roth"
<ne********@jhrothjr.com> wrote:
It might be better to simply take the question at face value, rather than
slanging Brandon. I don't find the personalities to add anything of value
to the conversation.
Clearly you haven't followed c.l.p for long, otherwise you wouldn't
make a statement like this. Brandon is *constantly* trolling this
newsgroup with inflammatory and/or contradictory statements.
Seriously do a search using google groups for Brandon Van Every in
comp.lang.python. Your statement is innappropriate take in full
context.


I've been on c.l.py for around two years. Your statement
is rude and assumes things you have not bothered to check
out.

There is a very simple rule for dealing with trolls, which most
usenet newbies learn sooner or later. If you think someone is
trolling, simply ignore them. Don't answer their posts, don't
comment on them, don't even give them the gratification of
a reply that says: "plonk!" Just killfile them and quit wasteing
bandwidth. You've got better things to do with your time than
maintaining an interaction that you find aggrevating.

John Roth

Doug Tolton
(format t "~a@~a~a.~a" "dtolton" "ya" "hoo" "com")

Jul 18 '05 #26

P: n/a

"Andrew Dalke" <ad****@mindspring.com> wrote in message
news:bh**********@slb0.atl.mindspring.net...
John Roth
All of the Ruby collections implement a .each method, which is essentially a version of the Visitor pattern. If I want to do something to every element
in a list or a dict (or any kind of collection,) all I have to do is say
something like (using Python syntax):

collectObj.each(<method name>)


Does that mean 'apply the method to each element of my
collection?'? Does it return a new container or modify things
in-place? Is it applied recursively?


I think that's something that each object which implements .each
needs to specify.
And you
have to worry about distinctions between functions and methods. In other
words, it's a mess compared to Ruby.


Where does that distinction come into play? A method is a bound
function, kinda like a curried function with self.


Ruby doesn't have functions in the sense that Python does. Since
a module is treated as a class without instances, module level
functions are class methods: they have the module itself as the instance.

I find this to be a conceptually cleaner way of handling the
issue.
I find C++ methods more confusing, because a reference to a
class method is unbound, when I almost always want it bound.
Well, in C++, there is no class object to bind it to. I think that's
a difficulty in C++, but then, I don't use the language.
Now, you can say: "We've got that with map()." Well, we've got it when
your inputs are either lists (or implement the correct protocol) but the
result is a list, it's not an internal modification to the object's state.
Ahh. Are strings in Ruby mutable or immutable? ... Yup,
looks like it's mutable. From the FAQ

def downer(string)
string.downcase!
end
a = "HELLO"
downer(a)
puts a #=> "hello"

In which case it makes more sense for this in Ruby than in
Python, since

"ABCDEFG".each(f)

can't do that much unless f modifies state, either as a bound
method or tweaking global variable.

Given that rather fundamental difference, an each method
in Python + code blocks wouldn't be any more powerful
than a for statement. The following is possible

def each(container, f):
for i, x in enumerate(container):
container[i] = f(container[i])

but then it requires the container be indexable, which
is stronger than just being iterable.
The major difference is in program expressiveness.
As I said, a For statement is a statement, while .each
is an expression, even when followed by a code block.
There's a considerable difference in the way the program
is laid out, which makes a difference in how easy it is to
determine what is being done.
How do Ruby's associative arrays work when the string used
as the key is mutated in-place? Is it copy-on-write?
I believe that's true for strings: they're used enough that there's
a special provision for them. For other objects, it's up to the
object type to maintain its hash value properly, or to the
application to rehash the dictionary.

I don't really consider this to be the best policy, though.
I like the Python solution better, though: solve the problem
by not allowing mutable values as keys.
To continue on this vein, Ruby directly implements Visitor, Observer,
Delegate and Singleton. I don't particularly like the way it does some
of them, but Python can't claim any one of the four!

The Python approach to a Singleton is called a 'Borg' class.
I knew I should have said: "And don't tell me about Borg.
It's a bloody hack that never should have been invented,
and should be quietly buried at the crossroads with a stake
through its heart now that it's possible to do it properly."
And I have said it before, on this newsgroup, in fact.
The other way to get singletons is with a factory function,
which under Python wouldn't look different than a normal
constructor. I looked at some Java code recently and
wanted to suggest a factory implementation only to realized
that would require a lot of 'new' removals.
Well, yes. You've always been able to do that, and
the Ruby mechanism is basically a class function. The
thing that the __new__() method (and Borg, to give it
its due) does that neither the factory function nor the
alternate constructor does is use the proper convention
for creating the instance: that is, the class's name.

That means that if you want to convert it from a singleton,
you've got a greater chance of having code you don't have
to touch.
Despite my best attempts, I find it almost impossible to slag someone
without including information to back up my view. Eg, I thought my
numbers and trends of mentions of other programming languages was
pretty interesting, but I guess it was of no value to you. :(
I found it interesting, but not to the point. If there is one,
it's simply a question of whether any of the differences are
significant enough so someone who knows one language would
consider switching to another one. Google searches won't tell
you that, only looking for people who've made that switch
will tell you.

And I doubt if you'll find them on this newsgroup. That's the
one problem I have with Brandon's questions. If I wanted
to find out whether someone considered Ruby to be sufficiently
better than Python to switch, I'd look on the Ruby newsgroup,
not this one.

I'm basically taking it from the viewpoint of whether there's
anything in Ruby that I think would be good in Python, which
is a question that might interest people on this NG.

John Roth
Andrew
da***@dalkescientific.com

Jul 18 '05 #27

P: n/a
Bruno Desthuilliers wrote:

PS : Brandon, please make my day and tell me : did I won my place in
your killfile too ?-)


Yes you did. Goodbye!

--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

Jul 18 '05 #28

P: n/a
John Roth wrote:
"Andrew Dalke" <ad****@mindspring.com> wrote in message
Despite my best attempts, I find it almost impossible to slag someone
without including information to back up my view. Eg, I thought my
numbers and trends of mentions of other programming languages was
pretty interesting, but I guess it was of no value to you. :(
I found it interesting, but not to the point. If there is one,
it's simply a question of whether any of the differences are
significant enough so someone who knows one language would
consider switching to another one.


The conclusion around here is pretty ironclad. From a Python standpoint,
Ruby does not matter. And from a technical standpoint, I am not shocked.
Python is already "more exotic" than mainstream industry knows it needs.
Ruby attempts to be "more exotic" than Python. At some point, exoticism is
not what one needs.
Google searches won't tell
you that, only looking for people who've made that switch
will tell you.

And I doubt if you'll find them on this newsgroup. That's the
one problem I have with Brandon's questions. If I wanted
to find out whether someone considered Ruby to be sufficiently
better than Python to switch, I'd look on the Ruby newsgroup,
not this one.


Actually, I didn't think of looking for converts. Rather, I thought of
looking for language wonks who are knowledgeable about Python + other
languages, who had been through their own analysis of the pros and cons
already. And I found some.

But, I will try your idea because it's a good one. Get your marshmellows
out for c.l.p, "Why did you switch from Python to Ruby?"

--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

Jul 18 '05 #29

P: n/a
>>>>> "Bruno" == Bruno Desthuilliers <bd***********@removeme.free.fr> writes:
Istvan Albert wrote:
Erik Max Francis wrote:
What's ***TOTALLY COMPELLING*** about Ruby over Python?

comp.lang.ruby doesn't have Brandon Van Every. LOL

LOL 2 Bruno
(yes, I want to be in Brandon's killfile. It's the new game on clp :
being in Brandon's killfile. Just imagine what will happen when every
clp regulars will be in Brandon's kill file...)


I am not a clp regular (mostly a lurker), but I also wanna play. *please*

;-).

Ganesan

--
Ganesan R

Jul 18 '05 #30

P: n/a
Andrew Dalke wrote:
...
than many consider. Though I know I can't recall needed a
singleton for my code. Maybe I have a different code style?
I've noticed a tendency of mine towards functional programming...


Good program designers rarely NEED singletons -- even when they
tend towards object-oriented rather than functional programming.

Kent Beck's superb "Test-Driven Development by example" book
(Addison-Wesley, highly recommended to everybody!) has this to
say on the subject, as part of an excellent though brief survey
of useful design patterns:
"""
Singleton

How do you provide global variables in languages without global variables?

Don't. Your program will thank you for taking the time to think about
design instead.
"""
This is ALL that Kent's book says on the subject -- and, really, it
SHOULD be all that NEEDS to be said.

The concept of a language that ENCOURAGES you to disregard Kent Beck's
advice, and use Singleton instead of "taking the time to think about
design", is truly appalling.
Alex

Jul 18 '05 #31

P: n/a
> I don't know either. I do know of several posters on the XP
lists, however, who have switched from Python to Ruby, and
I doubt that it was corporate pressure in any of their cases.

If you're interested (which most of the posters here are not -
I'm certainly not) you might check with them. I'm sure Phlip, for
one, would be more than happy to say why he switched, and what
made the difference.

John Roth


Hi, JR!

I got paid to research in Python, for a while, and started using Ruby
as a hobby project on the side - http://flea.sf.net

Python blocks, collections, and indentation all suck, but so do C++
equivalents, and I still use the latter as a hobby language, too.

If you were to instrument my physical responses and typing rate while
coding using Python and Test Driven Development, and compare them to
my responses using Ruby, you'd get close to assessing the subjective
reason I ain't going back.

And I would be interested to see such a comparison between Ruby and
Smalltalk. I can't use the latter, but I suspect Ruby exceeds its
expressiveness, but without the weird syntax.

To reveal objective reasons would lead to tired old threads like this
one. I could never write a paragraph expressing why Ruby is better, or
why this is not a personal taste thing.

The /Programming Ruby/ book says, "Ruby stays out of your way". I know
Python tried to be like that too, but it left in so many little
irritations.

Finally, my TFUI book will use Ruby for its core samples, but
generally written as expressively as possible, so that Pythonics and
others can read it.

I consider this a great improvement over similar books that use that
abomination Java. The elegant simplicity of C++ and the blazing speed
of Smalltalk!

--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces
Jul 18 '05 #32

P: n/a
On Mon, 18 Aug 2003 20:18:09 -0400, "John Roth"
<ne********@jhrothjr.com> wrote:
I've been on c.l.py for around two years. Your statement
is rude and assumes things you have not bothered to check
out.

There is a very simple rule for dealing with trolls, which most
usenet newbies learn sooner or later. If you think someone is
trolling, simply ignore them. Don't answer their posts, don't
comment on them, don't even give them the gratification of
a reply that says: "plonk!" Just killfile them and quit wasteing
bandwidth. You've got better things to do with your time than
maintaining an interaction that you find aggrevating.


You're right, I did make an assumption that you were new to the group.
A lot of people who are new make posts just like you did. Saying we
shouldn't be too harsh on Brandon, after a while they realize maybe he
is just a troll.

Perhaps my post was a bit rude, I shouldn't have automatically assumed
you were new to this NG, although I am a bit baffled at hearing a long
time c.l.p reading calling Every anything but a troll. You have to
admit, that is atypical.
Doug Tolton
(format t "~a@~a~a.~a" "dtolton" "ya" "hoo" "com")
Jul 18 '05 #33

P: n/a
John Roth wrote:
The standard usenet definition of a troll is someone who posts on
a contentious (and usually off-topic) subject with the sole objective
of stiring up reactions.


that's a very limited definition. I prefer this one:

"An internet troll is someone who fishes for people's confidence and,
once found, exploits it"

( from http://www.teamtechnology.co.uk/troll.htm )

</F>


Jul 18 '05 #34

P: n/a
Bruno Desthuilliers <bd***********@removeme.free.fr> pisze:
I am not a clp regular (mostly a lurker), but I also wanna play. *please*

;-).

Easy : answer to any post from Brandon, singing 'Brandon is a troll, is
a troll, is a troll' !-)


Ugh, I cann't... I cann't see his posts, I accidentally pressed 'k'
while reading some of his writings, than accidentally few times pressed
"Enter" followed by "y" key -- of course by accident...
--
Jarek Zgoda
Registered Linux User #-1
http://www.zgoda.biz/ JID:zg***@chrome.pl http://zgoda.jogger.pl/
Jul 18 '05 #35

P: n/a
Jarek Zgoda wrote:
Bruno Desthuilliers <bd***********@removeme.free.fr> pisze:

I am not a clp regular (mostly a lurker), but I also wanna play. *please*

;-).


Easy : answer to any post from Brandon, singing 'Brandon is a troll, is
a troll, is a troll' !-)

Ugh, I cann't... I cann't see his posts, I accidentally pressed 'k'
while reading some of his writings, than accidentally few times pressed
"Enter" followed by "y" key -- of course by accident...

Too bad an accident !-)

Jul 18 '05 #36

P: n/a
In article <gu********************************@4ax.com>,
Doug Tolton <dt*****@yahoo.com> wrote:

Perhaps my post was a bit rude, I shouldn't have automatically assumed
you were new to this NG, although I am a bit baffled at hearing a long
time c.l.p reading calling Every anything but a troll. You have to
admit, that is atypical.


I have been very careful to not label Brandon as a troll.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

This is Python. We don't care much about theory, except where it intersects
with useful practice. --Aahz
Jul 18 '05 #37

P: n/a
Aahz:
I have been very careful to not label Brandon as a troll.


As have I.

Andrew
da***@dalkescientific.com
Jul 18 '05 #38

P: n/a
"Brandon J. Van Every" <va******@3DProgrammer.com> wrote in message
news:bh************@ID-203719.news.uni-berlin.de...
Jeff Epler wrote:
PS I'd just like to state for the record that neither Python nor Ruby
have a totally compelling advantage compared to the following

K&R C


Even as one who hasn't converted to Python yet, that statement is clearly
insane.


Not at all: there are many applications in which K&R C is a more appropriate
language than Python.

Compelling advantages, yes. But "totally" compelling, no: if that were the
case it'd be Python-or-not-at-all in all cases.

James
Jul 18 '05 #39

P: n/a
"Brandon J. Van Every" <va******@3DProgrammer.com> wrote in message news:<bh************@ID-203719.news.uni-berlin.de>...
I'm realizing I didn't frame my question well.

What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes you jump
up in your chair and scream "Wow! Ruby has *that*? That is SO FRICKIN'
COOL!!! ***MAN*** that would save me a buttload of work and make my life
sooooo much easier!"

As opposed to minor differences of this feature here, that feature there.
Variations on style are of no interest to me. I'm coming at this from a C++
background where even C# looks like an improvement. ;-) From 10,000 miles
up, is there anything about Ruby that's a "big deal" compared to Python?

One person mentioned Japanese documentation. I'm sure that's Totally Kewl
to the Japanese....


Negative points earned by using 'frickin' and 'kewl'.

But with an earnest answer to your question - I started evaluating
Ruby about two and a half years ago. For me at the time, the "big
deals" in comparison to Python were:

A unified class hierarchy.
==========================
Python 2.2 started addressing this issue. And it's not one that
absolutely needs to be solved. But it starts making things more
consistent, and we can finally extend core types such as lists and
dictionaries, and legally write new code in C that can be subclassed
in Python.

Ruby has a different concept of modules than Python. In Ruby, a
Module is usually a class-like object that is mixed in, allowing for
multiple inheritance type functionality in a single inheritance
system. What's nice is that Ruby offers some very nice common built
in modules that you can reuse in your own classes, such as
'Comparable' (offering overloads for comparison operators),
'Enumerable' (offering a lot of Python built-in functions as methods
for collections of objects - equivalents of map(), min(), max(),
etc...), and more.

A pure pure pure OO system is a nice dream, and this feature makes
Ruby closer in it's OO offerings to Smalltalk than to Python. But I
have to admit that I actually prefer Python's module/package based
system better (I'll address this further down).
getter/setter methods for object attribute access
=================================================
This is another feature offered by Python 2.2 and later, in new style
classes. A problem that plagued Zope for a while was one didn't know
if a certain common attribute would be an attribute, or a method -
foo.title versus foo.title(). Some objects want to compute their
title, or other attributes (ie - you may store a mailbox size
attribute as bytes, but present it as megabyte to make it easier to
view/edit - so why not compute?). Since Python 2.2 now offers this
feature, which is not a critical one (just one that's quite nice),
Ruby doesn't score too many points here any more either. But it was
something that I liked when first evaluating the language.

Static/Class methods
====================
Python 2.2 and later finally allow these as well. In a pure OO system
like Ruby and Java, static method are very important when offering
what would be module-level functions in Python. Basically, they're
methods defined in a class that don't operate on an instance
(typically the 'self' in Python).

Class Methods operate on a class object instead of an instance.
Between static and class methods, for example, you can define new
constructors and place them in the class itself (not possible in older
Python or old style classes). So what Ruby, Java, Objective-C, and
other languages can offer are things like::

MyString.initFromFile(somefile)
MyString.initFromURL(someurl)

which would generate a new 'MyString' instance based on the contents
of a file or URL. Python 2.2 has caught up on this feature as well.
As others have stated - it's certainly *prettier* to define these
types of methods in Ruby, but I imagine Python will improve in this
area as time goes by. It's just nice to have these features
available.
Generators
==========
Another cool feature that Ruby had that fascinated me when I looked at
it that Python 2.2 coincidentally picked up. This is the 'yield'
keyword, and it produces a lot of opportunities for lazily generating
data to be iterated through. Again - Python 2.2 and later have this
one, so it's a moot point now. But this was something that really
excited me about Ruby when I saw it.
'blocks'
========
blocks...closures...anonymous functions. Whatever you want to call
them, Ruby employs them throughout the language. These have been
discussed en masse in this thread, I'm sure. It's no longer a deal
breaker for me. For the most part, if a lambda or list comprehension
expression don't offer me enough, writing a real named Python function
is the better route to go, in my opinion.

You can do a lot with lamda: expressions, and many parts of the system
allow them (including the re module, where you can supply a function
that takes a regex match object as its argument and do some
calculations on it).
import re
flan = "I'm some flan & I'm < half off."
nonword = re.compile('\W')
quoted = nonword.sub(lambda m:'&#%s;' % ord(m.group(0)), flan)
quoted 'I'm some flan & I'm < half off.'

Of course, for any detailed function, it's still better to write a
full one:
def quoter(matchobj): .... """ look up values we know names for before using ord() """
.... good_values = {
.... ' ': ' ', '<': '&lt;', '>': '&gt;', '"': '&quot;'
.... }
.... match = matchobj.group(0)
.... return good_values.get(match, "&#%s;" % ord(match))
.... nuquoted = nonword.sub(quoter, flan)
print nuquoted

I'm some flan & I'm &lt; half off.

In-Place versus Copy
====================
There's a long running Python situation where one wants a sorted list
in the middle of an expression, for the sake of the expression only.
Python only lets you do "foo.sort()" as a statement on its own. If
you use this in an expression, it evaluates to "None", not a sorted
list. Little battles over this show up on occasion in the Python
world and have since the beginning of time.

In Ruby, there's a difference between "foo.sort" and "foo.sort!"
(parenthesis aren't required on method calls in Ruby). Ruby can use
some punctuation in its method names, and the exclamation point is
often used to indicate that this method will change the current
object. "foo.sort!" in Ruby is equivalent to "foo.sort()" in Python
(assuming 'foo' is a list).

This isn't a huge dealbreaker in favor of Ruby. It's just nice. The
use of punctuation to differentiate between inplace operations and
i'll-return-a-new-modified-copy operations is a nice one. (Ruby also
can have method names end in '?', which is often used for boolean
methods. 'foo.isEmpty?' for example.)
Ruby Issues and Python Strengths
================================
Ruby has a lot more issues for me now, and Python has some really
strong features that differentiate it. Some of these features, in
fact, go almost unnoticed because they're so smooth and make so much
sense (see coming remarks about modules).

Ruby is still more closely related to Perl than it is to Python. Ruby
uses all of those shortcut expressions that I find terrible, like $_.
Ruby uses other punctuation marks to mark what different variables,
with name, $name, @name, and @@name all being different. While it's
nice to differentiate between local, global, instance, and class
variables, all of these extra punctuation 'shortcuts' get in the way
of readability. In fact, it looks like it's quite easy to write
unreadable code in Ruby. There are just lots of punctuation marks one
has to get used to, and while it's easy to get used to them, I think
it moves Ruby away from the "executable pseudocode" that most decent
Python code can be. You wind up with statements like ``%w{@names}``
or ``print if ($. == 1)``. dollar-dot? what's that? Fortunately,
Python's general "explicit is better than implicit" design means I
never have to know.

Ruby still has too much shell-script nature inside of it. One built
in Ruby expression type is command expansion, or `foo`, where foo is a
shell command. (You can also use %x, as in %x{echo "Hello There"}).
Putting `uname -v` in your code will execute the Unix 'uname' command.
The exit status of the command is in the cheerful global variable $?.
As a result, I wonder how well Ruby works as an embedded language.
Python and its sibling Jython have been embedded in a variety of
systems to allow programmability. Some examples of this include 3D
environments (I think 'Caligari Truespace' is one of these), UML
tools, and more. In such systems, you don't want shell commands to be
run. Yet Ruby has them as first class expressions. Python places
operating system interaction into the flexible 'os' and 'os.path'
modules, and there are the newer 'popenN' modules as well for running
other processes from Python and getting the results back in. But -
it's a very key feature of Python that it is not bound strongly to the
Unix shell in any way. I don't know how much the `command` feature of
Ruby is used, but it's still troubling (to me) that it is a first
class expression.

Python has modules. I love this fact about it. It got even better
when multi-level packages were added as a core feature to the system.
I don't know why, but using ``import package.module`` or ``from
package.module import Class`` makes me so much happier than the
alternatives I see in Ruby, Perl, and PHP. But Python modules and
packages just add a nicer element to the language, and I believe that
Modula 2 and/or 3 was one of the linguistic influences on Python.

Ruby has two statements, and they just bother me. They seem to be
nowhere nearly as clean as Python modules (or even Java packages):
'load' and 'require'. And they seem to behave slightly differently.

load "filename.rb" "includes the name Ruby source file every time the
method is executed". I wonder if that's a full path expression, like
if you could do ``load "mypackage/file.rb"``, and if that expression
would fail on Windows or the classic Mac OS (or any other operating
system that uses a different path separator than Unix). Python
Modules are free of that.

require "filename" seems not to require the '.rb' extension, and seems
closer to Python's imports, but I don't think it puts anything into a
special namespace. With Python, you have to explicitly load blindly
into your namespace with the "from foo import *" syntax. But it looks
like if you do a ``require 'tk'`` command in Ruby, you're doing the
equivalent of "from tk import *".

Ruby has modules, but in a completely different sense than Python.
Modules are namespaces defined within files, which can also be used as
mix-ins to classes. While Python makes all subelement traversal use
the '.' syntax (package.module.Class, instance.someMethod, etc), Ruby,
adds more punctuation to get into modules, using the :: syntax
(NameSpace::Example::CONST or NameSpace::Example.new). Man, the more
I write, the more I really appreciate the simplicity of Python. We
will do funny things with __underscores__, but even that's pretty
consistent.

Python also has the nice feature of compiling/caching modules, which
can speed things up. I don't know if Ruby re-evaluates all code every
time you start a Ruby program up, but I haven't really seen an
equivalent to Python's '.pyc' and '.pyo' (optimized, generated when
running with the -O option in Python) files.

Ruby does have some nice things going for it, and I think that people
looking for a good object oriented Perl would be happy with it.
Personally, I think that Python is more mature, has better design
influences (Modula and ABC instead of Perl and Smalltalk). A lot of
the extraordinary features of Ruby seem to have found their way into
recent Python versions. Python's built in OS abstraction layers (the
'os' module, etc) makes it easier to write multiplatform code (made
even easier by universal newline support in Python 2.3, which helps
deal with the "'\r', '\n', or '\r\n'?" situation). Python's explicit
nature makes following code a lot easier - it's *usually* pretty easy
to tell where a name is coming from, for instance. And it does all of
this without abusing the sunday comic curse word character set
{$@#:!}. Ruby also seems to have some other implicit behaviors,
like::

def mult(n, fact)
n * fact
end

the last statement in an expression is what's returned. You *can* use
a return statement. But it's nice that Python always requires it
(otherwise, you get 'None' as a result):

def mult(n, fact):
return n * fact

it's just a nice touch. It's especially nice when you have to go into
systems like Java and you have variables being used that take a while
to process - "where's this name coming from? Oh, it's somewhere
within the class, not local!". self.doThis() is much more
understandable than just doThis(), especially when you start to stack
up namespaces.

In summary - there's nothing totally compelling about Ruby over Python
for me, especially since Python 2.2 and 2.3 have come along and
answered my own petty grievances. There are some cool features and
aspects of Ruby, to be sure, but I'm pretty happy where I am.

And Python always equals = batteries included!
92.7 times out of 103.5, there's a module that shipped with the
distribution that will do something that you need to do. Time and
again, I hear stories of "I was just about to write a whole blablabla
module when it turns out that one was already there!"

--
J.Shell
Jul 18 '05 #40

P: n/a
Jeffrey P Shell wrote:

[an excellent, lengthy article contrasting Python and Ruby]

Article saved permanently. This is the only good thing to
come out of this thread so far. Thanks Jeffrey!

-Peter
Jul 18 '05 #41

P: n/a
Jeffrey P Shell wrote:
Ruby is still more closely related to Perl than it is to Python.
I think for many people, it all boils down to this. Whoever hates Perl
will find Python more interesting. Whoever loves Perl, or uses/has used
Perl, will find Ruby more welcoming.

I for one am a Perl programmer. I have tried to use Python as much as I
could for several months but just could not get as productive as I am in
Perl. Hell, I could not even put 'if ... else ...' on the same f*cking
line! :)
Ruby
uses all of those shortcut expressions that I find terrible, like $_.
Ruby _does_ try hard to be a better Perl. This includes providing $_ and
many other Perl stuffs. However, the more I use Ruby over time, the less
I use those.

What I like about Ruby is that, despite it brings many features from
Perl, it still manages to be pretty clean design-wise. The features are
often layered on top of the OO system (e.g: /.../ is a shortcut for
creating a Regexp object). And they are all optional to use. Surely one
is not forced to use it. But I understand that there are people who just
can't stand the fact that those features _exist_ in the language.
Ruby uses other punctuation marks to mark what different variables,
with name, $name, @name, and @@name all being different. While it's
nice to differentiate between local, global, instance, and class
variables, all of these extra punctuation 'shortcuts' get in the way
of readability.
Ah, but this improves readability for me. Some people might also argue
that all those underscores in Python code reduces readability. And how
many threads are lost for people complaining about having to write
'self.foo' all the time? ;-)
Ruby still has too much shell-script nature inside of it.
Yes. And I love it :)
in Ruby expression type is command expansion, or `foo`, where foo is a
shell command. (You can also use %x, as in %x{echo "Hello There"}).
Putting `uname -v` in your code will execute the Unix 'uname' command.
The exit status of the command is in the cheerful global variable $?.
As a result, I wonder how well Ruby works as an embedded language.
Not very badly, I think. mod_ruby, eruby, pl-ruby, jruby, ... Though the
last one is nowhere near usable as Jython right now.
(NameSpace::Example::CONST or NameSpace::Example.new). Man, the more
I write, the more I really appreciate the simplicity of Python. We
will do funny things with __underscores__, but even that's pretty
consistent.
And what's not consistent about :: for namespace separator, $ for global
vars, @ for class vars, and so on?
Python also has the nice feature of compiling/caching modules, which
can speed things up. I don't know if Ruby re-evaluates all code every
time you start a Ruby program up, but I haven't really seen an
equivalent to Python's '.pyc' and '.pyo' (optimized, generated when
running with the -O option in Python) files.
This is a purely implementation issue, not the issue with the language
itself. Currently Ruby does not have a VM yet, so it does not have
bytecode compilation. But it will in Ruby 2.0. The current
implementation of Ruby (Ruby 1.x) is admittedly not very fast, but it's
already much faster & efficient than Python for some things (like
creating and destroying objects/classes).
Ruby does have some nice things going for it, and I think that people
looking for a good object oriented Perl would be happy with it.
Personally, I think that Python is more mature, has better design
influences (Modula and ABC instead of Perl and Smalltalk).
Ruby is also largely influenced by LISP.
def mult(n, fact)
n * fact
end

the last statement in an expression is what's returned. You *can* use
a return statement. But it's nice that Python always requires it


This is also one of the thing I hate in Python :)

--
dave

Jul 18 '05 #42

P: n/a
Jeffrey P Shell wrote:
"Brandon J. Van Every" <va******@3DProgrammer.com> wrote in message news:<bh************@ID-203719.news.uni-berlin.de>...

I'm realizing I didn't frame my question well.

What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes you jump
up in your chair and scream "Wow! Ruby has *that*? That is SO FRICKIN'
COOL!!! ***MAN*** that would save me a buttload of work and make my life
sooooo much easier!"

As opposed to minor differences of this feature here, that feature there.
Variations on style are of no interest to me. I'm coming at this from a C++
background where even C# looks like an improvement. ;-) From 10,000 miles
up, is there anything about Ruby that's a "big deal" compared to Python?

One person mentioned Japanese documentation. I'm sure that's Totally Kewl
to the Japanese....


Negative points earned by using 'frickin' and 'kewl'.

But with an earnest answer to your question - I started evaluating
Ruby about two and a half years ago. For me at the time, the "big
deals" in comparison to Python were:


An excellent answer and a great read, Jeffrey. Thanks.

-- Graham
Jul 18 '05 #43

P: n/a
David Garamond:
Ah, but this improves readability for me. Some people might also argue
that all those underscores in Python code reduces readability. And how
many threads are lost for people complaining about having to write
'self.foo' all the time? ;-)
What if you had your editor expand '@' into 'self.'? (Not something
I would do.)

And how many Ruby threads are lost for people complaining about
having to write 'end' <wink>.
As a result, I wonder how well Ruby works as an embedded language.


Not very badly, I think. mod_ruby, eruby, pl-ruby, jruby, ... Though the
last one is nowhere near usable as Jython right now.


When I looked at Ruby a few years ago, I had concerns about
how its thread system (a platform independent/non-native) system
would interact with, say, POSIX threads or with an in-proc COM
server. I never found out the answer for that.

I also had concerns with its non-ref-count based garbage collection
for C extensions, because the C/Fortran libraries I use most often
for chemistry only pass opaque integer tokens around, and not raw
pointers, so there's no way for Ruby to know when to dealloc
things or what the proper deallocation order would be.
And what's not consistent about :: for namespace separator, $ for global
vars, @ for class vars, and so on?
Python gets away with doing the :: and @ with just a name and
a period.

'x' is local or global
'x.y' is the 'y' thingy in 'x', and 'x' could be a module, a class,
or an instance

So the inconsistency, from a Python view, is that the "get something
from something else" is written in different ways depending on
the source of the data.
The current
implementation of Ruby (Ruby 1.x) is admittedly not very fast, but it's
already much faster & efficient than Python for some things (like
creating and destroying objects/classes).


How is that tested? I hear that new-style classes for Python are
faster than old ones. Still, I decided to test out object creation
on a machine which has an older version of Python and of Ruby
installed.

%python -V
Python 2.2.2
%ruby --version
ruby 1.6.5 (2001-09-08) [i386-freebsd4.4]
%
%cat t.py
class Qwerty:
def __init__(self, name):
self.name = name

for i in xrange(1000000):
Qwerty("shrdlu")

%cat t.rb
class Qwerty
def initialize(name)
@name = name
end
end

for i in 0...1000000
Qwerty.new("shrdlu")
end
%time python t.py
3.303u 0.000s 0:03.42 96.4% 774+1008k 0+0io 0pf+0w
%time ruby t.rb
3.466u 0.185s 0:04.25 85.6% 5+889k 0+0io 0pf+0w
%

I deliberately chose Python code known to be slow.
Here's the faster version

%cat t.py
class Qwerty:
def __init__(self, name):
self.name = name

def main():
for i in xrange(1000000):
Qwerty("shrdlu")

main()
%time python t.py
2.929u 0.000s 0:03.36 86.9% 773+1008k 0+0io 0pf+0w
%

Faster because 'i' is in local namespace (simple offset
lookup in the list of local variables) vs. global namespace
(dictionary lookup). Deliberately chosen because I don't
know if Ruby has similar differences.

Andrew
da***@dalkescientific.com
Jul 18 '05 #44

P: n/a
A nice feature of Ruby is that exceptions are resumable like in
Smalltalk, ie. you can have a "retry" statement in your exception
handling that allows you to "try again".

http://www.rubycentral.com/book/tut_exceptions.html
Jul 18 '05 #45

P: n/a
In article <81************@darwin.lan.kassube.de>,
Nils Kassube <ni**@kassube.de> wrote:
A nice feature of Ruby is that exceptions are resumable like in
Smalltalk, ie. you can have a "retry" statement in your exception
handling that allows you to "try again".

http://www.rubycentral.com/book/tut_exceptions.html


I suppose this is nice, but does it really give you anything you
couldn't get in a slightly different way by just enclosing the whole try
construct in a loop?

while 1:
try:
do stuff
break
except:
fix the problem

If "do stuff" throws an exception, the "fix the problem" code runs and
then you try "do stuff" again. It even suffers from the same potential
infinite loop problem the Ruby version has :-)
Jul 18 '05 #46

P: n/a
Roy Smith <ro*@panix.com> writes:
I suppose this is nice, but does it really give you anything you
couldn't get in a slightly different way by just enclosing the whole try
construct in a loop?


You are correct. The exception handling in Python is as powerful as in
Ruby. However, Ruby's way seems more beautiful to me. Another example:
in Python you have to nest multiple try/except statements, in Ruby you
can have multiple rescue blocks. It just looks better. (For my eyes.)
Jul 18 '05 #47

P: n/a
On Mon, 18 Aug 2003 16:22:01 -0400, rumours say that "John Roth"
<ne********@jhrothjr.com> might have written:
All of the Ruby collections implement a .each method, which is essentially
a version of the Visitor pattern. If I want to do something to every element
in a list or a dict (or any kind of collection,) all I have to do is say
something
like (using Python syntax):

collectObj.each(<method name>)


You can do similar things in Python, just wrap your collection in a
class. Check this module:

http://www.sil-tec.gr/~tzot/python/predicates.py

See the test cases after the line
if __name__ == "main":

Does this work for you? Esp. the do method.

PS I don't believe that the my final test labeled "Tricky" works, but
RSN I'm going to work on it :)
--
TZOTZIOY, I speak England very best,
Microsoft Security Alert: the Matrix began as open source.
Jul 18 '05 #48

P: n/a
On Mon, 18 Aug 2003 14:55:21 -0700, rumours say that "Brandon J. Van
Every" <va******@3DProgrammer.com> might have written:
Istvan Albert wrote:
Erik Max Francis wrote:
What's ***TOTALLY COMPELLING*** about Ruby over Python?

comp.lang.ruby doesn't have Brandon Van Every.


Erik has been in my killfile forever, from other newsgroups. I even had to
put him back in after letting him out. I thought a year would have been
enough, but apparently not.
LOL

Istvan.


So, you're guilty by association. Goodbye!


Brandon,

I have no reason to call you names, and I won't bother pretending to be
a practical psychologist laying out my opinion about your social
interoperability; however, I will give your sense of humour a test :)

You have reported that you once in a while lose your killfile[1] because
of newsreader changes, "OS" (quotes intended to humour MS Windows)
reinstallations etc. A way to do comparisons between two languages is
to test them on practical matters. So, based on that periodical loss of
killfile, and on your keen-ness of informing your "victimfiles", I have
an idea for you.

Write a program in Python and Ruby that reproduces anytime your killfile
by googling your posts and selecting those containing a combination of
the words "killfile", "killfiling", "goodbye" and possibly "plonk!"
(don't know if you use that one); these are replies to people you
killfiled.
In the process, taste the languages. Request for support in the groups
(disabling temporarily your newly recreated killfile :). Join the
communities. Share the experience. Answer yourself your own questions
--and CC the groups in that answer!

I can't talk for Ruby, but I have lived the above for Python (and for a
long time just by lurking in the group; we're different in that, but I
don't imply I'm better than you). Ruby sounds interesting, but Python
has my heart (yes, geeks fall in love with computer languages, just like
with any other human product for which a lot of craftsmanship has been
invested).

Now, after all the sweet talk, I'll show you my true teeth (I'm a faulty
lying human sun of a beach after all) and tell you: "Stop believing
you're a leader and a lone wolf; there can't be two of us" :)

Cheer up, man. If people disappoint you, don't shut them off your
world; try charming them, for a change.
[1] It was you who reminded me the word "killfile"; I really had
forgotten about it and *plonk* etc, because c.l.py (ok, and a.h.bou)
have been the only ng's I invest time in lately...

....and PS: <me looking at the director>: "was that OK? or did I sound
too hippy? perhaps we should lose the San Francisco background and,
people, somebody stop the Ten Years track, OK??!"
--
TZOTZIOY, I speak England very best,
Microsoft Security Alert: the Matrix began as open source.
Jul 18 '05 #49

P: n/a
On Sat, 23 Aug 2003 03:34:02 +0300, I said:
Ten Years track


and I meant Ten Years AFTER.
--
TZOTZIOY, I speak England very best,
Microsoft Security Alert: the Matrix began as open source.
Jul 18 '05 #50

54 Replies

This discussion thread is closed

Replies have been disabled for this discussion.