Python vs Ruby

[Amol Vaidya]

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.

[bruno modulix]

Alex Martelli wrote:
(snip)

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
s/at/add/
at the end of the def
and while statements, and this is also valid Python.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Iain King]

Tom Anderson wrote:

On Fri, 21 Oct 2005, vdrab wrote:

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

SSshhhhhhhhh! Xah Lee might be listening!

Iain

[Scott David Daniels]

bruno modulix wrote:

Scott David Daniels wrote:

bruno modulix wrote:

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

Err... I'm afraid I don't understand this last word (and google have not
been of much help here)

Sorry, I was being too cute by half. If Simula is the fore father
(4 away) then Smalltalk is half as far (2) away. Hence the "toofather."
"Toofather" by analogy with the homophones "fore" and "four" we use the
homophones "two" and "too".

--Scott David Daniels
sc***********@acm.org

[Michele Simionato]

Alex Martelli wrote:

... remember Pascal's "Lettres Provinciales",
and the famous apology about "I am sorry that this letter is so long,
but I did not have the time to write a shorter one"!-)

This observation applies to code too. I usually spend most of my time
in making short programs
that would have been long. This means:

cutting off non-essential features (and you can discover that a feature
is non essential only after having implemented it)

and/or

rethinking the problem to a superior level of abstraction (only
possible after you have implented
the lower level of abstraction).

Michele Simionato

[Neil Hodgson]

Scott David Daniels:

Sorry, I was being too cute by half. If Simula is the fore father
(4 away) then Smalltalk is half as far (2) away. Hence the "toofather."
"Toofather" by analogy with the homophones "fore" and "four" we use the
homophones "two" and "too".

We could smear the homophones further and say OCaml is the "nextfather".

Neil

[Alex Martelli]

Michele Simionato <mi***************@gmail.com> wrote:

Alex Martelli wrote:

... remember Pascal's "Lettres Provinciales",
and the famous apology about "I am sorry that this letter is so long,
but I did not have the time to write a shorter one"!-)
This observation applies to code too. I usually spend most of my time
in making short programs
that would have been long. This means:

Absolutely true.
cutting off non-essential features (and you can discover that a feature
is non essential only after having implemented it)
This one is difficult if you have RELEASED the program with the feature
you now want to remove, sigh. You end up with lots of "deprecated"s...
somebody at Euro OSCON was saying that this was why they had dropped
Java, many years ago -- each time they upgraded their Java SDK they
found out that half their code used now-deprecated features.

Still, I agree that (once in a while) accepting backwards
incompatibility by removing features IS a good thing (and I look
forwards a lot to Python 3.0!-). But -- the "dream" solution would be
to work closely with customers from the start, XP-style, so features go
into the code in descending order of urgence and importance and it's
hardly ever necessary to remove them.
and/or

rethinking the problem to a superior level of abstraction (only
possible after you have implented
the lower level of abstraction).

Yep, this one is truly crucial.

But if I had do nominate ONE use case for "making code smaller" it would
be: "Once, And Only Once" (aka "Don't Repeat Yourself"). Scan your code
ceaselessly mercilessly looking for duplications and refactor just as
mercilessly when you find them, "abstracting the up" into functions,
base classes, etc...
Alex

[Jorge Godoy]

al*****@yahoo.com (Alex Martelli) writes:

forwards a lot to Python 3.0!-). But -- the "dream" solution would be
to work closely with customers from the start, XP-style, so features go
into the code in descending order of urgence and importance and it's
hardly ever necessary to remove them.
We do that often with two of our customers here. After the first changes,
they asked for more. And them some other and when it finally ended, the
project was like we had suggested, but instead of doing this directly, the
client wanted to waste more money... :-( Even if we earnt more money, I'd
rather have the first proposal accepted instead of wasting time working on
what they called "essential features".
But if I had do nominate ONE use case for "making code smaller" it would
be: "Once, And Only Once" (aka "Don't Repeat Yourself"). Scan your code
ceaselessly mercilessly looking for duplications and refactor just as
mercilessly when you find them, "abstracting the up" into functions,
base classes, etc...

And I'd second that. Code can be drastically reduced this way and even
better: it can be made more generic, more useful and robustness is improved.

--
Jorge Godoy <go***@ieee.org>

[Michele Simionato]

Alex Martelli:

Michele Simionato:

cutting off non-essential features (and you can discover that a feature
is non essential only after having implemented it)

This one is difficult if you have RELEASED the program with the feature
you now want to remove, sigh.

Yeah, but I used the wrong word "features", which typically means "end
user features".
Instead, I had in mind "developer features", i.e. core features that
will be called later
in "client" code (I am in a framework mindset here).

Typically I start with a small class, then the class becomes larger as
I add features that will
be useful for client code, then I discover than the class has become
difficult to mantain.
So I cut the features and and I implement them outside the class and
the class becomes
short again.

However, I *cannot* know from the beginning what is the minimal set of
features
needed to make short the client code until I write a lot of client
code. I can make things short
only after I have made things long. I think this applies to me, to you,
to Pascal and to
everybody in general. It is impossible to start from the beginning with
the short program,
unless you already know the solution (that means, you have already
written the long
version in the past). Still, some naive people think there is a silver
bullet or an easy way
to avoid the hard work. They are naive ;)

Michele Simionato

[Alex Martelli]

Jorge Godoy <go***@ieee.org> wrote:

al*****@yahoo.com (Alex Martelli) writes:

forwards a lot to Python 3.0!-). But -- the "dream" solution would be
to work closely with customers from the start, XP-style, so features go
into the code in descending order of urgence and importance and it's
hardly ever necessary to remove them.

We do that often with two of our customers here. After the first changes,
they asked for more. And them some other and when it finally ended, the
project was like we had suggested, but instead of doing this directly, the
client wanted to waste more money... :-( Even if we earnt more money, I'd
rather have the first proposal accepted instead of wasting time working on
what they called "essential features".

The customer is part of the team; if any player in the team is not
performing well, the whole team's performance will suffer -- that's
hardly surprising. You may want to focus more on _teaching_ the
customer to best play his part in the feature-selection game, in the
future... not easy, but important.

But if I had do nominate ONE use case for "making code smaller" it would
be: "Once, And Only Once" (aka "Don't Repeat Yourself"). Scan your code
ceaselessly mercilessly looking for duplications and refactor just as
mercilessly when you find them, "abstracting the up" into functions,
base classes, etc...

And I'd second that. Code can be drastically reduced this way and even
better: it can be made more generic, more useful and robustness is improved.

I'll second all of your observations on this!-)
Alex

[bruno modulix]

Scott David Daniels wrote:

bruno modulix wrote:

Scott David Daniels wrote:

bruno modulix wrote:

... 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.
Err... I'm afraid I don't understand this last word (and google have not
been of much help here)

Sorry, I was being too cute by half.

tss...
If Simula is the fore father
(4 away) then Smalltalk is half as far (2) away. Hence the "toofather."
"Toofather" by analogy with the homophones "fore" and "four" we use the
homophones "two" and "too".

My my my...

--
bruno desthuilliers
ruby -e "print 'o****@xiludom.gro'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"

[Andy Leszczynski]

Steven D'Aprano wrote:

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

The place I work at the creation rate is not a problem - we could crank
out in the team 1000s lines a week. Most time we spend is on maintanance
.. This is where Pyton shines over Java/C++/Perl. It is easy to read thus
maintane.

A.

[Andy Leszczynski]

Amol Vaidya wrote:

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.

How Ruby solves the problem of global interpreter lock?

A.

[Steven D'Aprano]

On Wed, 26 Oct 2005 22:35:33 -0500, Andy Leszczynski wrote:

Steven D'Aprano wrote:

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

The place I work at the creation rate is not a problem - we could crank
out in the team 1000s lines a week.

Good on you. I assume those thousands of lines are good ones, and not
just churning out quantity instead of quality.

In any case, no matter how fast you are, you will be faster if you have
fewer lines to write.
Most time we spend is on maintanance
. This is where Pyton shines over Java/C++/Perl. It is easy to read thus
maintane.

Yes. Now imagine how much less maintenance you'd have to do with fewer
lines.

Of course, it is easy to take this to extremes. One thing which is a red
rag to me is when folks have written perfectly good, efficient, fast,
readable code in four lines, and then obsess "how can I write this as a
one-liner?". That way to the Dark Side goes: unreadable, cryptic,
unmaintainable, buggy code.

In any case, lines of code is a very poor metric for measuring programmer
productivity. I'm not even so sure it is better than nothing -- in some
cases, it is *worse* than nothing.

--
Steven.

[Lawrence Oluyede]

Il 2005-10-27, Andy Leszczynski <leszczynscyATnospam.yahoo.com.nospam> ha scritto:

How Ruby solves the problem of global interpreter lock?

AFAIK Ruby does not have those kind of problems, it does not have "real" threads
but it emulates them via software

--
Lawrence
http://www.oluyede.org/blog

[bellarchitects]

bruno modulix wrote:

It's been a long time since I last saw a Java applet on a website.

That can only mean you are ignorant.
Applets are a huge deal for Intranets. And Java Web Start is even more
useful. I really wish Python had such wonderful means of deployment.

bruno modulix wrote 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.
I think you are confusing terms. Class-based means that the language
uses classes and class inheritance and not object prototyping (as in
javascript):
http://en.wikipedia.org/wiki/Object_...e-based_models

And why should functions be objects ? Actually, this makes it less OOP
if we consider Smaltalk as being true OOP ;)
Python is here more pragmatic but less OOP, please try to remember it.

And haven't you heard of java.lang.Class or java.lang.reflect.Method ?
Classes in Java *ARE* objects. Or do you think all those static methods
and properties just pop out of the ground ? Voodoo maybe ? :)

The reason classes don't behave as objects is because that's only
usefull for reflection and meta-programming and that can be achieved by
using the java.lang.reflect package which IMHO it really makes sense
the way it was implemented.

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

You see, I rarely see this kind of rubish on comp.lang.ruby. Shame on
you.
Do you realy think you are doing the Python community a favor by
bashing Java ?

<troll>
And yeah, LOC count is stupid. Productivity in general measured in LOC
is stupid. For that Java has a simple syntax which anyone can learn in
only a few hours (simpler than Python's ... a lot imho) and tools like
Eclipse, Netbeans, Studio Creator, JBuilder, etc ...
</troll>

[bellarchitects]

bruno modulix wrote:

It's been a long time since I last saw a Java applet on a website.

That can only mean you are ignorant.
Applets are a huge deal for Intranets. And Java Web Start is even more
useful. I really wish Python had such wonderful means of deployment.

bruno modulix wrote 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.
I think you are confusing terms. Class-based means that the language
uses classes and class inheritance and not object prototyping (as in
javascript):
http://en.wikipedia.org/wiki/Object_...e-based_models

And why should functions be objects ? Actually, this makes it less OOP
if we consider Smaltalk as being true OOP ;)
Python is here more pragmatic but less OOP, please try to remember it.

And haven't you heard of java.lang.Class or java.lang.reflect.Method ?
Classes in Java *ARE* objects. Or do you think all those static methods
and properties just pop out of the ground ? Voodoo maybe ? :)

The reason classes don't behave as objects is because that's only
usefull for reflection and meta-programming and that can be achieved by
using the java.lang.reflect package which IMHO it really makes sense
the way it was implemented.

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

You see, I rarely see this kind of rubish on comp.lang.ruby. Shame on
you.
Do you realy think you are doing the Python community a favor by
bashing Java ?

<troll>
And yeah, LOC count is stupid. Productivity in general measured in LOC
is stupid. For that Java has a simple syntax which anyone can learn in
only a few hours (simpler than Python's ... a lot imho) and tools like
Eclipse, Netbeans, Studio Creator, JBuilder, etc ...
</troll>