Comparison between Python and "Ruby"

[Thomas A. Bryan]

Gerrit Holl wrote:
> 
> Yukihiro Matsumoto wrote:
> >
> > I guess he loves reducing variablity, if possible, which is totally
> > against TMTOWTDI.  I don't judge whether it is good or bad.
> >
> 
> Are there people who see TMTOWTDI [1] as an advantage?
> [1]
> There's more than one way to do it.

Yes, there are.  Larry Wall's speeches (Wall is the Guido of Perl)
often proclaim that the problem with many programming languages 
is that they enforce too many restrictions on the programmer and 
his code.  Thus, given a problem, the programmer first has to map 
that problem onto what is permitted by the language.  The less 
flexibility the language offers, the more difficult this mapping 
process can be for more problems.  Perl is supposed to reduce the 
amount of mapping that a programmer has to do before implementation.

It's an interesting concept, but I don't know whether I agree that 
this aspect of Perl is a "feature."  I haven't been programming long 
enough to decide.  Some experienced C/C++ software engineers that 
I've known complain that Larry Wall is ignoring the years of industry 
and academic wisdom in software engineering when he says things like 
that.  Code typically spends a lot of time in maintenance by a lot 
of different people.  (If it doesn't, it simply dies.)  If a language 
offers too much flexibility, then it doesn't matter if you know the 
language.  You still may have a really hard time understanding someone 
else's code in that language.  If you think about it, a lot of people's 
Python code looks very similar in structure and syntax.  I don't think 
that's as true in the Perl world.  

In my own personal experience, I've never had trouble reading other
people's Python code.  I often have to struggle through other people's
Perl code.  Even when I knew more Perl than Python, this statement was 
still true.  When I read Perl code, I spent too much of the time 
figuring out *how* the code worked instead of figuring out *what* the 
code was doing.  I suspect that this difficulty was due in part to 
the fact that Perl has more Perl hackers than Python has Pythonistas.
Thus, it also has more *bad* programmers producing *bad* code.

To keep myself from rambling too much, I'll summarize by simply saying 
that if Python is more restrictive than Perl, I've never noticed it, and 
I've never felt that my options were limited in Python.  On the other 
hand, when I go to the more flexible world of Perl, I seem to spend a 
lot of time just dealing with the language.  Python gives me sufficient 
power and flexibility but then stays out of my way and lets me think 
about data structures, algorithms, and design patterns.  

I'll close with something Tim Peters posted once about "The Python Way."
Note the item about "only one obvious way."  There might be other ways, 
but they're usually non-obvious and not often used in Python.

"""Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.     
Now is better than never.
Although never is often better than *right* now.
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.     
Namespaces are one honking great idea -- let's do more of those! """

---Tom