Python vs Ruby

[Tom Anderson]

Re: Python vs Ruby

On Fri, 21 Oct 2005, vdrab wrote:
[color=blue]
> You can tell everything is well in the world of dynamic languages when
> someone posts a question with nuclear flame war potential like "python
> vs. ruby" and after a while people go off singing hymns about the beauty
> of Scheme...[/color]

+1 QOTW
[color=blue]
> I love this place.[/color]

Someone should really try posting a similar question on c.l.perl and
seeing how they react ...

tom

--
Transform your language.

[Scott David Daniels]

Re: Python vs Ruby

bruno modulix wrote:[color=blue]
> ... Another language that failed to make it to the mainstream but is
> worth giving a try is Smalltalk - the father of OOPLs (Simula being the
> GrandFather).[/color]
I would say Simula is the forefather of modern OOPLs, and Smalltalk is
the toofather.

--Scott David Daniels
scott.daniels@a cm.org

[Ed Jensen]

Re: Python vs Ruby

Sion Arrowsmith <siona@chiark.g reenend.org.uk> wrote:[color=blue]
> I have here a library (it's the client side of a client-server
> interface including a pile of class definitions) which has
> implementations in pure C++, Java and Python, taking about 3000,
> 3500 and 1500 loc respectively. And there's an associated module
> (with no C++ implementation) that I remember being particular
> "impressed" while writing it to find being 3 times as long in Java
> as Python despite (a) extensive (and pretty much common) Javadoc/
> docstrings and (b) implementing in the Python version a feature
> present in the standard Java library (scheduling a thread to run
> at specified intervals and time out). Strip the Javadoc/docstrings
> out and it's about at that 5:1 ratio.[/color]

This claim seems pretty dubious to me.

[Peter Hansen]

Re: Python vs Ruby

Bryan wrote:[color=blue]
> Dave Cook wrote:[color=green]
>> Cale? You mean Python has more ruffage?[/color]
>
> i think you mean "kale" not "cale". nothing like a hot bowl of tofu
> kale soup while reading the recipes in the "python cookbook".[/color]

Well, if he's going to talk about "ruffage" instead of "roughage",
perhaps he really did mean "cale" and not "kale". ;-)

[Kent Johnson]

Re: Python vs Ruby

Casey Hawthorne wrote:[color=blue]
> I have heard, but have not been able to verify that if a program is
> about
> 10,000 lines in C++
> it is about
> 5,000 lines in Java
> and it is about
> 3,000 lines in Python (Ruby to?)[/color]

My experience is that Java:Python is roughly 2:1, the highest I have seen (on small bits of code) is 3:1.

Kent

[Bryan]

Re: Python vs Ruby

Ed Jensen wrote:[color=blue]
> Sion Arrowsmith <siona@chiark.g reenend.org.uk> wrote:
>[color=green]
>>I have here a library (it's the client side of a client-server
>>interface including a pile of class definitions) which has
>>implementatio ns in pure C++, Java and Python, taking about 3000,
>>3500 and 1500 loc respectively. And there's an associated module
>>(with no C++ implementation) that I remember being particular
>>"impressed" while writing it to find being 3 times as long in Java
>>as Python despite (a) extensive (and pretty much common) Javadoc/
>>docstrings and (b) implementing in the Python version a feature
>>present in the standard Java library (scheduling a thread to run
>>at specified intervals and time out). Strip the Javadoc/docstrings
>>out and it's about at that 5:1 ratio.[/color]
>
>
> This claim seems pretty dubious to me.[/color]

i would not say sion's ratio of 5:1 is dubious. for what it's worth, i've
written i pretty complex program in jython over the last year. jython compiles
to java source code and the number of generated java lines to the jython lines
is 4:1.

bryan

[Alex Martelli]

Re: Python vs Ruby

Amol Vaidya <mynewsa@gmail. com> wrote:
[color=blue]
> Hi. I am interested in learning a new programming language, and have been
> debating whether to learn Ruby or Python. How do these compare and contrast
> with one another, and what advantages does one language provide over the
> other? I would like to consider as many opinions as I can on this matter
> before I start studying either language in depth. Any help/comments are
> greatly appreciated. Thanks in advance for your help.[/color]

Within the panorama of existing languages, Python and Ruby are just
about as similar as two languages independently developed are likely to
get (and then some -- there is clearly some minor mutual influence, e.g.
Ruby probably picked 'def' for function definition partly-because that's
what Python uses, and later Python may have picked 'yield' for
generators partly-because that's what Ruby uses to have a method
interact with a block it gets passed). They address the same niches and
share most of the same strengths (and minor weaknesses).

Pragmatically, Python is more mature -- with all sort of consequences,
e.g., Python will be faster for many tasks (more time has been spent on
optimizing it), more third-party libraries and tools are available, etc,
but the Python community may be less easy to "get into" than the newer,
smaller Ruby one, for example.

Here's a tiny script showing some similarities and differences:

def f()
i = 0
while i < 1000000
j = 923567 + i
i += 1
end
end

f()

comment out the 'end' statements, and at colons at the end of the def
and while statements, and this is also valid Python. On my iBook...:

Helen:~ alex$ time ruby -w tim.rb

real 0m5.367s
user 0m5.129s
sys 0m0.041s

while:

Helen:~ alex$ time python tim.py

real 0m1.078s
user 0m0.953s
sys 0m0.063s

Note that this is NOT the normal way to loop in either language, so do
NOT read too much into the reported times -- a 5:1 ratio is NOT normally
observed on real tasks, though it IS reasonably normal for Python to be
somewhat faster. BTW, this is Python 2.4.1 and Ruby 1.8.2.

I'm pretty sure that the Ruby community at some point will go through
much the same exercise the Python one did in the several years spent on
the transitions 2.2 -> 2.3 -> 2.4 -- reduce the amount of change in the
language and library and focus most development effort on optimization
instead. I know of no intrinsic reason why Ruby and Python should not
deliver just about equal performance for similar tasks, though the
current implementations may not be equivalent (yet) from this POV.

Python in recent years moved to enhance its object model (making it in
some ways closer to Ruby) and iteration abilities (ditto), while Ruby
moved to shed more and more of its Perl legacy (though in both cases
legacy issues may have slowed down progress a little bit, yet for both
languages the direction is clear). This makes the two languages more
similar and to some extent interchangeable .

Ruby has acquired a framework ("Ruby on Rails") that makes it very
desirable to implement database-backed web sites; while Python's running
hot after it (e.g. with Django), for this specific task Rails is better
today (e.g., you can get good _books_ about Rails, but not yet about
Django). "Ruby Gems" is a good package management system that is fully
operational today; again, Python's catching up, but it's not there yet.

For other things, Python's existing base of third-party extensions and
tools is above Ruby's. For example, Numeric (and numarray and scipy,
etc) make Python excellent for heavy-duty number crunching, and I do not
know of Ruby equivalents in this area; Twisted is a great framework for
asynchronous network programming, and, again, it's a Python advantage;
and so on, and so forth. However, there is a downside: for some tasks
(e.g., web-site frameworks) Python has _too many_ good 3rd party
extensions available, making it hard to choose among them!

We can proceed to compare the languages themselves. Many differences
are minor and cosmetic. Typically, Python is more specific, giving you
fewer cosmetic choices: e.g., you must use parentheses in defining and
calling functions, while, in Ruby, parentheses are optional (though
often recommended) for these same tasks. Ruby's approach of having
everything be an object on the same plane, infinitely modifiable until
and unless explicitly frozen, is more regular, while Python's approach
of giving slightly special status to built-in types and making them not
modifiable dynamically is slightly less regular but may be more
pragmatic. OTOH, Python's approach to "callable objects" (essentially
making them all fully interchangeable ) is the more regular of the two.
Ruby's approach to iteration (passing the code block into a method) is
essentially equivalent to Python's (iterators and generators), with
several minor advantages and disadvantages on either side. One could go
on for quite a long time, but to some extent these are all minor
quibbles, nothing really earth-shaking in the mix. Writing Ruby
extensions in C is slightly easier (thanks to mark-and-sweep garbage
collecton, mostly), but Python offers many alternatives (e.g., pyrex)...

Personally, I'm happy to stick with Python, but I keep studying Ruby
when new books &c about it come out (I'm biased, having written Python
books, but the Ruby books from the "pragmatic programmers" are also
quite good ones, no two ways about it). I think that if you try both
and consider accurately all the uses you may want to put them to, you'll
most probably be happy with either... or both!


Alex

[Robert Boyd]

Re: Python vs Ruby

On 10/19/05, Jason Stitt <jason@pengale. com> wrote:
[color=blue]
>
> How can we improve Python's competitiveness in this arena? "Pie"? Or
> can we do even better than Lua? Ptooey![/color]

I'm sure I could really evangelize use of it at work were it called Ptooey ;)

As if Plone, Zope, and (non-Python) Shibboleth weren't getting me
enough funny looks. And I haven't even started telling co-workers
about Django.

Rob

[Roy Smith]

Re: Python vs Ruby

Robert Boyd <robert.h.boyd@ gmail.com> wrote:[color=blue]
> As if Plone, Zope, and (non-Python) Shibboleth weren't getting me
> enough funny looks. And I haven't even started telling co-workers
> about Django.[/color]

A couple of years ago, a head-hunter asked me if I knew Plone. I figured
he was just being an idiot and didn't know how to spell PL/1. Silly me :-)

[Terry Hancock]

Re: Python vs Ruby

On Friday 21 October 2005 04:25 pm, Ed Jensen wrote:[color=blue]
> Sion Arrowsmith <siona@chiark.g reenend.org.uk> wrote:[color=green]
> > I have here a library (it's the client side of a client-server
> > interface including a pile of class definitions) which has
> > implementations in pure C++, Java and Python, taking about 3000,
> > 3500 and 1500 loc respectively. And there's an associated module
> > (with no C++ implementation) that I remember being particular
> > "impressed" while writing it to find being 3 times as long in Java
> > as Python despite (a) extensive (and pretty much common) Javadoc/
> > docstrings and (b) implementing in the Python version a feature
> > present in the standard Java library (scheduling a thread to run
> > at specified intervals and time out). Strip the Javadoc/docstrings
> > out and it's about at that 5:1 ratio.[/color]
>
> This claim seems pretty dubious to me.[/color]

Why?

--
Terry Hancock ( hancock at anansispacework s.com )
Anansi Spaceworks http://www.anansispaceworks.com

[Kent Johnson]

Re: Python vs Ruby

Bryan wrote:[color=blue]
> i would not say sion's ratio of 5:1 is dubious. for what it's worth,
> i've written i pretty complex program in jython over the last year.
> jython compiles to java source code and the number of generated java
> lines to the jython lines is 4:1.[/color]

Ugh. The code generated by jythonc is *nothing like* the code you would write by hand to do the same thing. This is a meaningless comparison.

Kent

[Ed Jensen]

Re: Python vs Ruby

Bryan <belred@gmail.c om> wrote:[color=blue]
> i would not say sion's ratio of 5:1 is dubious. for what it's worth, i've
> written i pretty complex program in jython over the last year. jython compiles
> to java source code and the number of generated java lines to the jython lines
> is 4:1.[/color]

Most code generators are known to produce non-optimal code.

[Steven D'Aprano]

Re: Python vs Ruby

On Fri, 21 Oct 2005 13:03:29 +0100, Alex Stapleton wrote:
[color=blue]
>
> On 21 Oct 2005, at 09:31, Harald Armin Massa wrote:
>[color=green]
>> Casey,
>>
>>
>>[color=darkred]
>>> I have heard, but have not been able to verify that if a program is
>>> about
>>> 10,000 lines in C++
>>> it is about
>>> 5,000 lines in Java
>>> and it is about
>>> 3,000 lines in Python (Ruby to?)[/color][/color][/color]

I suspect it is considerably less than that, although it depends on the
specific code being written.

[color=blue][color=green]
>> BTW: it is normally only 50 lines in Perl. Not that you could read it,
>> though
>>
>> Harald
>>
>>[/color]
> Perl is more like a CISC CPU. There are a million different commands.
> Python is more RISC like.
> Line count comparisons = pointless.[/color]


Not so.

Every line = more labour for the developer = more cost and time.
Every line = more places for bugs to exist = more cost and time.

I find it sometimes helps to imagine extreme cases. Suppose somebody comes
to you and says "Hi, I want you to develop a web scrapping application to
run on my custom hardware." You look at the project specifications and
realise that the hardware has no OS, no TCP/IP, no file manager, no
compiler. So you have to quote the potential customer on writing all these
layers of software, potentially tens of millions of lines of code.
Even porting an existing OS to the new hardware is not an insignificant
job. Think how much time and money it would take.

On the other extreme, the client comes to you and asks the same thing,
except the hardware is a stock-standard Linux-based PC. Your development
environment already contains an operating system, a file manager,
TCP/IP, compilers, frameworks... and wget. The work you need to do is
potentially as little as writing down the command "man wget" on a slip of
paper and pushing it across the table to your customer.

As programming languages go, C is closer to the first extreme, C++ a
little further away, Java further away still, because Java provides
more capabilities already built-in that the C programmer has to
create from scratch. For many tasks, Python provides even more
capabilities, in a language that demands less syntax scaffolding to make
things happen. Every line of code you don't have to write not only is a
bug that just can't happen, but it also saves time and labour.


--
Steven.

[Mike Meyer]

Re: Python vs Ruby

Steven D'Aprano <steve@REMOVETH IScyber.com.au> writes:[color=blue]
> On Fri, 21 Oct 2005 13:03:29 +0100, Alex Stapleton wrote:[color=green]
>> Perl is more like a CISC CPU. There are a million different commands.
>> Python is more RISC like.
>> Line count comparisons = pointless.[/color]
>
> Not so.
>
> Every line = more labour for the developer = more cost and time.
> Every line = more places for bugs to exist = more cost and time.[/color]

There were studies done in the 70s that showed that programmers
produced the same number of debugged lines of code a day no matter
what language they used. So a language that lets you build the same
program with fewer lines of code will let you build the program in
less time.
[color=blue]
> I find it sometimes helps to imagine extreme cases. Suppose somebody comes
> to you and says "Hi, I want you to develop a web scrapping application to
> run on my custom hardware." You look at the project specifications and
> realise that the hardware has no OS, no TCP/IP, no file manager, no
> compiler. So you have to quote the potential customer on writing all these
> layers of software, potentially tens of millions of lines of code.
> Even porting an existing OS to the new hardware is not an insignificant
> job. Think how much time and money it would take.[/color]

Then factor in the profits to be reaped from selling the ported
OS/compilers :-).

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Alex Martelli]

Re: Python vs Ruby

Mike Meyer <mwm@mired.or g> wrote:
[color=blue][color=green]
> > Every line = more labour for the developer = more cost and time.
> > Every line = more places for bugs to exist = more cost and time.[/color]
>
> There were studies done in the 70s that showed that programmers
> produced the same number of debugged lines of code a day no matter
> what language they used. So a language that lets you build the same
> program with fewer lines of code will let you build the program in
> less time.[/color]

Of course, these results only apply where the "complexity " (e.g., number
of operators, for example) in a single line of code is constant. There
is no complexity advantage to wrapping up code to take fewer LINES, as
such -- e.g., in Python:

for item in sequence: blaap(item)

or

for item in sequence:
blaap(item)

are EXACTLY as easy (or hard) to write, maintain, and document -- it's
totally irrelevant that the number of lines of code has "doubled" in the
second (more standard) layout of the code!-)

This effect is even more pronounced in languages which allow or
encourage more extreme variation in "packing" of code over lines; e.g.,
C, where

for(x=0; x<23; x++) { a=seq[x]; zap(a); blup(a); flep(a); }

and

for(x=0;
x<23;
x++)
{
a=seq[x];
zap(a);
blup(a);
flep(a);
}

are both commonly used styles -- the order of magnitude difference in
lines of code is totally "illusory".


Alex