Python vs Ruby

2005-10-19 Thread 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. 


-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-19 Thread Roy Smith
In article <[EMAIL PROTECTED]>,
 "Amol Vaidya" <[EMAIL PROTECTED]> 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.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-19 Thread jean-marc
I'd believe that would be Lua, but then again what is common to one
might not be to another ;-)

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-19 Thread Roy Smith
In article <[EMAIL PROTECTED]>,
 "jean-marc" <[EMAIL PROTECTED]> 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!
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-19 Thread Jason Stitt
On Oct 19, 2005, at 10:01 PM, Roy Smith wrote:

> In article <[EMAIL PROTECTED]>,
>  "jean-marc" <[EMAIL PROTECTED]> 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

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-19 Thread 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

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-19 Thread 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.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-19 Thread elbertlev
Languages are very similar but Python has more cale avaliable. Much
more.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-19 Thread Dave Cook
On 2005-10-20, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

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

Cale?  You mean Python has more ruffage?

Dave Cook
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-19 Thread Bryan
Dave Cook wrote:
> On 2005-10-20, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-20 Thread 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 '[EMAIL PROTECTED]'.split('@')])"
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-20 Thread 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 '[EMAIL PROTECTED]'.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 '[EMAIL PROTECTED]'.split('@')])"
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-20 Thread 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.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-20 Thread gene tani
http://blog.ianbicking.org/ruby-python-power.html
http://www.ruby-doc.org/RubyEyeForThePythonGuy.html
http://onestepback.org/index.cgi/Tech/Ruby/PythonAndRuby.rdoc
http://www.approximity.com/ruby/Comparison_rb_st_m_java.html
http://www.jvoegele.com/software/langcomp.html
http://reflectivesurface.com/weblog/2004/12/19/why-rails

http://martinfowler.com/bliki/CollectionClosureMethod.html
http://onestepback.org/articles/10things
http://www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=true&entry=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

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-20 Thread Cameron Laird
In article <[EMAIL PROTECTED]>,
bruno modulix  <[EMAIL PROTECTED]> 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
.
.
.
You've already been told all the essentials:  that they're similar,
that specific Web pages usefully contrast them, that *Dive into Python*
and so on are worth reading, ...  I want to emphasize particularly the
wisdom of trying the two for yourself, to see how each fits your own 
tastes.  This is practical advice; it truly is possible to have a 
meaningful experience with Python and/or Ruby over the course of a day.
These languages are FAR more "light-weight" than, for example, C++, 
which typically requires weeks or months of practice before one truly
"gets it".  While you won't know everything about, say, Ruby, in the
first four hours, you *will* be able to write programs independently,
and you'll have a "feel" for how the language works as a whole.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-20 Thread 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 <[EMAIL PROTECTED]> wrote:

>In article <[EMAIL PROTECTED]>,
> "Amol Vaidya" <[EMAIL PROTECTED]> 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-20 Thread 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. 


-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-20 Thread Amol Vaidya

"Casey Hawthorne" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> 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. 


-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-20 Thread Tom Anderson
On Thu, 20 Oct 2005, Amol Vaidya wrote:

> "Casey Hawthorne" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>> 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-20 Thread [EMAIL PROTECTED]
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.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-20 Thread Mike Meyer
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> 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 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 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 http://archive.eiffel.com/doc/oosc/ >.

LISP: On LISP, by Paul Graham. Download it at 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.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-21 Thread 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

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-21 Thread 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

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-21 Thread Torsten Bronger
Hallöchen!

"Harald Armin  Massa" <[EMAIL PROTECTED]> 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 vetusICQ 264-296-646
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-21 Thread Tom Anderson
On Thu, 20 Oct 2005, Mike Meyer wrote:

> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-21 Thread 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.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-21 Thread bruno modulix
Amol Vaidya wrote:
> "Casey Hawthorne" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> 
>>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.


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


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


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 '[EMAIL PROTECTED]'.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 '[EMAIL PROTECTED]'.split('@')])"
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-21 Thread Michael Ekstrand
On Friday 21 October 2005 07:07, bruno modulix wrote:
> >>Python is more like Java.
>
> 
> Err... Python is more like what Java would have been if Java was a
> smart dynamic hi-level object oriented language !-)
> 

+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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-21 Thread Sion Arrowsmith
bruno modulix  <[EMAIL PROTECTED]> wrote:
>> "Casey Hawthorne" <[EMAIL PROTECTED]> wrote in message 
>> news:[EMAIL PROTECTED]
>>>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 -- [EMAIL PROTECTED] -- 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs Ruby

2005-10-21 Thread 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.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-21 Thread 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.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-21 Thread 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
[EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-21 Thread Ed Jensen
Sion Arrowsmith <[EMAIL PROTECTED]> 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.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-21 Thread 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". ;-)
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-21 Thread 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-21 Thread Bryan
Ed Jensen wrote:
> Sion Arrowsmith <[EMAIL PROTECTED]> 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

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-21 Thread Alex Martelli
Amol Vaidya <[EMAIL PROTECTED]> 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 < 100
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 

real0m5.367s
user0m5.129s
sys 0m0.041s

while:

Helen:~ alex$ time python tim.py

real0m1.078s
user0m0.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

Re: Python vs Ruby

2005-10-21 Thread Robert Boyd
On 10/19/05, Jason Stitt <[EMAIL PROTECTED]> 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-21 Thread Roy Smith
Robert Boyd <[EMAIL PROTECTED]> 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 :-)
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-21 Thread Terry Hancock
On Friday 21 October 2005 04:25 pm, Ed Jensen wrote:
> Sion Arrowsmith <[EMAIL PROTECTED]> 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

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-21 Thread 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-21 Thread Ed Jensen
Bryan <[EMAIL PROTECTED]> 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.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-22 Thread 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.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-22 Thread Mike Meyer
Steven D'Aprano <[EMAIL PROTECTED]> 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 :-).

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-22 Thread Alex Martelli
Mike Meyer <[EMAIL PROTECTED]> 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-22 Thread Mike Meyer
[EMAIL PROTECTED] (Alex Martelli) writes:
> Mike Meyer <[EMAIL PROTECTED]> 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.

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-23 Thread 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-23 Thread Alex Martelli
Mike Meyer <[EMAIL PROTECTED]> 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'' equiv

Re: Python vs Ruby

2005-10-24 Thread bruno modulix
Michael Ekstrand wrote:
> On Friday 21 October 2005 07:07, bruno modulix wrote:
> 
Python is more like Java.
>>
>>
>>Err... Python is more like what Java would have been if Java was a
>>smart dynamic hi-level object oriented language !-)
>>
> 
> 
> +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 '[EMAIL PROTECTED]'.split('@')])"
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-24 Thread bruno modulix
Alex Martelli wrote:
(snip)
> Here's a tiny script showing some similarities and differences:
> 
> def f()
>   i = 0
>   while i < 100
> 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 '[EMAIL PROTECTED]'.split('@')])"
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-24 Thread 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

SSsh! Xah Lee might be listening!

Iain

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-24 Thread 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

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-24 Thread Alex Martelli
Michele Simionato <[EMAIL PROTECTED]> 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-24 Thread Jorge Godoy
[EMAIL PROTECTED] (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  <[EMAIL PROTECTED]>
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-24 Thread 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

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-24 Thread Alex Martelli
Jorge Godoy <[EMAIL PROTECTED]> wrote:

> [EMAIL PROTECTED] (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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-26 Thread 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.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-26 Thread 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.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-27 Thread 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.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-10-27 Thread Lawrence Oluyede
Il 2005-10-27, Andy Leszczynski  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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python vs Ruby

2005-11-16 Thread 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_oriented#Prototype-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 ?


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


-- 
http://mail.python.org/mailman/listinfo/python-list


Re: [OT] Python vs Ruby

2005-10-24 Thread 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 '[EMAIL PROTECTED]'.split('@')])"
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: [OT] Python vs Ruby

2005-10-24 Thread 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
[EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: [OT] Python vs Ruby

2005-10-24 Thread 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: [OT] Python vs Ruby

2005-10-25 Thread 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 '[EMAIL PROTECTED]'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
-- 
http://mail.python.org/mailman/listinfo/python-list