pg is a well-known advocate of macros, and I suppose he influenced a lot of people in this opinion. I do like macros, but it's true, too many times you're doing it wrong if you're defining a macro.
Richard Gabriel (author of Worse is better, Lucid founder, etc.: in short: Lisp expert) said:
"Macros encourage people who are not good at
language design to do something equivalent to language design,
using tools that don't help, and with effects that are too
powerful. This makes code unreadable to people joining later and
for the authors after time has passed. Well designed macros are
well documented, but this doesn't happen much."
He makes some interesting points, but macros are like everything else that's useful (fire, nuclear power ...), they can be abused. It's fair to warn people about macros, just as people are warned repeatedly about multi-threading; but it doesn't mean macros, or multi-threading, are wrong or bad. Having a few years of practicing "Don't Repeat Yourself" in java, perhaps, you have finally hit the limit, and realise that removing more duplication means a net increase in volume of code. Arc and assembly are the only non-condescending languages I know, and I love the freedom of writing unfettered code in arc.
I notice that arc's macros are mostly very short and to the point, and are strictly hygienic even though the core language doesn't impose it. As for me, I'm still learning this discipline, just as it took me a while to understand why short methods and small classes are "better".
Interesting. I suspect I overuse macros; I try consciously to improve by constraining the surface area of the program that lies under defmacro, but there's a long way to go.
One pattern: I often used to use defmacro just to get call-by-reference. Most of the time I can get by with just primitives.
