The victim: http://www.python.org/dev/peps/pep-0020/

Original text:
The Zen of 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!

Annotation:
Perhaps these jokes should only be treated seriously with Python, otherwise:
Beautiful is better than ugly.
↑Nonsense.
Explicit is better than implicit.
↑Foolish. Explicitly should not be mandated. One powerful mechanism we mankind have learned is, tooling automatically is often preferred to accomplish something repeated. This requires the power granted by implicit rules, which should be reusable fine-grained sets of methods.
Simple is better than complex.
↑Usually non-feasible, cuz one had to spend time looking into "which should be the simpler", and often difficult to get the ideal result.

Flat is better than nested.
↑Absurd. Things nested properly are structural. Flat is somewhat attractive, but not always means to do something simpler or more acceptable. There are several popular examples illustrating the evilness: plain text for general data representation (like configurations), and "typeless" programing language (like UNIX-shell) for general programing. They are really inconvenient.
Sparse is better than dense.
↑This is surely ignoring some general requirements. Not operational.
Readability counts.
↑Yes in general, but not in some rare scenes. If you are doing something only yourself, you can afford missing of readability, you think it's no good for that "neat" restriction, then it's okey to just throw it away. And do remember, thing other than readability also counts, can be also serious, or even more serious.

Special cases aren't special enough to break the rules.
↑Well, it's often reasonable, but the premise is the system of rules is properly designed. If the rules themselves are corrupted, game over.
Although practicality beats purity.
↑There is the same problem as "simple is better than complex", though seems less common.
Errors should never pass silently.
↑Right in theory, not always true practically. We do let errors we can't handle escape. And... what's the error, indeed?

Unless explicitly silenced.
↑Same problem as explicit vs. implicit.
In the face of ambiguity, refuse the temptation to guess.
↑Sometimes guessing is forced, e.g. using natural languages.
There should be one-- and preferably only one --obvious way to do it.
↑Also too ideal. That should be good if it can be really implemented it everywhere... but when?
And what about only one ugly method?

Although that way may not be obvious at first unless you're Dutch.
↑Okey, I'm not.
Now is better than never.
Although never is often better than *right* now.
↑Later but not now. It depends.

If the implementation is hard to explain, it's a bad idea.
↑Do mathematicians and theoretical physicists all fools?
If the implementation is easy to explain, it may be a good idea.
↑Although never is often better than *right* now. Think twice, why the "easy" explanation is needed, and what is the real purpose.
Namespaces are one honking great idea -- let's do more of those!
↑Seems the only statement I have no problem about it.

EOF