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.

[Roy Smith]

In article <Zn***************@tornado.texas.rr.com>,
"Amol Vaidya" <my*****@gmail.com> 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.

Of all the common scripting languages, Ruby has the highest vowel to
consonant ratio.

[jean-marc]

I'd believe that would be Lua, but then again what is common to one
might not be to another ;-)

[Roy Smith]

In article <11**********************@z14g2000cwz.googlegroups .com>,
"jean-marc" <jm*********@cvm.qc.ca> wrote:

I'd believe that would be Lua, but then again what is common to one
might not be to another ;-)

Dang, you're right! Lua's got Ruby beat two-fold!

[Jason Stitt]

On Oct 19, 2005, at 10:01 PM, Roy Smith wrote:

In article <11**********************@z14g2000cwz.googlegroups .com>,
"jean-marc" <jm*********@cvm.qc.ca> wrote:

I'd believe that would be Lua, but then again what is common to one
might not be to another ;-)

Dang, you're right! Lua's got Ruby beat two-fold!

And lack of vowels is definitive proof that PHP is not-so-good, right?

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

- Jason

[Bryan]

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.

why don't you do what i did? download ruby and spend a day or two reading
"programming ruby" from www.ruby-lang.org/en. the download python and spend a
day or two reading the python tuturial from www.python.org. they are very
similar languages and it's going to come down to your personal perference. for
me personally, ruby did not fit in my brain and python did. i used the "how
many times did i have to flip back to a previous page in the manual/tutorial and
reread a section" test. with ruby, once i got about one third of the way
through the manual, i had to constantly reread previous sections. with python,
not once did i need to reread a previous section. therefore, python was the
obvious choice for me.
bryan

[jean-marc]

As you see, pythonistas are a nice humourous bunch...
But to help a bit more in your balancing act you might take a look at:

http://blog.ianbicking.org/ruby-python-power.html

It's rather nice, and commented.

[elbertlev]

Languages are very similar but Python has more cale avaliable. Much
more.

[Dave Cook]

On 2005-10-20, el*******@hotmail.com <el*******@hotmail.com> wrote:

Languages are very similar but Python has more cale avaliable. Much
more.

Cale? You mean Python has more ruffage?

Dave Cook

[Bryan]

Dave Cook wrote:

On 2005-10-20, el*******@hotmail.com <el*******@hotmail.com> wrote:

Languages are very similar but Python has more cale avaliable. Much
more.

Cale? You mean Python has more ruffage?

Dave Cook

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

bryan

[bruno modulix]

Bryan wrote:

Amol Vaidya wrote:

Hi. I am interested in learning a new programming language, and have
been debating whether to learn Ruby or Python.

(snip)
why don't you do what i did? download ruby and spend a day or two
reading "programming ruby" from www.ruby-lang.org/en. the download
python and spend a day or two reading the python tuturial from
www.python.org.

Or better: DiveIntoPython

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

[bruno modulix]

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.

The main point about "advantages" is that Python has a larger community,
a larger choice of libraries, and is somewhat more mature (which is not
surprising since Python is a little bit older than Ruby).

Else, both are hi-level highly dynamic object oriented languages, both
are fun to program with, and both are easy to get started with. So the
best thing to do is to give both a try and go with the one that fits
your brain.

--
bruno desthuilliers
ruby -e "print 'o****@xiludom.gro'.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 'o****@xiludom.gro'.split('@')])"

[beza1e1]

Depends on your experience. If you know C,C++,Java and the whole
C-syntax-bunch. I'd recommend Python just to learn to adapt a different
syntax. If you want to learn for the learnings sake, i'd also recommend
Haskell to try functional programming, if you do not already know it.

Ruby has some interesting concepts, Python (well CPython) does not
have. Blocks for example, which make Continuations possible. In Python
you need stackless Python (a different implementation) to do this.

[gene tani]

http://blog.ianbicking.org/ruby-python-power.html
http://www.ruby-doc.org/RubyEyeForThePythonGuy.html
http://onestepback.org/index.cgi/Tec...onAndRuby.rdoc
http://www.approximity.com/ruby/Comp...st_m_java.html
http://www.jvoegele.com/software/langcomp.html
http://reflectivesurface.com/weblog/...2/19/why-rails

http://martinfowler.com/bliki/Collec...ureMethod.html
http://onestepback.org/articles/10things
http://www.cincomsmalltalk.com/userb...try=3284695382
http://www.tbray.org/ongoing/When/200x/2005/08/27/Ruby
http://pleac.sourceforge.net/
http://dev.rubycentral.com/faq/rubyfaq-2.html

beza1e1 wrote:

Depends on your experience. If you know C,C++,Java and the whole

[Cameron Laird]

In article <43***********************@news.free.fr>,
bruno modulix <on***@xiludom.gro> wrote:

Bryan wrote:

Amol Vaidya wrote:

Hi. I am interested in learning a new programming language, and have
been debating whether to learn Ruby or Python.

(snip)

why don't you do what i did? download ruby and spend a day or two
reading "programming ruby" from www.ruby-lang.org/en. the download
python and spend a day or two reading the python tuturial from
www.python.org.

Or better: DiveIntoPython

[Casey Hawthorne]

What languages do you know already?

What computer science concepts do you know?

What computer programming concepts do you know?
Have you heard of Scheme?
Ruby is a bit Perl like -- so if you like Perl, chances are you might
like Ruby.

Python is more like Java.

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

Roy Smith <ro*@panix.com> wrote:

In article <Zn***************@tornado.texas.rr.com>,
"Amol Vaidya" <my*****@gmail.com> 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.

Of all the common scripting languages, Ruby has the highest vowel to
consonant ratio.

--
Regards,
Casey

[Amol Vaidya]

Thank you for all the great information and links! I think I will do what a
lot of you reccomended and try both for myself, the only problem is finding
time with homework, college applications, and SATs coming up. I'll let you
know how it turns out. Again, thank you all for the help.

[Amol Vaidya]

"Casey Hawthorne" <ca***************@istar.ca> wrote in message
news:02********************************@4ax.com...

What languages do you know already?

What computer science concepts do you know?

What computer programming concepts do you know?
Have you heard of Scheme?
Ruby is a bit Perl like -- so if you like Perl, chances are you might
like Ruby.

Python is more like Java.

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

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. I've created some semi-complex programs
in java, in my opinion, such as networked checkers, 8-player blackjack, a
space-shooter type game, a copy of mario (one level, anyway), and some other
stuff. I've also done a bit of studying on C. I've done a few projects in C,
including another space-shooter type of game using SDL, an IRC client and
some simple database-type programs. I also gave a shot at assembly using
NASM for x86 before, but didn't get too far. I wrote some trivial code --
wrote to the video buffer, played with some bios interrupts, stuff like
that. The only thing I did in assembly was create a program that loads at
boot-up, and loads another program that just reiterates whatever you type
in. I only did that because I was curious. That's about as far as my
programming knowledge/experience goes.

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.

I have no idea what Scheme is, but I'll cettainly look it up as soon as I'm
done writing this.

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.

Thanks for your help. Hopefully I wasn't too lengthy in this post.

[Tom Anderson]

On Thu, 20 Oct 2005, Amol Vaidya wrote:

"Casey Hawthorne" <ca***************@istar.ca> wrote in message
news:02********************************@4ax.com...

What languages do you know already? What computer science concepts do
you know? What computer programming concepts do you know? Have you
heard of Scheme?
Good questions!
Ruby is a bit Perl like -- so if you like Perl, chances are you might
like Ruby.
I don't think rubyists would appreciate that description. Ruby may be
heavier on the funky symbols than python, but it's a very clean, elegant,
usable, well-thought-out and deeply object-oriented language - in other
words, nothing at all like perl.
Python is more like Java.
Python is *nothing* like java.
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?)

ITYM 300. Yes, ruby too.
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. I've created some semi-complex
programs in java, in my opinion, such as networked checkers, 8-player
blackjack, a space-shooter type game, a copy of mario (one level,
anyway), and some other stuff. I've also done a bit of studying on C.
I've done a few projects in C, including another space-shooter type of
game using SDL, an IRC client and some simple database-type programs. I
also gave a shot at assembly using NASM for x86 before, but didn't get
too far. I wrote some trivial code -- wrote to the video buffer, played
with some bios interrupts, stuff like that. The only thing I did in
assembly was create a program that loads at boot-up, and loads another
program that just reiterates whatever you type in. I only did that
because I was curious. That's about as far as my programming
knowledge/experience goes.
An excellent start!
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.
I think i know what Casey means, but i don't know if i can explain it any
better. Do you understand the concept orthogonality? The Once And Only
Once principle? Have you ever heard of design patterns?
I have no idea what Scheme is, but I'll cettainly look it up as soon as
I'm done writing this.
You won't like it. Give yourself another 5-10 years, and you might start
to find it strangely intriguing.
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.
Your father has good friends.
Thanks for your help. Hopefully I wasn't too lengthy in this post.

Lengthy is fine!

Anyway, the upshot of all this is that, yes, you should learn python.
Python is dope!

tom

--
NOW ALL ASS-KICKING UNTIL THE END

[bonono]

I don't think you really need to give to much time in weighting between
python or Ruby. Both are fine. But Python has the obvious advantage
that it has much more modules than Ruby so many things you don't need
to implement if you have real work to do.

I recommend you give haskell a shot if you are "in" to programming
because it makes you think differently, not necessary better(at least
not all the time) but helps.

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

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.

Amol Vaidya wrote:

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. I've created some semi-complex programs
in java, in my opinion, such as networked checkers, 8-player blackjack, a
space-shooter type game, a copy of mario (one level, anyway), and some other
stuff. I've also done a bit of studying on C. I've done a few projects in C,
including another space-shooter type of game using SDL, an IRC client and
some simple database-type programs. I also gave a shot at assembly using
NASM for x86 before, but didn't get too far. I wrote some trivial code --
wrote to the video buffer, played with some bios interrupts, stuff like
that. The only thing I did in assembly was create a program that loads at
boot-up, and loads another program that just reiterates whatever you type
in. I only did that because I was curious. That's about as far as my
programming knowledge/experience goes.

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.

I have no idea what Scheme is, but I'll cettainly look it up as soon as I'm
done writing this.

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.

Thanks for your help. Hopefully I wasn't too lengthy in this post.

[Mike Meyer]

"bo****@gmail.com" <bo****@gmail.com> writes:

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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Michele Simionato]

Tom Anderson:

I have no idea what Scheme is, but I'll cettainly look it up as soon as
I'm done writing this.

You won't like it. Give yourself another 5-10 years, and you might start
to find it strangely intriguing.

+1 ;-)
Michele Simionato

[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

[Torsten Bronger]

Hallöchen!

"Harald Armin Massa" <ha**************@gmail.com> writes:

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

At least they could form a heart.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus ICQ 264-296-646

[Tom Anderson]

On Thu, 20 Oct 2005, Mike Meyer wrote:

"bo****@gmail.com" <bo****@gmail.com> writes:

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.

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

--
For one thing at least is almost certain about the future, namely, that very much of it will be such as we should call incredible. -- Olaf Stapledon

[Alex Stapleton]

On 21 Oct 2005, at 09:31, Harald Armin Massa wrote:

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

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

[bruno modulix]

Amol Vaidya wrote:

"Casey Hawthorne" <ca***************@istar.ca> wrote in message
news:02********************************@4ax.com...

What languages do you know already?

What computer science concepts do you know?

What computer programming concepts do you know?
Have you heard of Scheme?
Ruby is a bit Perl like -- so if you like Perl, chances are you might
like Ruby.
Ruby is a whole lot Smalltalk-like -- so if you like Smalltalk... !-)
Python is more like Java.
<troll>
Err... Python is more like what Java would have been if Java was a smart
dynamic hi-level object oriented language !-)
</troll>
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?)

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

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 'o****@xiludom.gro'.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 'o****@xiludom.gro'.split('@')])"

[Michael Ekstrand]

On Friday 21 October 2005 07:07, bruno modulix wrote:

Python is more like Java.

<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

[Sion Arrowsmith]

bruno modulix <on***@xiludom.gro> wrote:

"Casey Hawthorne" <ca***************@istar.ca> wrote in message
news:02********************************@4ax.com...

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

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.

--
\S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump

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

[Tom Anderson]

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

--
Transform your language.

[Scott David Daniels]

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.

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

[Ed Jensen]

Sion Arrowsmith <si***@chiark.greenend.org.uk> wrote:

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.

[Peter Hansen]

Bryan wrote:

Dave Cook wrote:

Cale? You mean Python has more ruffage?

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

[Kent Johnson]

Casey Hawthorne wrote:

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

[Bryan]

Ed Jensen wrote:

Sion Arrowsmith <si***@chiark.greenend.org.uk> wrote:

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.

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]

Amol Vaidya <my*****@gmail.com> 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.

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]

On 10/19/05, Jason Stitt <ja***@pengale.com> wrote:

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

[Roy Smith]

Robert Boyd <ro***********@gmail.com> wrote:

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

[Terry Hancock]

On Friday 21 October 2005 04:25 pm, Ed Jensen wrote:

Sion Arrowsmith <si***@chiark.greenend.org.uk> wrote:

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.

Why?

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

[Kent Johnson]

Bryan wrote:

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.

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]

Bryan <be****@gmail.com> wrote:

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.

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

[Steven D'Aprano]

On Fri, 21 Oct 2005 13:03:29 +0100, Alex Stapleton wrote:

On 21 Oct 2005, at 09:31, Harald Armin Massa wrote:

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

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

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.

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]

Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:

On Fri, 21 Oct 2005 13:03:29 +0100, Alex Stapleton wrote:

Perl is more like a CISC CPU. There are a million different commands.
Python is more RISC like.
Line count comparisons = pointless.
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.

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

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

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

[Alex Martelli]

Mike Meyer <mw*@mired.org> wrote:

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

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.

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

[Mike Meyer]

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

Mike Meyer <mw*@mired.org> wrote:

> Every line = more labour for the developer = more cost and time.
> Every line = more places for bugs to exist = more cost and time. 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.

Of course, these results only apply where the "complexity" (e.g., number
of operators, for example) in a single line of code is constant.

I'm not sure what you're trying to say here. The tests ranged over
things from PL/I to assembler. Are you saying that those two languages
have the same "complexity in a single line"?
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!-)

The studies didn't deal with maintenance. They only dealt with
documentation in so far as code was commented.

On the other hand, studies of reading comprehension have shown that
people can read and comprehend faster if the line lengths fall within
certain ranges. While it's a stretch to assume those studies apply to
code, I'd personally be hesitant to assume they don't apply without
some reseach. If they do apply, then your claims about the difficulty
of maintaining and documenting being independent of the textual line
lengths are wrong. And since writing code inevitable involves
debugging it - and the studies specified debugged lines - then the
line length could affect how hard the code is to write as well.

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

[Max M]

Mike Meyer wrote:

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.

In my experience the LOC count is *far* less significant than the levels
of indirections.

Eg. how many levels of abstraction do I have to understand to follow a
traceback, or to understand what a method relly does in a complex system.
--

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science

[Alex Martelli]

Mike Meyer <mw*@mired.org> wrote:
...

Of course, these results only apply where the "complexity" (e.g., number
of operators, for example) in a single line of code is constant.

I'm not sure what you're trying to say here. The tests ranged over
things from PL/I to assembler. Are you saying that those two languages
have the same "complexity in a single line"?

Not necessarily, since PL/I, for example, is quite capable of usages at
extremes of operator density per line. So, it doesn't even have "the
same complexity as itself", if used in widely different layout styles.

If the studies imply otherwise, then I'm reminded of the fact that both
Galileo and Newton published alleged experimental data which can be
shown to be "too good to be true" (fits the theories too well, according
to chi-square tests etc)...

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

The studies didn't deal with maintenance. They only dealt with
documentation in so far as code was commented.

On the other hand, studies of reading comprehension have shown that
people can read and comprehend faster if the line lengths fall within
certain ranges. While it's a stretch to assume those studies apply to
code, I'd personally be hesitant to assume they don't apply without
some reseach. If they do apply, then your claims about the difficulty
of maintaining and documenting being independent of the textual line
lengths are wrong. And since writing code inevitable involves
debugging it - and the studies specified debugged lines - then the
line length could affect how hard the code is to write as well.

If time to code depends on textual line lengths, then it cannot solely
depend on number of lines at the same time. If, as you say, the studies
"prove" that speed of delivering debugged code depends strictly on the
LOCs in the delivered code, then those studies would also be showing
that the textual length of the lines is irrelevant to that speed (since,
depending on coding styles, in most languages one can trade off
textually longer lines for fewer lines).

OTOH, the following "mental experiment" shows that the purported
deterministic connection of coding time to LOC can't really hold:

say that two programmers, Able and Baker, are given exactly the same
task to accomplish in (say) language C, and end up with exactly the same
correct source code for the resulting function;

Baker, being a honest toiling artisan, codes and debugs his code in
"expansive" style, with lots of line breaks (as lots of programming
shops practice), so, given the final code looks like:
while (foo())
{
bar();
baz();
}
(etc), he's coding 5 lines for each such loop;

Able, being able, codes and debugs extremely crammed code, so the same
final code looks, when Able is working on it, like:
while (foo()) { bar(); baz(); }
so, Able is coding 1 line for each such loop, 5 times less than Baker
(thus, by hypothesis, Able must be done 5 times faster);

when Able's done coding and debugging, he runs a "code beautifier"
utility which runs in negligible time (compared to the time it takes to
code and debug the program) and easily produces the same "expansively"
laid-out code as Baker worked with all the time.

So, Able is 5 times faster than Baker yet delivers identical final code,
based, please note, not on any substantial difference in skill, but
strictly on a trivial trick hinging on a popular and widely used kind of
code-reformatting utility.
Real-life observation suggests that working with extremely crammed code
(to minimize number of lines) and beautifying it at the end is in fact
not a sensible coding strategy and cannot deliver such huge increases in
coding (and debugging) speed. Thus, either those studies or your
reading of them must be fatally flawed in this respect (most likely,
some "putting hands forward" footnote about coding styles and tools in
use was omitted from the summaries, or neglected in the reading).

Such misunderstandings have seriously damaged the practice of
programming (and managements of programming) in the past. For example,
shops evaluating coders' productivity in terms of lines of code have
convinced their coders to distort their style to emit more lines of code
in order to be measured as more productive -- it's generally trivial to
do so, of course, in many cases, e.g.
for i in range(100):
a[i] = i*i
can easily become 100 lines "a[0] = 0" and so on (easily produced by
copy and paste or editor macros, or other similarly trivial means). At
the other extreme, some coders (particularly in languages suitable for
extreme density, such as Perl) delight in producing "one-liner"
(unreadable) ``very clever'' equivalents of straightforward loops that
would take up a few lines if written in the obvious way instead.

The textual measure of lines of code is extremely easy to obtain, and
pretty easy to adjust to account for some obvious first-order effects
(e.g., ignoring comments and whitespace, counting logical lines rather
than physical ones, etc), and that, no doubt, accounts for its undying
popularity -- but it IS really a terrible measurement for "actual
program size and complexity".

Moreover, even if you normalized "program size" by suitable language
specific factors (number of operators, decision points, cyclomatic
complexity, etc), the correlation between program size and time to code
it would still only hold within broadly defined areas, not across the
board. I believe "The mythical man-month" was the first widely read
work to point out how much harder it is to debug programs that use
unrestrained concurrency (in today's terms, think of multithreading
without any of the modern theory and helpers for it), which Brooks
called "system programs", compared to "ordinary" sequential code (which
Brooks called "application programs" -- the terminology is quite dated,
but the deep distinction remains valid). Also: one huge monolithic
program using global variables for everything is going to have
complexity (and time to delivery of debugged code) that grows way more
than linearly with program size; to keep a relation that's close to
linear (though in no case can exact linearity be repeatably achieved for
sufficiently large programming systems, I fear), we employ a huge
variety of techniques to make our software systems more modular.
It IS important to realize that higher level languages, by making
programs of equivalent functionality (and with comparable intrinsic
difficulty, modularity, etc) "textually smaller" (and thereby
"conceptually" smaller), raises program productivity. But using "lines
of code", without all the appropriate qualifications, for these
measurements, is not appropriate. Even the definition of a language's
level in terms of LOCs per function point is too "rough and ready" and
thus suffers from this issue (function points as a language-independent
measure of a coding task's "size" have their own issues, but much
smaller ones than LOCs as a measure of a delivered code's size).
Consider the analogy of measuring a writing task (in, say, English) by
number of delivered words -- a very popular measure, too. No doubt, all
other things being equal, it may take a writer about twice as much to
deliver 2000 copy-edited words than to deliver 1000. But... all other
things are rarely equal. To me, for example, it often comes most
natural to take about 500 words to explain and illustrate one concept;
but when I need to be concise, I will then take a lot of time to edit
and re-edit that text until just about all of the same issues are put
across in 200 words or less. It may take me twice as long to rewrite
the original 500 words into 200, as it took to put down the 500 words in
the first place -- which helps explains why many of my posts are so
long, as I don't take all the time to re-edit them, and why it taks so
long to write a "Nutshell" series book, where conciseness is crucial.

Nor it is only my own issue... 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"!-)
Alex

[bruno modulix]

Michael Ekstrand wrote:

On Friday 21 October 2005 07:07, bruno modulix wrote:

Python is more like Java.

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

It's been a long time since I last saw a Java applet on a website.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[bruno modulix]

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)

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