Re: New to Python: my impression v. Perl/Ruby

Ben Giddings <[e-mail]> wrote in message news:<[e-mail]>...
> On Jan 22, 2004, at 05:50, GGarramuno wrote:
> 
> Overall, I think it's more Matz' philosophy that you shouldn't write 
> your Ruby code based on how you think the Ruby interpreter will 
> perform, but rather what seems most natural.  Ruby is supposed to be 
> easy for the programmer, not for the interpreter.
> 

Well, most natural to me would likely be something in Spanish as it is
my native tongue, but I'm not holding my breath on ruby understanding
that :)

Speaking seriously, I love that philosophy (and it is also why I
prefer Ruby syntactically to python, where there is usually only one
-very strict- way of doing things).
But you are mistaken in thinking that I see times() and other integer
constructs more readable.  I honestly don't.
That's why I prefer for/loops to all the other looping constructs as
to me they are both more natural and more readable down the line, as
was mentioned in the thread --- to me it leaves less room to
interpretation and confusion.  No confusion about writing the block
with brackets or not; much harder to place the loop in a single line;
much more clear to know where the loop limits are, it forces you to
use a looping variable, etc, etc.  Performance is also a concern, but
it goes together with the other issues, too.  It is never as simple a
decision as just choosing speed over all else.  Of course, that is my
opinion and it does not have to be yours.

Yet, for an open philosophy of accepting different similar idioms, all
equivalent constructs have to perform at roughly equivalent speed. 
That is also something to be admired in Perl.

If not, whether you admit it or not, you are already "encouraging" the
programmer into a way of writing code (not necessarily a bad idea,
mind you, but you might as well go all the way and put this info in
the docs and tutorials then).

> Aside from that, there's the philosophy of "don't optimize code too 
> soon".  

True, but all languages have constructs that are faster than others. 
And part of learning any language to me is also to know about those
constructs and make a habit out of them (and teaching those constructs
to others, too).
Thus, even in a fast language such as C++, for example, I find it best
to avoid writing i++ anywhere but when absolutely necessary, instead
choosing the cheaper ++i.  Nobody would accuse me of premature
optimization for that, but it is a habit that comes in really useful
once you start dealing with iterators and the STL, for example.  If
you learn that earlier in the language, you are better off than trying
to relearn it years down the line, imho.

Ruby still being a young and evolving language makes this still a
moving target, perhaps, but I'm sure that architecture decisions will
always keep favoring some constructs over others.