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.
Oct 20 '05
65 5268
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('@')])"
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
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
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
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
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 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>
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
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
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('@')"
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.
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.
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.
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
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>
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> This discussion thread is closed Replies have been disabled for this discussion. Similar topics
reply
views
Thread by Adam |
last post: by
|
220 posts
views
Thread by Brandon J. Van Every |
last post: by
|
54 posts
views
Thread by Brandon J. Van Every |
last post: by
|
467 posts
views
Thread by mike420 |
last post: by
|
13 posts
views
Thread by Wayne Folta |
last post: by
|
30 posts
views
Thread by Christian Seberino |
last post: by
|
22 posts
views
Thread by Francois |
last post: by
|
52 posts
views
Thread by Steve Holden |
last post: by
|
reply
views
Thread by bruce |
last post: by
| | | | | | | | | | |