: Can anyone give me a good reason why I would want to use Ruby over
Python?Ruby smells better than Python. Also, it has cuter girls.
Python sometimes tastes better if you prepare it right.
I hadn’t noticed the odor thing. It does have a faintly floral aroma
doesn’t it.
Of course it is no surprise that you can get more and cuter girls with
Rubies than you can with Pythons.
Scott
Careful, boys,
There are some girls listening in on this and watching every move.
LOL
No…I’m not Kent Starr. Just what’s left behind since he passed on.
Regards,
Mary Dixon
http://rubyforge.org/projects/colorparser/
On 8/28/03 8:56 PM, “Scott Thompson” easco@mac.com wrote:
: Can anyone give me a good reason why I would want to use Ruby over
Python?Ruby smells better than Python. Also, it has cuter girls.
Python sometimes tastes better if you prepare it right.
I hadn’t noticed the odor thing. It does have a faintly floral aroma
doesn’t it.Of course it is no surprise that you can get more and cuter girls with
Rubies than you can with Pythons.Scott
W. Kent Starr wrote:
Careful, boys,
There are some girls listening in on this and watching every move.
LOL
No…I’m not Kent Starr. Just what’s left behind since he passed on.
Regards,
Mary Dixon
http://rubyforge.org/projects/colorparser/
Girl … Pythons? That bite? Ouch! Careful, I’m holding a Ruby! Will chip
the fangs…
Ok, so I guess my question is mostly answered. Not much difference except
for personal preferences and the like.
I don’t want to start an rwar – really. Was looking for an honest,
objective answer, that is all.
-Fred
–
Shameless plug:
http://JobMarketIntelligence.com
A database of high-tech firms at your fingertips.
Fred wrote:
Ok, so I guess my question is mostly answered. Not much difference except
for personal preferences and the like.I don’t want to start an rwar – really. Was looking for an honest,
objective answer, that is all.
Given the permathread nature of this topic, I’ve put some links here:
http://www.ruby-doc.org/RubyEyeForThePythonGuy.html
James
-Fred
In article 3F503BB7.7010606@ruby-doc.org,
Fred wrote:
Ok, so I guess my question is mostly answered. Not much difference except
for personal preferences and the like.I don’t want to start an rwar – really. Was looking for an honest,
objective answer, that is all.Given the permathread nature of this topic, I’ve put some links here:
http://www.ruby-doc.org/RubyEyeForThePythonGuy.html
James
LoL 
Does this mean that Rubyists are better at interior decorating? 
Seriously, This link on your page:
http://onestepback.org/index.cgi/Tech/Ruby/PythonAndRuby.rdoc
I found to be one of the most concise descriptions of the main difference
between Python and Ruby.
Phil
Phil Tomson wrote:
In article 3F503BB7.7010606@ruby-doc.org,
…Given the permathread nature of this topic, I’ve put some links here:
http://www.ruby-doc.org/RubyEyeForThePythonGuy.html
James
LoL
Does this mean that Rubyists are better at interior decorating?
Well, I happen to think that Rubyists just have better taste. Wouldn’t
surprise me if that went beyond mere language choice.
Seriously, This link on your page:
http://onestepback.org/index.cgi/Tech/Ruby/PythonAndRuby.rdocI found to be one of the most concise descriptions of the main difference
between Python and Ruby.
Glad to hear that. I’ve only limited experience with Python, so if
anyone with real knowledge of both Ruby & Python can comment on the
links, or offer others, it would be appreciated. You needn’t do it on
this list; E-mail if you like.
James
“jbritt@ruby-doc.org” jbritt@ruby-doc.org wrote in message news:3F519252.3090408@ruby-doc.org…
Well, I happen to think that Rubyists just have better taste. Wouldn’t
surprise me if that went beyond mere language choice.
Even if you meant that as a joke, the statement is actually at
the root of language wars. No sane people would argue tens of
messages that pie is better than cake. People have finally understood
the differences between tastes, regarding edible things (ok, some
snobs may state that people who like caviar have better taste than
those who don’t, but those are not in the majority).
But when it comes to languages, there are just people with better
taste and people with worse taste. Language choice is often
based on some kind of meta-science. You can prove that something
can be expressed more compactly in Perl than in C++. Yet you can
show that there has been many excellent libraries made with C++,
that, when finished, are elegant to use and couldn’t have been
made as nicely with Perl. Then people also like to go into the
fuzzier regions like “Python is easier to read than Ruby”, stating
this as a fact of course.
Unless a language can be shown to be able to make a lot better
abstractions without reducing readability or comprehensability
(already a hard task to show objectively), then little can be said
about what language is better. Take Python and Ruby comparisons,
for example. These languages differ only in subtleties like
indentation vs blocks, self vs @, or Ruby’s “pure OO” vs
Python’s “almost pure OO” (that many consider very pure),
which bears little or no meaning in actual code. I’ve actually
seen a lot less arguments between C++ and Ruby/Python, as I’ve
seen between Ruby and Python. That alone goes to show that
the lenghtiest arguments arise from the most insignificant details.
I was quite humoured by this article:
http://www.cs.washington.edu/homes/kd/courses/pythonruby.pdf
It said having to use abs(-5) instead of -5.abs is a “major problem
with Python”. And I’m afraid they were serious, even though that’s
not far from begin complete nonsense. They were not concerned with
the syntactic difference between overloaded operator calls and normal
function calls, for example. Or that some might actually prefer abs(x).
Oh boy, would they enjoy Lisp or Scheme. For some reason, most of us
don’t.
Hannu Kankaanpää wrote:
Even if you meant that as a joke, the statement is actually at
the root of language wars. No sane people would argue tens of
messages that pie is better than cake.
You assume that programmers are sane.
But when it comes to languages, there are just people with better
taste and people with worse taste. Language choice is often
based on some kind of meta-science. You can prove that something
can be expressed more compactly in Perl than in C++.
But you can’t prove that “more compact” is “better.”
I was quite humoured by this article:
http://www.cs.washington.edu/homes/kd/courses/pythonruby.pdf
I will read that.
I am sure you will be humoured by many of the replies
to your post also.
Hal
I was quite humoured by this article:
http://www.cs.washington.edu/homes/kd/courses/pythonruby.pdfIt said having to use abs(-5) instead of -5.abs is a “major problem
with Python”. And I’m afraid they were serious, even though that’s
not far from begin complete nonsense.
They also seemed to be offended by being able to type
print “Hello world”
Though from their second alternative I guess they weren’t aware that you can
write
STDOUT.print “Hello world”
Though IMHO having to write STDOUT all the time would get tiresome very
quickly (and “hello world”.print just looks weird)
So I’d say that Ruby has the right balance of purity and practicality.
They were not concerned with
the syntactic difference between overloaded operator calls and normal
function calls, for example. Or that some might actually prefer abs(x).
Oh boy, would they enjoy Lisp or Scheme. For some reason, most of us
don’t.
Best Regards
Mark Sparshatt
On Monday 01 Sep 2003 9:47 am, Hannu Kankaanpää wrote:
Heh. It does wear its bias a little obviously, doesn’t it?
“Ruby supports Arrays and associative arrays (Hash). Python has Lists
and Tuples which are the same as arrays.” Er, yes, and Python has
dictionaries, too, which are the same as associative arrays, so the
apparent point in favour of Ruby is spurious…
On 1 Sep 2003 01:36:28 -0700, hanzspam@yahoo.com.au (Hannu Kankaanpää) wrote:
I was quite humoured by this article:
http://www.cs.washington.edu/homes/kd/courses/pythonruby.pdf
mark wrote:
I was quite humoured by this article:
http://www.cs.washington.edu/homes/kd/courses/pythonruby.pdfIt said having to use abs(-5) instead of -5.abs is a “major problem
with Python”. And I’m afraid they were serious, even though that’s
not far from begin complete nonsense.They also seemed to be offended by being able to type
print “Hello world”
Though from their second alternative I guess they weren’t aware
that you can
writeSTDOUT.print “Hello world”
Though IMHO having to write STDOUT all the time would get tiresome very
quickly (and “hello world”.print just looks weird)So I’d say that Ruby has the right balance of purity and practicality.
They were not concerned with
the syntactic difference between overloaded operator calls and normal
function calls, for example. Or that some might actually prefer abs(x).
Oh boy, would they enjoy Lisp or Scheme. For some reason, most of us
don’t.
Regardless of their concluding paragraph, the body of the article still read
more like an endorsement of Ruby.
But, perhaps I’m biased…
Curt
On Monday 01 Sep 2003 9:47 am, Hannu Kankaanpää wrote:
mark wrote:
I was quite humoured by this article:
http://www.cs.washington.edu/homes/kd/courses/pythonruby.pdfIt said having to use abs(-5) instead of -5.abs is a “major problem
with Python”. And I’m afraid they were serious, even though that’s
not far from begin complete nonsense.They also seemed to be offended by being able to type
print “Hello world”
Though from their second alternative I guess they weren’t aware that you can
writeSTDOUT.print “Hello world”
Though IMHO having to write STDOUT all the time would get tiresome very
quickly (and “hello world”.print just looks weird)So I’d say that Ruby has the right balance of purity and practicality.
They were not concerned with
the syntactic difference between overloaded operator calls and normal
function calls, for example. Or that some might actually prefer abs(x).
Oh boy, would they enjoy Lisp or Scheme. For some reason, most of us
don’t.
I think the author was a little mistaken about Ruby though. You don’t
call methods of a numerical object to perform most math operations like
sin and such. That’s all provided by the Math module (unless things
have changed since Dave and Andy’s “Programming Ruby”). -5.abs is the
only math-like method of a number, as far as I know.
I didn’t agree with the “Hello world” example either. I don’t think
it’s a question of how you perform tasks with an object as much as which
module’s job is it to do what. OOP doesn’t mean every object needs a
method for everything that can possibly be done with itself.
In my opinion, -5.abs seems right; -5 and 5 are the same, except one has
the property of being negative and the other does not. It makes sense
to me that -5 would know how to represent itself without it’s negative
property. The object holds the value 5, with a property that equates to
“negative=true”.
Along that same line of thinking, sin(5) seems right too. sin(5) is NOT
the same as 5, and I don’t expect 5 to know how to the result of its
sine function result. That’s the job of a math module.
The method print doesn’t seem to me to belong, logically, to the string
“Hello world”, so I don’t expect the string to know how to print itself.
It does seem to me to belong as a method of $stdout, however.
I remember back in the early 90’s when I first dove into C++, there
seemed to be this thought process regarding OOP that went something
like: every object should be able to stand alone and interact rarely, if
ever, with anything else because that would break the object’s
encapsulation. I got that feeling from several texts, and I thought it
ludicrous at the time, and still do. As things have evolved, it seems
common sense has stepped in to replace those purist theories, but that
article really took me back to that time.
Sean O'Dell
On Monday 01 Sep 2003 9:47 am, Hannu Kankaanpää wrote:
Your original interpretation of the idea of encapsulation is one that I
find held by a lot of folks that are new to object-oriented programming
as you no doubt were in the early 90’s. The ideas may have been
presented improperly, or you may have misinterpreted them, but the
ideas are not ludicrous unless you take them to an illogical extreme.
The idea is that every object should encapsulate a single idea, a
cohesive concept, and should not have to look outside of itself to
implement that concept. If it does, then it will have to expose
implementation details of itself to others through it’s public
interface. Once you do that you have violated encapsulation.
It is not the idea that objects should interact with other objects
rarely. Obviously if that were true then you would have system that
never did anything :-).
Rather it’s along the same lines as Einstein’s “Make things as simple
as possible but no simpler”, the idea is that objects should interact
with other objects as little as possible and certainly NOT as a means
of implementing behavior that should be the province of the object
itself.
The other way I’ve heard it described is with the terms Coupling and
Cohesion. With all due respect to Dirk Gently, Coupling refers to the
interconnectedness of all things within your program. Cohesion refers
to keeping related data, objects, behaviors, etc… together in tightly
related groups. An ideal system will have have very low coupling,
passing as few messages between objects as necessary to get the job
done, and have very high Cohesion, with related data and behaviors
collected into logical containers.
As with most things, however, this is more an organizing principle than
a hard and fast rule. There are a thousand things that, under any
given set of circumstances, can call for coupling than one might like
to have, or less cohesion. The concepts, however, are valuable to keep
in mind.
Scott
.
On Sep 1, 2003, at 3:29 PM, Sean O’Dell wrote:
I remember back in the early 90’s when I first dove into C++, there
seemed to be this thought process regarding OOP that went something
like: every object should be able to stand alone and interact rarely,
if ever, with anything else because that would break the object’s
encapsulation. I got that feeling from several texts, and I thought
it ludicrous at the time, and still do. As things have evolved, it
seems common sense has stepped in to replace those purist theories,
but that article really took me back to that time.
No, I think the /article/ was biased
On Tue, 2 Sep 2003 04:21:02 +0900, “Curt Hibbs” curt@hibbs.com wrote:
Regardless of their concluding paragraph, the body of the article still read
more like an endorsement of Ruby.But, perhaps I’m biased…
Sean O’Dell wrote:
The method print doesn’t seem to me to belong, logically, to the string
“Hello world”, so I don’t expect the string to know how to print itself.
It does seem to me to belong as a method of $stdout, however.
There’s a series of articles [0] by Alan Holub about writng UI, based on
the idea that an object should know how to render itself. In it, Holub
claims,
[quote]
I’ll explain the whys and wherefors in a moment, but here are some rules
of thumb that you can apply to see if you’re really looking at an
object-oriented system:
[quote]
(Also, see Dave & Andy’s discussion [1] of Tell, Don’t Ask. )
I remember back in the early 90’s when I first dove into C++, there
seemed to be this thought process regarding OOP that went something
like: every object should be able to stand alone and interact rarely, if
ever, with anything else because that would break the object’s
encapsulation. I got that feeling from several texts, and I thought it
ludicrous at the time, and still do. As things have evolved, it seems
common sense has stepped in to replace those purist theories, but that
article really took me back to that time.
It’s true there are countless possible messages one could send to a
String object, so having String know about all of them in advance is too
much. (There’s been a similar discussion on ruby-talk regarding math
functions)
And while the convention in many langauges has been to pass a String
object to an IO object, it may be more appropriate to do it the other
way around, and just call String.print or String.print( someIoObject )
Luckily, it’s dead simple to add this to your code by enhancing the
String class.
class String
def print( io=$stdout )
io.puts( self )
end
end
I’ve been doing this sort of thing in my code, and after a while it
struck me as common sense, not purist theory. I find it goes a long
way towards cleaning up or avoiding procedural code where I want OO, and
I find it easier to read.
As Holub states, “I should say that although the foregoing attitude
might sound extreme, my ideas don’t stem from some academic notion of
purity; rather, every time I’ve strayed from the straight and narrow in
my own work, I’ve found myself back in the code fixing it a month or two
later. All of this do-it-wrong-then-go-back-and-fix-it work just started
taking up too much time. It turned out to be easier to just do it right
to begin with. My notions, then, are based on practical experience
gathered while putting together working systems, and a desire to put
those systems together as quickly as possible.”
That’s pretty much how it’s worked for me.
James
[0] http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox_p.html
[1] http://www.pragmaticprogrammer.com/ppllc/papers/1998_05.html
Sean O'Dell
Scott Thompson wrote:
I remember back in the early 90’s when I first dove into C++, there
seemed to be this thought process regarding OOP that went something
like: every object should be able to stand alone and interact rarely,
if ever, with anything else because that would break the object’s
encapsulation. I got that feeling from several texts, and I thought
it ludicrous at the time, and still do. As things have evolved, it
seems common sense has stepped in to replace those purist theories,
but that article really took me back to that time.Your original interpretation of the idea of encapsulation is one that I
find held by a lot of folks that are new to object-oriented programming
as you no doubt were in the early 90’s. The ideas may have been
presented improperly, or you may have misinterpreted them, but the ideas
are not ludicrous unless you take them to an illogical extreme.
Well, now, that’s the big catch, isn’t it? =)
Developers are FAR more practical about encapsulation these days. =)
Sean O'Dell
On Sep 1, 2003, at 3:29 PM, Sean O’Dell wrote:
Holub:
- All objects must provide their own UI.
Bollocks to this. It’s this sort of nonsense
that leads to object databases and the uselessness that they
represent. An object should be able to be represented in a number of
different ways, and it cannot possibly predict the ways that it
could be represented. That’s the whole point behind the MVC model,
and saying that an object provides its own UI breaks MVC
significantly.
I’m not sure I agree with most of the rest of the list, either.
-austin
–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.09.02
* 12.45.41
james_b wrote:
Sean O’Dell wrote:
The method print doesn’t seem to me to belong, logically, to the
string “Hello world”, so I don’t expect the string to know how to
print itself. It does seem to me to belong as a method of $stdout,
however.There’s a series of articles [0] by Alan Holub about writng UI, based on
the idea that an object should know how to render itself. In it, Holub
claims,[quote]
I’ll explain the whys and wherefors in a moment, but here are some rules
of thumb that you can apply to see if you’re really looking at an
object-oriented system:
This is, to me, quite insane. =) That puts too much on the shoulders
on the object developer. This assumes that “UI representation” is a
natural function of the object, which it is not. That’s a subjective
parameter that Alan Holub wanted, and completely ignores what others may
want from the object, and that, in my opinion, is the epitome of
breaking object-orientation. =)
- All data is private. Period. (This rule applies to all implementation
details, not just the data.)
I believe I disagree. Dangerous details should be private, yes. But
sometimes data can be exposed when it is protected, because often, a
class variable is itself an object of another class and has its own
protections. If he means raw data, dangerously exposed data, then I agree.
- get and set functions are evil. (They’re just elaborate ways to make
the data public.)
They’re ugly, but if you want to expose potentially dangerous data
elements safely, you have to have these methods, albeit in a more
coder-friendly form (obj.var and obj.var=).
Unless he means actual functions named “get” and “set” for class member
variables. Those do creep me out. Member variable access should be
virtualized somehow.
- Never ask an object for the information you need to do something;
rather, ask the object that has the information to do the work for you.
This is one of those things I was talking about earlier that I also
thought was ludicrous. In a system like this, no object can use the
information from any other object. It’s expected to stand-alone and
perform in a vacuum. Silliness I say, silliness!
- It must be possible to make any change to the way an object is
implemented, no matter how significant that change may be, by modifying
the single class that defines that object.
Well, this turns right around and shows some open-minded thinking, if I
read this right. This sounds somewhat Ruby-esque to me. Every object
should be completely modifiable at run-time.
Not sure if I agree with the “by modifying the single class that defines
it” part though.
I remember back in the early 90’s when I first dove into C++, there
seemed to be this thought process regarding OOP that went something
like: every object should be able to stand alone and interact rarely,
if ever, with anything else because that would break the object’s
encapsulation. I got that feeling from several texts, and I thought
it ludicrous at the time, and still do. As things have evolved, it
seems common sense has stepped in to replace those purist theories,
but that article really took me back to that time.It’s true there are countless possible messages one could send to a
String object, so having String know about all of them in advance is too
much. (There’s been a similar discussion on ruby-talk regarding math
functions)
I like the Math function organization. I see a fair blend of logic and
practicality in the way they were laid out.
And while the convention in many langauges has been to pass a String
object to an IO object, it may be more appropriate to do it the other
way around, and just call String.print or String.print( someIoObject )Luckily, it’s dead simple to add this to your code by enhancing the
String class.class String
def print( io=$stdout )
io.puts( self )
end
endI’ve been doing this sort of thing in my code, and after a while it
struck me as common sense, not purist theory. I find it goes a long
way towards cleaning up or avoiding procedural code where I want OO, and
I find it easier to read.
It strikes me as purist theory. I tried a lot of this sort of thing,
too and found it was sdrawkcab.
What you have there is a string class that knows how to print itself to
any object which supports a “puts” method. But puts might not be the
right paradigm for other objects that the string could be printed to,
such as a socket or a streaming compression object. You then either
have to switch back to letting the other objects print with the string,
and now you have this mixed code (sometimes the string prints itself,
sometimes other objects handle the work) or you have to add more method
to the string object.
That’s ugly to me. Perhaps not to others, but it is to me.
As Holub states, “I should say that although the foregoing attitude
might sound extreme, my ideas don’t stem from some academic notion of
purity; rather, every time I’ve strayed from the straight and narrow in
my own work, I’ve found myself back in the code fixing it a month or two
later. All of this do-it-wrong-then-go-back-and-fix-it work just started
taking up too much time. It turned out to be easier to just do it right
to begin with. My notions, then, are based on practical experience
gathered while putting together working systems, and a desire to put
those systems together as quickly as possible.”That’s pretty much how it’s worked for me.
None of the above really strikes me as purist, it strikes me as wishful.
I think Ruby right now is pretty close to the purity I have, over my
12 years of OO-coding, come to believe is how OO should work. Actually,
Ruby has taught a lot of new things; not the least of which is run-time
morphism.
I guess I can explain how I see OOP something like this: the real world
is made up of objects. You can describe OO programming in terms of
real-world examples. I am an object. I am made of other objects. I
interact with other objects. But I move through the world, and do
everything I do, procedurally. I am an object which moves through life
procedurally. I have my job, other objects have theirs. Our places in
the world are clearly defined by “what I am” and “what I do.”
So, in my line of thinking: me.eat(food)
“Hello world”.print to me equates to: food.eat.
I eat. Food doesn’t eat. $stdout prints. Strings don’t print.
Again, this is all just my opinion. I hope I didn’t come across as
insulting; if I did, I apologize in advance!
Sean O'Dell
Sean O’Dell wrote:
"
So, in my line of thinking: me.eat(food)
“Hello world”.print to me equates to: food.eat.I eat. Food doesn’t eat. $stdout prints. Strings don’t print.
Isn’t this begging the question?
The argument seems to be, “print has been defined for $stdout, not
string; since strings don’t have ‘print’, string.print would not be not
correct.”
James
I’m sometimes interested in “varying flavors” of OOP. The one
proposed here seems very extreme to me. It seems as though
a rigorous application of these principles would pretty much
rule out parameter passing, and the “single class” rule would
rule out inheritance. A full application of these ideas would
make it IMO nearly impossible to code at all.
[snip and move upward:]
Again, this is all just my opinion. I hope I didn’t come across as
insulting; if I did, I apologize in advance!
Likewise…
But that’s not why I’m posting this. I have another opinion
question for all of you. See below.
I guess I can explain how I see OOP something like this: the real world
is made up of objects. You can describe OO programming in terms of
real-world examples. I am an object. I am made of other objects. I
interact with other objects. But I move through the world, and do
everything I do, procedurally. I am an object which moves through life
procedurally. I have my job, other objects have theirs. Our places in
the world are clearly defined by “what I am” and “what I do.”So, in my line of thinking: me.eat(food)
“Hello world”.print to me equates to: food.eat.I eat. Food doesn’t eat. $stdout prints. Strings don’t print.
I like this example. It made me think of a discussion I was having a
few weeks back on when you design an interface like x.meth(y) and
when you do y.meth(x) instead.
The other person cited (I think) the Design Patterns book, giving
polygon.draw(window) as an example. The polygon knows how to draw
itself, and you tell it where to do it.
Logical to many people, but feels backwards to me. I’d rather say
window.draw(polygon) on the theory that the window is where all the
drawing happens, and you tell it what to draw on itself, allowing
it to query the object-to-be-drawn as needed (since we’re passing
it in).
Actually, I remember the concrete example now – it was in RMagick.
To take a piece of text and stick it in an image, you do the
operation text.annotate(img) – it was confusing to me, since I
wanted to do img.annotate(text) instead. FWIW, Tim Hunter ended up
adding the other way as an alternative.
I’ve just realized that in the back of my mind, I prefer passing
the “little object” into the “big object” rather than vice versa.
Hmm. A psychological aspect there.
Much of what Ruby already does bears this out, I think.
array << item # not item << array
stack.push(item) # not item.push(stack)
queue.add(item) # not item.add(queue)
Junk-food for thought…
Hal