Python vs Ruby!

ruby-talk
1

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

2

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.

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.
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.

3

Joe,

Suggestions, no expertise, grain of salt, etc.

Joe Van Dyk wrote:

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

4

Joe Van Dyk wrote:

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

5

(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

···

On Thursday 18 August 2005 17:07, Joe Van Dyk wrote:

Which is better, Python or Ruby?

6

My best thought:

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

James Edward Gray II

···

On Aug 18, 2005, at 4:07 PM, Joe Van Dyk wrote:

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

7

Joe Van Dyk wrote:

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

8

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:

+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!

9

Well, good news. While Ruby's not on the companywide "approved" list
yet, my group and all other groups that we work with have got an
official "Ruby is ok" exception granted.

So, thanks to all of you!

Joe

···

On 8/18/05, Joe Van Dyk <joevandyk@gmail.com> wrote:

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.

10

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

···

On Thursday 18 August 2005 3:17 pm, Josh Charles wrote:

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.

11

<snip>

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

···

On Fri, 19 Aug 2005, Jamey Cribbs wrote:
--

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

===============================================================================

12

Ben Giddings wrote:

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.

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

···

On Thursday 18 August 2005 17:07, Joe Van Dyk wrote:

--

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

13

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.

···

At 08:18 PM 8/18/2005, Jamey Cribbs wrote:

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.

_____________________
  Bret Pettichord
  www.pettichord.com

14

Jamey Cribbs wrote:

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.

You must be kidding! It is Python that has had the object oriented stuff baked in. Ruby was designed from ground up to be object oriented (every thing, even a number, even nil, is an object!)

Baalbek

15

#: Jamey Cribbs changed the world a bit at a time by saying on 8/19/2005 3:18 AM :#

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

What about lambdas? (afaik python has lambdas and a notion called maps - but about the 2nd I am not pretty sure).

:alex |.::the_mindstorm::.|

16

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.

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

17

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

···

On 8/18/05, James Britt <james_b@neurogami.com> wrote:

Ben Giddings wrote:
> On Thursday 18 August 2005 17:07, Joe Van Dyk wrote:
>
>>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.

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.

18

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

···

On Thursday 18 August 2005 9:33 pm, James Britt wrote:

> 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.

19

Bret Pettichord wrote:

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.

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. :slight_smile:

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.

···

At 08:18 PM 8/18/2005, Jamey Cribbs wrote:

20

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...

···

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.)

--
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org