Why patterns are evil

An astounding fact for you: design patterns have been popular since at least 1994.  This is possibly the weirdest thing in all of programming.  Because even if not all programmers have taken a course in information theory, they should have a good working knowledge of it, given that their daily job revolves around it.  And thus they should intuitively understand what a waste patterns are.  Patterns can be described in a more concise form, and automatically generated/expanded from that.  (This is pretty much their definition.)  A good analogy is using higher-level languages vs. assembly.

Every programmer knows that generally it is a mistake to write in assembly.  The reason is that many things both required for general programming, and trivial in higher languages, e.g. if-then-else, loops, objects, etc., can only be expressed in a repetitive manner in assembly.  And as the usual wisdom of structured programming goes: more code, more bugs.  When some structure has to be expressed in more code than necessary, there are more opportunities to make a mistake.  More importantly, when a program has to be modified (software), some copies might be overlooked.  Also, a low-level description has to be unraveled first before it can be adjusted.

This rule extends beyond assembly and goto.  When a human programmer writes repetitive code, following some template or motif, they are doing the compiler's job.  They should not embrace drudgery, cataloging patterns; they should be looking for a more compact description.  Sometimes, such a shorter formulation requires features missing from the language.  Even if they don't consciously understand this, many programmers try to fix the problem.  This is called Greenspun's tenth rule.