Design Patterns is about typing out boilerplate code by hand to solve a problem, because the language doesn't have the expressivity to encode the same solution directly.
When it does have the expressivity, the underlying rendering of the pattern hasn't gone away; just the manual boiler-plate for producing it.
For instance, if you're working in assembly language, then you might sometimes benefit from a "while loop design pattern" to keep your code clean. The while loop design pattern calls for some test code before a block which jumps past the block when the test is negative, and an unconditional backward branch at the end of the block back to that test expression.
The while loop doesn't go away when you use a higher level language. You just indicate that you would like that pattern, and the compiler spits it out for you, invisibly.
> Every time you pass a lambda to a higher order function you're using a strategy pattern.
Every time you pass a "naked" lambda somewhere, you're potentially missing the opportunity to have a macro there do that for you.
> Every time you pass a "naked" lambda somewhere, you're potentially missing the opportunity to have a macro there do that for you.
True but equally sad that you must use Lisp to hide ugly Lisp because naked lambda's are so ugly. Yet the point remains, whether hidden behind a macro or not, design patterns still exist in Lisp and every other language and always will.
Lambdas aren't "ugly"; they are sometimes just a mechanism that is not directly relevant to the problem domain: the "how" part of the solution, rather than "what".
The point isn't to hide the lambdas, but to hide the "how", which might or might not use lambdas.
The "how" could instead open-code the procedure that would have otherwise called the lambdas; then the material just becomes embedded forms in the inline code.
Lets not kid ourselves, hiding lambda's is one of the primary uses of macros in Lisp (obviously not the only). Yes, you're hiding the "how", we don't disagree there, but my point was that such syntactic abstraction is only necessary in Lisp because it's so ugly to directly use lambda. Compare to Smalltalk which uses naked lambda's everywhere because they're nice looking as is and don't need to be hidden away by special forms in order to feel idiomatic.
> Lets not kid ourselves, hiding lambda's is one of the primary uses of macros in Lisp (obviously not the only). Yes, you're hiding the "how", we don't disagree there, but my point was that such syntactic abstraction is only necessary in Lisp because it's so ugly to directly use lambda. Compare to Smalltalk which uses naked lambda's everywhere because they're nice looking as is and don't need to be hidden away by special forms in order to feel idiomatic.
Hiding lambdas with macros isn't really that common in my experience. The "how" being hidden is much more often (ultimately) IF, LET, BLOCK, and GO. Of course, higher order functions could often be used instead, but they're generally not.
When it does have the expressivity, the underlying rendering of the pattern hasn't gone away; just the manual boiler-plate for producing it.
For instance, if you're working in assembly language, then you might sometimes benefit from a "while loop design pattern" to keep your code clean. The while loop design pattern calls for some test code before a block which jumps past the block when the test is negative, and an unconditional backward branch at the end of the block back to that test expression.
The while loop doesn't go away when you use a higher level language. You just indicate that you would like that pattern, and the compiler spits it out for you, invisibly.
> Every time you pass a lambda to a higher order function you're using a strategy pattern.
Every time you pass a "naked" lambda somewhere, you're potentially missing the opportunity to have a macro there do that for you.