The UnZen of UnPython

An inverted version of the original by Tim Peters

• Ugly is better than beautiful because there's no time to make it beautiful, and beauty is just a matter of opinion.
• Implicit is better than explicit because explicit violates DRY.
• Complex is better than simple because no one needs a consultant to do simple things
• Complicated is better than complex because you don't want to tie the developer to anything prematurely.
• Nested is better than flat because hierarchy keeps things organized.
• Dense is better than sparse because sparse wastes space and time.
• Readability doesn't count because personal expressiveness is more important.
• Special cases are special enough to break the rules specialized dialects let you better express your meaning.
• Although purity beats practicality because you only go around once, you better do it right.
• Errors should pass silently because status return codes are more explicit.
• Unless explicitly raised because unhandled exceptions cause problems.
• In the face of ambiguity, guess because at least you'll be matching someone's expectations, as opposed to no one.
• There should be several obvious way to do it because people think in many different ways, and for each there should be a way that matches their thought process.
• Never is better than now because we don't want to be rushed.
• Although *right* now is often better than never because we can always change our minds.
• If the implementation is easy to explain, it's a bad idea because then the programmer could have done it on their own, and we don't need to add yet another idea to the system.
• If the implementation is hard to explain, it may be a good idea because clearly something neat and magical is going on there.
• Namespaces honk let's not look like clowns!

It's the UnZen because I also destroy any Zenness when I explain each item. No elegant koans here. And I left out the Dutch one; I didn't feel like picking on some arbitrarily chosen nationality.

But for just about each idea, it seems like there's someone or some project that really does value the opposite idea. They seem to fall into two camps: the first several for cowboy coders and cowboy languages (*coughperlcough*), and the second half are ivory tower programmers and languages (*coughschemecough*). Inverting the error handling reminds me of this article. Complex syntax and special cases reminds me of people who defend Perl as a Huffman coding of programmer intent. Just to name a few.

Anyway, food for thought.