## Design Patterns Criticism Inappropriate use of patterns may unnecessarily increase complexity. It has been observed that design patterns may just be a sign that some features are missing in a given programming language. Peter Norvig demonstrates that 16 out of the 23 patterns in the _Design Patterns_ book (which is primarily focused on C++) are simplified or eliminated (via direct language support) in Lisp or Dylan.  Related observations were made by Hannemann and Kiczales, who implemented several of the 23 design patterns using an aspect-oriented programming language (AspectJ) and showed that code-level dependencies were removed from the implementations of 17 of the 23 design patterns and that aspect-oriented programming could simplify the implementations of design patterns. A primary criticism of _GoF Design Patterns_ is that its patterns are simply workarounds for missing features in C++, replacing elegant abstract features with lengthy concrete patterns, essentially becoming a "human compiler." Paul Graham wrote: > When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough—often that I'm generating by hand the expansions of some macro that I need to write.