I think the "paper" is actually the Design Patterns in Dynamic Languages presentation, also cited in Wikipedia for this particular claim:
The design patterns may just be a sign of some missing features of a given programming language (Java or C++ for instance). 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.
In similar manner, Paul Graham describes design patterns as "the human compiler at work" in Revenge of the Nerds:
This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. 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.
Both quotes are the basis of the Are Design Patterns Missing Language Features discussion on Ward's Wiki.