Re: deciding between ruby and python

>     Atrdridel> Then with an array of Sockets, you can do:
> 
>     Atrdridel> [......].join("\n")
> 
>     Atrdridel> src: 10.10.0.0 dest: 10.10.0.1
>     Atrdridel> src: 10.10.0.0 dest: 10.10.0.2
> 
>     Atrdridel> Useful?
> 
> Indeed it is. We do the same thing in Python (just define __str__() in
> your classes), but with the added spice of "explicit is better than
> implicit". So you need to coerce thems to strings before you join
> them:
> 
> list_as_strings = [str(e) for e in list_of_objects]
> 
> I consider this a feature, because it leads to more robust code and
> less surprises. If I expected to have a list of strings, but one
> element is a socket, I should know about it.

Hm. In this case, defining (locally!) the Socket#to_str method seems to
me to be saying "Yes, I know this could be a socket". Instead of putting
it in the code that deals with the list, though, we just put it in the
class -- same thing said, a different way.

> 'Explicit is better than implicit' comes from "Zen of Python", if
> someone didn't know. Those who didn't, check out:
> 
> http://www.python.org/doc/Humor.html#zen

This is one reason Python is better than Ruby: More english-language Zen
stories.

Actually, though, I think that the Zen of Python sums up the differences
very well, and shows why people prefer one language or the other.

	Beautiful is better than ugly.

We agree here.

	Explicit is better than implicit.

Or just "do what I wanted, as long as it's clear"

	Simple is better than complex.
	Complex is better than complicated.

Absolutely.

	Flat is better than nested.

I don't think Ruby programmers thing either way on that one.

	Sparse is better than dense.

Clear and modular is better than dense and coupled.

	Readability counts.

Readability counts, but if things are too plain, you won't like
programming in it.

	Special cases aren't special enough to break the rules.

Special cases that are actually used warrant some attention.

	Although practicality beats purity.

Certainly!

	Errors should never pass silently.
	Unless explicitly silenced.

Though what is an error and what is simply not pure is a matter of
taste.

	In the face of ambiguity, refuse the temptation to guess.

But sometimes, the right thing is obvious, even without mathematical
proof.

	There should be one-- and preferably only one --obvious way to do it.

If it is surprising that it doesn't work that way, too, then it should
be added. 

	Although that way may not be obvious at first unless you're Dutch.

Though you should read "surprising" as "surprising to Matz"

	Now is better than never.

Definately. But don't forget to unit-test it anyway.

	Although never is often better than *right* now.

Just pick a scope for your work, and stick to it.

	If the implementation is hard to explain, it's a bad idea.
	If the implementation is easy to explain, it may be a good idea.

If it can be stated in blunt, clear English by Matz in less than 76
characters, people will listen.

	Namespaces are one honking great idea -- let's do more of those!

Yes, but open classes let you do neat stuff. Just be aware of what
others do with code, so you don't step on their toes.

>     Atrdridel> The tradition of duck-typing and various kinds of
>     Atrdridel> hammer to coerce objects into acting like the
>     Atrdridel> appropriate types is an appealing part of Ruby.
> 
> The duck part applies to Python too (even though we usually speak of
> dynamic typing ;-). The implicit coercion is going to burn you on
> large projects ("Errors should never pass silently. Unless explicitly
> silenced."), though. Perhaps this is indicative of the more general
> Ruby tradition (taking influence of perl?) of optimizing shorter
> scripts at the cost of large scale development?

I think Ruby walks a very fine line, one crafted by Matz with immense
skill: I continuously find myself amazed, thinking "that would be really
fragile if it were any different", but it's not different.

When it comes down to it, I use Ruby and not Python, because I like
Ruby's syntax, and the method names are obvious to me. It walks the
right path for me to follow -- not too brittle, not too heavy-handed
design for me. I write smallish programs, but that's only because when I
wrote large systems before, I realized how much simpler they could be.

Python never attracted me for small scripts, so I never really learned
it (I learned perl and sh and bash and zsh and a bit of TCL first.) ...
then I decided I liked Ruby, because I could start with a script, and
grow it into a well-designed, tested system.

It comes down to the design of the language -- little things. I'm
attracted to Objective C and Smalltalk and Lisp, and pushed away from
C++ and Java, ambivalent about Python (Let me say: I hate having to get
in and mess with it, but I so rarely have to, because things written in
it usually work). I like "messy" languages like sh and awk. Perl is a
nice tool, though I hate it for anything over, say, 100 lines. I do use
it less now that I use Ruby, though while so many people have compared
Ruby to Perl, that doesn't really hold lately. (Actually, how many
python-lovers who read this have tried Ruby 1.8? 1.6?)

I also learned Object Pascal as my first real language, so I like begin
and especially end, not { and }, and not indentation for blocks.

I also like tabs to indent. I resent folding editors. I search for
begin keywords often to navigate code: I often type /if, /else, /def,
just to jump around the screen. (Yes, I use vi)

Matters of taste.

Ari