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