> 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.
For me, patterns define ways how you put language constructs units together to solve typical "higher-level" problems. For example, "how do I implement an undo mechanism". Of course for static/object-oriented languages, the patterns will be different than for dynamic languages.
I am currently listening to the Software-Engineer Radio Podcast from 2006/2007, and they talk heavily about patterns. Even though the POSA books patterns may not be applicable to dynamic languages like Ruby or JavaScript, I think the right idea is to define new patterns that are useful for these type of languages.
Maybe one reason why we don't have this is because nowadays to solve a more "specific" problem the only thing you need to do is to install some third party library from github that already does it? (like if I wanted to implement an undo-redo fucntionality I will use maybe this: https://www.npmjs.com/package/undo-redo )
> 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.