|
|
|
|
|
by chc
5671 days ago
|
|
Design patterns are essentially code that you have to repeat because the language is incapable of generically representing the process that the pattern codifies. For example, I believe pg once observed that most of the classical design patterns didn't exist in any recognizable form in Common Lisp because their functionality could be factored out into higher order functions and macros. Ah, I found it. It was in his Revenge of the Nerds essay, and he was actually citing Norvig, though he goes into more detail than just that. http://www.paulgraham.com/icad.html Also, Coding Horror on the topic: http://www.codinghorror.com/blog/2005/06/are-design-patterns... |
|
In the specific case of the twenty canonical design patterns from the GoF book, some are rendered trivial by better languages, but the principle of a design pattern remains valid. I'm confident that Lisp has design patterns, I own a book full of them:
http://www.amazon.com/LISP-Advanced-Techniques-Common/dp/013...
A design pattern in the abstract is a systemized form of folklore. Problem Statement, Forces Acting on the Solution, Template for Implementing the Solution. Until we have a language where every problem to be solved can be done so with a single atomic element of the language, there will be design patterns that programmers use to share their experience.
Now that we have established that we can choose several different colours for the bike shed, I will say that if you gave me that answer in an interview, I wouldn't hold it against you in any way. It demonstrates intelligence and experience. I imagine that if we were talking face to face we could have an interesting conversation about languages and abstractions and templates and problems and communicating folklore.
So my meta-observation is that the important thing about a question is whether it helps provoke an interesting and useful conversation, not whether the person parrots out some answer you are seeking.
JM2C.