The Zens of Python and Ruby

I've had this idea kicking around in my head for a while that someone ought to rewrite The Zen of Python from a Ruby perspective. Despite their many similarities (very high-level, multi-paradigm, interpreted and dynamic), Python and Ruby have nearly opposite design principles in many areas. Similarly, programmers of the two languages seem (to me anyway) to have different attitudes about readability and documentation, and what constitutes "cleverness" in programming (and whether cleverness is good or bad).

Having used Ruby regularly for a few years, and Python for much longer, and having formed some negative impressions of Ruby, I thought I would attempt this tongue-in-cheek comparison of the two languages. Don't get me wrong--I like Ruby quite a lot, even more than Python in some respects (especially blocks); the Zen of Ruby may come across as a little insulting, and more than a little inaccurate, but it was fun to write, and I think a productive way to vent a few of my frustrations with learning the language.

Without further ado:

The Zen of Python
by Tim Peters
The Zen of Ruby
by Eric Pierce
Beautiful is better than ugly. Beauty is in the eye of the beholder.
Explicit is better than implicit. Implicit is preferable to explicit.
Simple is better than complex. Simple is boring.
Complex is better than complicated. Complex is interesting.
Flat is better than nested. Delegate the details to someone else.
Sparse is better than dense. If possible, make it a one-liner.
Readability counts. Readability is sometimes nice.
Special cases aren't special enough to break the rules. Special cases are everywhere; the rules can't cover them all.
Although practicality beats purity. When in doubt, monkeypatch.
Errors should never pass silently. Errors should be suppressed.
Unless explicitly silenced. Unless whiny nils is turned on.
In the face of ambiguity, refuse the temptation to guess. When in doubt, make assumptions about what the user wanted.
There should be one-- and preferably only one --obvious way to do it. There should be many-- preferably dozens --of non-obvious ways to do it.
Although that way may not be obvious at first unless you're Dutch. What's obvious to you may be completely unintuitive to someone else.
Now is better than never. Now is better than later.
Although never is often better than *right* now. And later is better than never.
If the implementation is hard to explain, it's a bad idea. If the design is flawed, explain why in the implementation docs.
If the implementation is easy to explain, it may be a good idea. If the design is good, don't bother with implementation docs.
Namespaces are one honking great idea -- let's do more of those! Namespaces are completely unnecessary -- let's make everything global!


Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • Each email address will be obfuscated in a human readable fashion or (if JavaScript is enabled) replaced with a spamproof clickable link.

More information about formatting options

This question tests whether you are a human visitor, to prevent automated spam submissions.
Question text provided by