Python vs Ruby!

[Joe Van Dyk]

Which is better, Python or Ruby?

(ha, just kidding)

I've been fighting the good fight inside a really large corporation
trying to get Ruby on the "approved" list. I've brought this up a
couple times in the past on this list and have got some good
responses.

Perl used to be the language of choice for certain application
domains. Then, a few years ago, Python was seen to be better than
Perl, so Python was added to the "approved" list.

As there's an interest in reducing variability in software systems in
the company, any addition to the approved list has to have some pretty
good reasons as to why the addition is needed.

I have a couple main reasons why I prefer Ruby over Python:
1) Simple to extend existing applications written in C with Ruby.
2) Great syntax
3) Blocks
4) DRb
5) Rails

I don't think that's enough though, as #2 is pretty subjective and
there's probably an equivalent to DRb in Python and Rails is probably
way too bleeding edge (and I don't do web development stuff here). #1
is probably the most compelling reason.

I obviously don't want to push for Ruby as a replacement for Python,
that would never work. I'm pushing for Ruby to be available for use
in addition to Python. So, I think the question is: "Why would you
want to use Ruby in a situation where Python is available?"

Thanks,
Joe

 

[Josh Charles]

I've been fighting the good fight inside a really large corporation

trying to get Ruby on the "approved" list. I've brought this up a
couple times in the past on this list and have got some good
responses.
=20
Perl used to be the language of choice for certain application
domains. Then, a few years ago, Python was seen to be better than
Perl, so Python was added to the "approved" list.

One concern I have is performance issues, especially when it comes to
GUI programming. After trying several different programs, I've
noticed a large difference in performance between Ruby (Using FXRuby)
and Python (Using PyQT) with Python coming out as the clear leader.=20
The Python Program (Eric3) was running about five times faster than
the Ruby (FreeRIDE). Those two ought to compare well, as they have
similar functions.

It's bothersome because I already dedicated a project to working in
Rails before I found this out, so I can only hope this is a Graphical
Toolkit Issue and not a language issue.

 

[Kirk Haines]

It's bothersome because I already dedicated a project to working in
Rails before I found this out, so I can only hope this is a Graphical
Toolkit Issue and not a language issue.

Ruby performance with web tasks has been mentioned a great deal. Heck, I
think I've mentioned it in a praising way a couple times already in the past
week.

Rails has demonstrated adequate performance for real world tasks on many
occasions, now. 43things.com runs on Rails and they field quite a bit of
highly dynamic traffic without any problem on a very reasonable set of
hardware.

And while I don't use Rails, I have used Ruby exclusively for web work for
over three years, and I get what I deem to be very good performance from it.
Comparing web performance is very difficult because there are so many
variables that can influence the numbers, but an app that I have in
production for a fortune 500 company has been benchmarked by me to deliver a
9k, modestly dynamic page in .0035 seconds on a single processor, midrange
Linux box. For large groups of consecutive requests of this page (not
cached), it does 260-290 requests per second, consistently, depending on what
other load I have on the machine at the same time. In actual real, heavy
usage with real data, many of the pages will be larger or more complex, and
thus slower to deliver, but that one cheap box will still handle more traffic
per second than this company will _ever_ throw at it, and if it did start to
get bogged down, adding a second server at the level of performance that Ruby
gives me is a reasonable, economical solution.

At least when it comes to web applications, Ruby is plenty fast, and Rails in
real usage seems to deliver enough performance to handle pretty heavy usage.


Kirk Haines

 

[Josh Charles]

At least when it comes to web applications, Ruby is plenty fast, and Rail=
s in

real usage seems to deliver enough performance to handle pretty heavy usa=

ge.

Thanks for the info. That really makes me feel more comfortable with
the decision I made to go with Ruby.

 

[Devin Mullins]

Joe,

Suggestions, no expertise, grain of salt, etc.

I have a couple main reasons why I prefer Ruby over Python:

Are they the same reasons that the company should prefer Ruby over
Python? (In what cases?) If so:

1) Simple to extend existing applications written in C with Ruby.
2) Great syntax
3) Blocks
4) DRb
5) Rails

If you've got a lot of free time on your hands, implement each of these
as actual Python vs Ruby code samples, and then draw conclusions based
on reasons deduction from examination of the samples. (You can see here
how such-and-such is easier to implement, hence resulting in less
duplication.) Tie everything back to dollar amounts, but show your work.
Don't try to cover up the fudge factor -- measuring programming
productivity is a bit of a black art.

I didn't at all answer your question, but that's because I'm not
familiar enough with Python. I read through 5 chapters of "Dive Into
Python," got disgusted, and decided to try Ruby instead. Boy am I glad I
did.

Devin

 

[Jamey Cribbs]

Which is better, Python or Ruby?

(ha, just kidding)

I've been fighting the good fight inside a really large corporation
trying to get Ruby on the "approved" list. I've brought this up a
couple times in the past on this list and have got some good
responses.

Yesterday I had to give a short presentation to the big boss about Ruby
and why I had chosen to use it at our company (and why I wanted to
continue using it).

As there's an interest in reducing variability in software systems in
the company, any addition to the approved list has to have some pretty
good reasons as to why the addition is needed.

I have a similar issue, I had been using both Python and Ruby for my
programming needs and was told by my boss that I would have to pick one
and use it exclusively.

I don't think that's enough though, as #2 is pretty subjective and
there's probably an equivalent to DRb in Python and Rails is probably
way too bleeding edge (and I don't do web development stuff here). #1
is probably the most compelling reason.

I'm not so sure you will find an equivalent to DRb in Python. I have
looked. Oh, there are a couple of similar libraries in Python, but I
did not find them nearly as easy to use as DRb (of course, I'm not the
sharpest tack in the box).

I obviously don't want to push for Ruby as a replacement for Python,
that would never work. I'm pushing for Ruby to be available for use
in addition to Python. So, I think the question is: "Why would you
want to use Ruby in a situation where Python is available?"

Boy, isn't that the $64,000 question. I struggled with this one at my
job for months, as my boss put more and more pressure on me to choose
one and only one.

Because I have developed a moderately complex library (KirbyBase) in
first Python and then Ruby, I'm hoping that you will find my $.02 worth
on this topic interesting.

To me, from a practical programming perspective (say that 10 times
fast), Python and Ruby are *very* similar. Obvious differences are of
course, things like the indentation thing; Ruby feeling more like
object-orientated stuff was baked in rather than added on; Python being
a little faster, etc.

I went back and forth trying to decide. What finally sold me on Ruby
was a feature that I had little use for until Hal Fulton helped the
light bulb to go on above my head. Blocks! More specifically, blocks
used as closures.

Hal convinced me to rewrite KirbyBase and allow the user to specify
query syntax using blocks. When I finally figured out how easy it was
to add this functionality and how much power it gave the user to specify
queries, I was sold.

What really put me over the top was when I recently went back and
rewrote the Python version of KirbyBase and tried to duplicate all of
the functionality of the new Ruby version. Python doesn't have blocks.
It has lambda, but it is pretty crippled. In Python, a lambda can only
be one expression and you can't do assignment in a lambda. What's
worse, Guido doesn't even like lambda and he is planning on removing it
from the language.

Now, you can still do closures in Python by actually passing a named
function, but using blocks is just so much more elegant.

Before this, I had *used* blocks for things like #collect and #each.
But it was only when I started having my own user-defined methods accept
and use blocks that I really started to understand how powerful they
make Ruby.

Anyway, sorry for the long post. To make a long story short, I chose
Ruby. I still program in Python on the side. I'm hoping to soon
release a Python version of KirbyBase that is equivalent to the Ruby
version. But, without those blocks, it's just not as much fun (although
list comprehensions are cool!). Hope this helps answer your question.

Jamey Cribbs

 

[Ara.T.Howard]

On Fri, 19 Aug 2005, Jamey Cribbs wrote:

Anyway, sorry for the long post. To make a long story short, I chose Ruby.
I still program in Python on the side. I'm hoping to soon release a Python
version of KirbyBase that is equivalent to the Ruby version. But, without
those blocks, it's just not as much fun (although list comprehensions are
cool!). Hope this helps answer your question.

thanks alot - very interesting.

-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| Your life dwells amoung the causes of death
| Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================

 

[Ben Giddings]

Which is better, Python or Ruby?

(checks the mailing list)

Um... Ruby?

But seriously, Python and Ruby are so similar that it will be really hard to
make a really compelling argument. I'd go with a few things.

1) Are there people there that miss Perl, or have found Python not as well
suited to what they're doing as Perl was? Ruby's Perl-like roots may come in
handy. I think Ruby is a much more suitable language for certain tasks than
Python because of its Perl roots. Tasks like modifying a bunch of files in
place, anything dealing with regular expressions, etc. Find the old Perl
hackers and show them Ruby, see what they think.

2) Do you share code in ways other than code files? Say on websites, inside
other files (like say word processor docs), as email snippets, etc? That's
one area where indentation-sensitive languages really suffer. In particular,
copying and pasting Python code from web sites can be a real exercise in
frustration. Getting it there in the first place can be even worse. HTML
wants to make whitespace insignificant, Python really cares about
indentation, the mix causes problems. That can be a real reason to push for
Ruby.

3) Rails and Instiki. You can (I haven't done this, but I've heard), easily
install instiki on a USB thumb drive. Having a really portable wiki like
that can be super valuable, and it's so easy to set up, did you know,
"there's no step 3"? If you show the applications, rather than the
underlying techologies, and convince people that the applications are
great... they may be more willing to accept the technologies the applications
use.

Finally, you should show how well Python and Ruby interoperate using things
like XML-RPC. If people are scared of a hodge-podge of different languages,
show how well the two can coexist.

Ben

 

[James Edward Gray II]

So, I think the question is: "Why would you
want to use Ruby in a situation where Python is available?"

My best thought:

"Well boss, I'm just more productive with Ruby."

James Edward Gray II

 

[James Britt]

Which is better, Python or Ruby?

(ha, just kidding)

I've been fighting the good fight inside a really large corporation
trying to get Ruby on the "approved" list. I've brought this up a
couple times in the past on this list and have got some good
responses.

Perl used to be the language of choice for certain application
domains. Then, a few years ago, Python was seen to be better than
Perl, so Python was added to the "approved" list.

As there's an interest in reducing variability in software systems in
the company, any addition to the approved list has to have some pretty
good reasons as to why the addition is needed.

I have a couple main reasons why I prefer Ruby over Python:
1) Simple to extend existing applications written in C with Ruby.
2) Great syntax
3) Blocks
4) DRb
5) Rails

I don't think that's enough though, as #2 is pretty subjective and
there's probably an equivalent to DRb in Python and Rails is probably
way too bleeding edge (and I don't do web development stuff here). #1
is probably the most compelling reason.

What makes Rails so appealing is that it is *not* bleeding edge. Rails
takes a variety of good ideas that have been tried and tested under a
variety of circumstances, and makes them easy to use.

(That's not to say Rails doesn't incorporate advanced coding or smart
design; clearly it does, but the user need not be concerned with any of
that until he or she so desires.)

Even if you don't do Web stuff, you can hold up Rails as an example of
how Ruby helps make one build tools to help others be more productive.
Ruby enables productivity bootstrapping because how how well it allows
one to create DSLs.

I obviously don't want to push for Ruby as a replacement for Python,
that would never work. I'm pushing for Ruby to be available for use
in addition to Python. So, I think the question is: "Why would you
want to use Ruby in a situation where Python is available?"

Higher productivity. Ruby fits my way of thinking better, so I spend
less time pushing against the language.

Put it another way: What's so bad about getting paid to use Python?

James

--

http://www.ruby-doc.org - The Ruby Documentation Site
http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys

 

[James Britt]

(checks the mailing list)

Um... Ruby?

But seriously, Python and Ruby are so similar that it will be really hard to
make a really compelling argument. I'd go with a few things.

1) Are there people there that miss Perl, or have found Python not as well
suited to what they're doing as Perl was? Ruby's Perl-like roots may come in
handy. I think Ruby is a much more suitable language for certain tasks than
Python because of its Perl roots.

I find this somewhat baffling. I'm aware that Matz was influenced by
certain aspects of Perl, but I really don't see any alleged "Perl roots"
when coding Ruby. (My biased take is that this is something Pythonitas
like to toss out about any language that allows more than one way to do
anything.) There are things common to both languages, but not unique to
the pair.

I used Perl for several years, and was fairly evangelistic about it with
others. I heard about Ruby, was initially put off, gave it another try,
and never regretted it.

I recently had to go poke through some Perl code, and it was truly
foreign. If there were any essential similarities with Ruby, they
eluded me.

I wouldn't try to lure Perl developers to Ruby with any suggestions that
they can go write Ruby code with a Perl mindset or style. That's asking
for trouble.

Tasks like modifying a bunch of files in
place, anything dealing with regular expressions, etc. Find the old Perl
hackers and show them Ruby, see what they think.

That's not possible in Python? (Real question; my Python is vague.)


James

--

http://www.ruby-doc.org - The Ruby Documentation Site
http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys

 

[Joe Van Dyk]

=20
I find this somewhat baffling. I'm aware that Matz was influenced by
certain aspects of Perl, but I really don't see any alleged "Perl roots"
when coding Ruby. (My biased take is that this is something Pythonitas
like to toss out about any language that allows more than one way to do
anything.) There are things common to both languages, but not unique to
the pair.
=20
I used Perl for several years, and was fairly evangelistic about it with
others. I heard about Ruby, was initially put off, gave it another try,
and never regretted it.
=20
I recently had to go poke through some Perl code, and it was truly
foreign. If there were any essential similarities with Ruby, they
eluded me.
=20
I wouldn't try to lure Perl developers to Ruby with any suggestions that
they can go write Ruby code with a Perl mindset or style. That's asking
for trouble.

The style is different, sure, but a lot of the Perl shortcuts ($0, $$,
$<, etc) are there, along with ~=3D and those other godawful punctuation
soup operators.

 

[Gene Tani]

1) Simple to extend existing applications written in C with Ruby.

2) Great syntax
3) Blocks
4) DRb
5) Rails

Besides SWIG, py has several mature well-documented libraries for
extensions and inlining c/C++: CXX, boost, weave, pyrex:

http://cxx.sourceforge.net/
http://www.python.org/cgi-bin/moinmoin/boost_2epython_2fGettingStarted
http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/
http://www.scipy.org/documentation/weave/

Syntax: Mr. Fulton's Ruby Way, appendix B compares Ruby 1.6, python 2.2
(py 2.4's not materially different from 2.2, whereas rb 1.8 was a big
leap forward). Python's oft-criticized O-O
warts_or_philosophical_choices: no truly class-private declaration
("__methORattrib_name" is just a name-mangling procedure; "self" must
always 1st param in method defs; duplication between function and
method libs, e.g. for string processing. You could look at Codezoo, see
waht those folks have picked as well coded, documented, &tested ruby
and python components.

blocks: Guido's definitely paying attention, read the (accepted) PEP:
http://www.python.org/peps/pep-0343.html
+1 for ruby!

the python Drb analog would be pyro:
http://directory.google.com/Top/Computers/Programming/Languages/Python/Modules/Distributed_Computing

rails analogs: Django, Subway i know nothing about. Rails kicks ass,
just like every intelligent person proclaims out loud at least 1x/hour!

 

[Kirk Haines]

I find this somewhat baffling. I'm aware that Matz was influenced by
certain aspects of Perl, but I really don't see any alleged "Perl roots"
when coding Ruby. (My biased take is that this is something Pythonitas
like to toss out about any language that allows more than one way to do
anything.) There are things common to both languages, but not unique to
the pair.

I used Perl for several years, and was fairly evangelistic about it with
others. I heard about Ruby, was initially put off, gave it another try,
and never regretted it.

I recently had to go poke through some Perl code, and it was truly
foreign. If there were any essential similarities with Ruby, they
eluded me.

I came to Ruby from many years of Perl zealotry, and one of the things that
made the switch very, very easy was that when it came to the methods
available on the core classes, they were generally named the same as the
keyword to do the same thing in Perl. So I didn't have to sit in the Pickaxe
class reference and lookup methods to do most of the common stuff. Most of
the time if I just use a method name the same as what the function was in
Perl, it worked.

So, once I adapted to blocks and to using a method call syntax on almost
everything, I was already productively writing Ruby code. The learning curve
between initially reading about Ruby and actually writing useful code was
quite shallow, coming from Perl.


Kirk Haines

 

[Jim Weirich]

I came to Ruby from many years of Perl zealotry, and one of the things = that
made the switch very, very easy was that when it came to the methods
available on the core classes, they were generally named the same as th= e
keyword to do the same thing in Perl. =A0So I didn't have to sit in the
Pickaxe class reference and lookup methods to do most of the common stu= ff.
=A0Most of the time if I just use a method name the same as what the fu= nction
was in Perl, it worked.

Same here. After using Perl for a number of years I was trying to move t=
o a=20
language that would grow into larger programs more gracefully than Perl. =
I=20
tried to make the switch to Python three times, but found Python just=20
different enough that it was hard to use Python for the small, jobs that =
I=20
normally used Perl for. It was during my third attempt to pick up Python=
=20
that I saw a posting about Ruby by Dave Thomas. Since I had just finishe=
d=20
reading the Pragmatic Programmer book, I held Dave's opinion in high rega=
rd. =20
I downloaded and installed Ruby and was writing Ruby code within a day. =
I=20
have never used Perl for non-legacy code since the switch.

I'm not sure why switching to Ruby was so much easier than switching to=20
Python. Part of the reason is that I didn't have to keep looking things =
up=20
in Ruby ... things just worked the way I expected.

--=20
-- Jim Weirich (e-mail address removed) http://onestepback.org

 

[Luc Heinrich]

I'm not sure why switching to Ruby was so much easier than =20
switching to
Python.

According to my experience, it's because Python is just insanely =20
inconsistent in every single way.

--=20
Luc Heinrich - (e-mail address removed) - http://www.honk-honk.com

 

[Jamey Cribbs]

Could you show us an example of this? I'm sure i should be using
blocks more myself and i'd like to see how others are doing it.

Ok, here is a somewhat simplified code example. Let's say you have a
table that holds information about WWII airplanes. You want to write a
query that selects all planes from the table that belonged to the US and
had a top speed greater than 350mph. First you would write the query,
using a block to specify the actual select condition:

results = plane_tbl.select { |r| r.country == 'USA' and r.speed > 350 }

Notice that Ruby allows you to easily pass around code that keeps it's
local context, you can simply write the query using Ruby, instead of
having to, say, write a string that KirbyBase would have to do an #eval
on to figure out what you want to do.

Now, how is this query we wrote above handled? Here is a greatly
simplified version of KirbyBase's select method:

def select(&select_cond)
result = []
@db.engine.get_recs(self).each do |rec|
result << rec if select_cond.call(rec)
end
return result
end

Notice that the query block is passed in and assigned to the variable
select_cond. Then, KirbyBase loops through all the records in the
table. For each record it executes the block, passing in the values of
the current record to the block. If the return value from the block is
true, then the record is added to the result set. After all records
have been looped through, the result set is returned to user.

Before I re-wrote KirbyBase to use blocks, I had written an earlier
version where the user specifed their query by putting it inside a
string. The select method then parsed the string and built up the query
itself. It was tedious ugly code, parsing the string, trying to make
sure I covered all the ways the user might specify the query string.
Additionally, the user was very limited in the kinds of comparisons they
could do in the query string. Basically, if I the parsing code in the
select method could not handle it, they couldn't do it.

Then, when I switched KirbyBase to handle blocks, that totally changed.
Now, the user has total freedom to write their query the way they want,
because, as long as their query is valid Ruby code, it will work! Even
better, if Matz adds new classes or methods to Ruby, I don't need to
change a line of code of KirbyBase to accomodate it, because, when
KirbyBase executes a query, it is actually Ruby that is doing all the
heavy lifting, since the query is simply Ruby code itself.

This totally sold me on blocks.

Jamey

Confidentiality Notice: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. If you are not the intended recipient(s), you are hereby notified that any dissemination, unauthorized review, use, disclosure or distribution of this email and any materials contained in any attachments is prohibited. If you receive this message in error, or are not the intended recipient(s), please immediately notify the sender by email and destroy all copies of the original message, including attachments.

 

[Kirk Haines]

Ok, here is a somewhat simplified code example. Let's say you have a
table that holds information about WWII airplanes. You want to write a
query that selects all planes from the table that belonged to the US and
had a top speed greater than 350mph. First you would write the query,
using a block to specify the actual select condition:

results = plane_tbl.select { |r| r.country == 'USA' and r.speed > 350 }

I *heart* that sort of query syntax. You'll see much the same thing in the
Kansas ORM:

results = ksdbh.selectPlanes) {|r| (r.country == 'USA') & (r.speed > 350)}

In this case, method_missing magic is mixed into that in such a way that the
Ruby code becomes a SQL statement for querying a relational database.

It's a great way of interacting with data. Neat to see that KirbyBase is
doing that.


Kirk Haines

 

[tony summerfelt]

James Britt wrote on 8/18/2005 11:33 PM:

(My biased take is that this is something Pythonitas
like to toss out about any language that allows more than one way to do
anything.)

imho, this completely alienates newbies from the language.

when i first learned perl ten years ago or so i did something like this:

$_=$text # do something with $text
if ($text eq "test)
{
print "matched"
}

and it worked. nobody called me names. said i was doing it wrong, etc.

after i learned more perl that kind of thing changed a few steps and i
ended up writing it this way:

$_=$text # do something with $text
print "matched" if /test/i

if i 'tossed out' any language that allowed tim toadie and did it
Python Approved way i would have to learn all the intracasies of
python before being able to write Proper Python Code.

as it turns out NONE of my python code did followed the 'there's only
one way to do it' mantra . i solved that problem though. i stopped
using python

with ruby, i'm SURE that using yield more will give me shorter and
more efficient code. in the mean time i can Get Things Done by writing
ruby code that works for me and so far seems to be a perfectly
acceptable tim toadie...

 

[Isaac Gouy]

I *heart* that sort of query syntax. You'll see much the same thing in the
Kansas ORM:

results = ksdbh.selectPlanes) {|r| (r.country == 'USA') & (r.speed > 350)}

Good ole Smalltalk

'select' even wormed it's way into OCL v1.1 (p16)
http://www.google.com/url?sa=t&ct=r...sources/obje_11.pdf&ei=LxwGQ72PBpyQsQGAqO2qDQ