Python vs Ruby

M

Mike Meyer

I am not sure your intention but I think there isn't a one language
fits all situation here.

Very true.
C/C++ - for linux kernel hacking etc., many library out there still use
it
python - generic stuff
SQL - nothing beats it for many business apps
haskell - a language to train my brain
javascript - Web front end

other than haskell and SQL, the others are more or less the same to me
so getting familiar with them is not too difficult.

There are actually lots of good "train your brain" type
languages. Members of the LISP family, for instance, to learn what you
can do with lists, and also for how cool a real macro facility can
be. I happen to like Scheme, but that's just me. APL, for learning you
can do with arrays. SNOBOL for old-school string processing and
pattern matching. Icon for what you can do with failure. Eiffel for
what you can do with objects and DbC. CLU for duck typing with
declerations. Prolog for what you can do without writing commands. Oz
includes a nice combination of a lot of these things.

The best ones have a book associated with them that teaches general
programming practices using said language as an example - and
hopefully does a good job of it. I've only got four of those:

Scheme: Structure and Interpretation of Computer Programs, by Abelson,
Sussman and Sussman. Commonly called SICP. Available online at <URL:
http://mitpress.mit.edu/sicp/full-text/book/book.html >.

Oz: Concepts, Techniques and Models of Computer Programming, by Van
Roy and Haridi. Sometimes shortened to "The Oz book." Read more about
it at <URL: http://www2.info.ucl.ac.be/people/PVR/book.html >.

Eiffel: Object Oriented Software Construction, by Bertrand
Meyer. Referred to as OOSC. Read more about it at <URL:
http://archive.eiffel.com/doc/oosc/ >.

LISP: On LISP, by Paul Graham. Download it at <URL:
http://www.paulgraham.com/onlisp.html >.

The first three are books about programming that happen to use a
specific language that supports the techniques the authors want to
discuss. On LISP on the other hand is more about what's unique about
LISP programming, at least when compared to more conventional
languages. A lot of what's good about LISP is also good about Python,
so a lot of what he has to say carries over into Python. It's also the
only place to get a thorough look at LISP macro programming, which
knowledge does *not* carry over into Python - but you'll understand
why people ask for macros in Python :).

If you know of some book/language pair that you think everyone would
benefit from reading, I'd be interested in hearing about them.

<mike
 
H

Harald Armin Massa

Casey,

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

BTW: it is normally only 50 lines in Perl. Not that you could read it,
though

Harald
 
T

Torsten Bronger

Hallöchen!

Harald Armin Massa said:
Casey,


BTW: it is normally only 50 lines in Perl. Not that you could read
it, though

At least they could form a heart.

Tschö,
Torsten.
 
T

Tom Anderson

There are actually lots of good "train your brain" type languages.
Members of the LISP family, for instance, to learn what you can do with
lists, and also for how cool a real macro facility can be. I happen to
like Scheme, but that's just me.

I haven't actually done anything much in any LISP, but Scheme definitely
looks like a winner to me - single namespace, generally cleaned-up
language and library, etc.

tom
 
A

Alex Stapleton

Casey,




BTW: it is normally only 50 lines in Perl. Not that you could read it,
though

Harald

Perl is more like a CISC CPU. There are a million different commands.
Python is more RISC like.
Line count comparisons = pointless.
 
B

bruno modulix

Ruby is a whole lot Smalltalk-like -- so if you like Smalltalk... !-)

<troll>
Err... Python is more like what Java would have been if Java was a smart
dynamic hi-level object oriented language !-)

For a whole lot of common tasks (like file IO etc), the Java/Python loc
ratio is between 5/1 and 10/1. Also, not having the dumbest type system
in the world, Python is naturally much more generic than Java, which
saves a lot of boilerplate code. I think that the real numbers would be
much like 5000 lines in Java -> 1000 lines in Python - and probably 5000
-> 500 in some cases.
I've done a lot of studying on my own, and taken the classes that my
high-school offers. I feel that I have a fairly good understanding of Java,
and basic OO concepts due to that.

<IMHO>
Err... I wouldn't start another HolyWar, but Java is not that Object
Oriented. 'Class-based' would be more appropriate. Python, while not
being class-based (ie: it doesn't impose that all code goes into a
'class' statement), is much more an OO language than Java, since in
Python *everything* is an object - even functions, classes and modules.
This makes a *big* difference.

So yes, you may have learned some basic 00 concepts with Java (classes,
instances, inheritence and polymorphism), but with Python and/or Ruby,
you will probably realize that there's much more in the OO paradigm than
all the Java world can dream of.
Well, I'm not sure what you mean by programming concepts. I'm familiar with
OO through Java, and procedural programming through C. I'd be more detailed,
but I'm not exactly sure what you are asking. Sorry.

patterns, metaclasses, aspects, closures, anonymous functions,
higher-order functions, multiple dispatch, properties (computed
attributes), generators, list expressions... does that ring a bell ?
I have no idea what Scheme is, but I'll cettainly look it up as soon as I'm
done writing this.

Scheme is a Lisp dialect - Lisp being one of the oldest programming
languages, and one of the most modern programming languages. Whatever
the latest overhyped revolutionary new silver bullet buzzword stuff, you
can bet your ass Lisp already had it many years ago.

Now Lisp never managed to make it to the mainstream... It's a language
(well, a familly of languages should I say) that is worth learning, but
probably not until you've become familiar with some Python features and
idioms.

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). BTW, most of Ruby's feature have been happily stolen from
Smalltalk !-)
I've never given Perl a shot. It was another language I considered learning,
but my father's friend told me to go with Python or Ruby.

+1



--
bruno desthuilliers
ruby -e "print '(e-mail address removed)'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '(e-mail address removed)'.split('@')])"
 
M

Michael Ekstrand

<troll>
Err... Python is more like what Java would have been if Java was a
smart dynamic hi-level object oriented language !-)
</troll>

+1. Python is easily applicable to most of the problem domain of Java,
but solves problems much more elegantly. It just isn't shipped embedded
in all leading browsers :-(.

- Michael
 
S

Sion Arrowsmith

bruno modulix said:
For a whole lot of common tasks (like file IO etc), the Java/Python loc
ratio is between 5/1 and 10/1. Also, not having the dumbest type system
in the world, Python is naturally much more generic than Java, which
saves a lot of boilerplate code. I think that the real numbers would be
much like 5000 lines in Java -> 1000 lines in Python - and probably 5000
-> 500 in some cases.

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.

As for Ruby, looking at some of the comparisons given elsewhere
in this thread, my intuition is that it would be more loc than
Python due to all the explicit end s.
 
V

vdrab

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

I love this place.
v.
 
T

Tom Anderson

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

+1 QOTW
I love this place.

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

tom
 
S

Scott David Daniels

bruno said:
... 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).
I would say Simula is the forefather of modern OOPLs, and Smalltalk is
the toofather.

--Scott David Daniels
(e-mail address removed)
 
E

Ed Jensen

Sion Arrowsmith said:
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.

This claim seems pretty dubious to me.
 
P

Peter Hansen

Bryan said:
i think you mean "kale" not "cale". nothing like a hot bowl of tofu
kale soup while reading the recipes in the "python cookbook".

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

Kent Johnson

Casey said:
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?)

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

Kent
 
B

Bryan

Ed said:
This claim seems pretty dubious to me.

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
 
A

Alex Martelli

Amol Vaidya said:
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.

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
 
R

Robert Boyd

How can we improve Python's competitiveness in this arena? "Pie"? Or
can we do even better than Lua? Ptooey!

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
 
R

Roy Smith

Robert Boyd said:
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.

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

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Staff online

Members online

Forum statistics

Threads
474,270
Messages
2,571,352
Members
48,034
Latest member
BettinaArn

Latest Threads

Top