Je pense que le «papier» est en fait la présentation des modèles de conception dans les langages dynamiques , également citée dans Wikipedia pour cette affirmation particulière:
Les modèles de conception peuvent simplement être un signe de certaines fonctionnalités manquantes d'un langage de programmation donné (Java ou C ++ par exemple). Peter Norvig démontre que 16 des 23 modèles du livre Design Patterns (qui est principalement axé sur C ++) sont simplifiés ou éliminés (via un support de langage direct) en Lisp ou Dylan.
De la même manière, Paul Graham décrit les modèles de conception comme "le compilateur humain au travail" dans Revenge of the Nerds :
Cette pratique est non seulement courante, mais institutionnalisée. Par exemple, dans le monde OO, vous entendez beaucoup parler de "modèles". Je me demande si ces modèles ne sont pas parfois la preuve du cas (c), le compilateur humain, au travail. Quand je vois des modèles dans mes programmes, je considère que c'est un signe de problème. La forme d'un programme ne devrait refléter que le problème qu'il doit résoudre. Toute autre régularité dans le code est un signe, pour moi au moins, que j'utilise des abstractions qui ne sont pas assez puissantes - souvent que je génère à la main les extensions d'une macro que je dois écrire.
Les deux citations sont à la base de la discussion sur les modèles de conception manquant de fonctionnalités linguistiques sur le wiki de Ward.
