Creo que el "artículo" es en realidad la presentación de Patrones de diseño en lenguajes dinámicos , también citada en Wikipedia para esta afirmación particular:
Los patrones de diseño pueden ser solo un signo de algunas características faltantes de un lenguaje de programación dado (Java o C ++, por ejemplo). Peter Norvig demuestra que 16 de los 23 patrones en el libro Design Patterns (que se centra principalmente en C ++) se simplifican o eliminan (a través del soporte directo del lenguaje) en Lisp o Dylan.
De manera similar, Paul Graham describe los patrones de diseño como "el compilador humano en el trabajo" en La venganza de los nerds :
Esta práctica no solo es común, sino institucionalizada. Por ejemplo, en el mundo OO se escuchan muchas cosas sobre "patrones". Me pregunto si estos patrones no son a veces evidencia del caso (c), el compilador humano, en el trabajo. Cuando veo patrones en mis programas, lo considero un signo de problemas. La forma de un programa debe reflejar solo el problema que necesita resolver. Cualquier otra regularidad en el código es una señal, al menos para mí, de que estoy usando abstracciones que no son lo suficientemente potentes, a menudo que estoy generando a mano las expansiones de alguna macro que necesito escribir.
Ambas citas son la base de la discusión de Are Design Patterns Missing Language Features en Ward's Wiki.
