upvote
That is badly generalized proverb. Clojure has unhygienic macros, no expander extension points, and no error-message layer, so "don't" is a rational default there. Yet, for example Racket writes macros that write macros as a matter of course. And that's because the language has the infrastructure: hygiene by default, phase separation, `syntax-parse` with grammar-quality error messages, a module system that actually knows about compile-time dependencies.

But even with some limitations, there are cases in Clojure where macros do achieve things otherwise unattainable. One practical example is multi-host code generation. You can have a Clojurescript macro that parses and analyzes some javascript lib, doing that on JVM side, while emmiting code generated to run in Javascript. Hyperfiddle/Electric is the best example of that kind of macro ingenuity.

Or take core.async's `go`. It takes an arbitrary body, analyzes it into an AST, and rewrites it into a state machine so that <! and >! can park and resume. On the JVM it lets you avoid blocking threads. In Clojurescript it is the only way to have the model at all, because JS has no threads to block.

Nothing about that is expressible as a function. The transformation needs the entire body as data. Same family: core.match compiles a pattern matrix into a decision tree. And there are many more example use cases for macros.

"Don't write macros" rule has the second part: "unless you truly have no choice."

reply
Author here. I think in general this is sound advice, but in Emacs it is an incredibly convenient utility. I use them all the time. Mostly simple things like wrapping function definitions, or even other macros that wrap function definitions. Most of my lisp experience is in Emacs where the config layer is essentially exposed through an elisp API. In that context, I find myself using macros a lot. But if I was building some software from scratch, like say a data processing system, I can't immediately think of scenarios where I would define macros.

Worth mentioning in Elisp that even if you don't define your own macros, you use them more often than you would think. defun, unless, def-custom, etc (more examples in the blog post) are all macros. The fact they look and feel like non-macros like special forms and built in functions implemented in C is part of what makes elisp so cool to me. There are plenty of homoiconic languages, but you rarely feel the distinction between program and data in elisp, and macro-supporting lisps in general.

reply
If you look at the definition of a macro like defcustom, you'll see that it just expands to a function call, where all the logic is implemented. This could also be implemented in the macro, but that is more complicated and brittle, due to the risk of double-evaluations and having to produce code that will (usually) later evaluate with the intended side effect.

Furthermore, macros and functions constitute a kind of function coloring. To use a macro in a function, like defcustom, you couldn't pass the name of the user option you are defining in as a symbol, as that is not evaluated. So instead you'd have to call eval on a runtime constructed expression, which is a cludge.

So I agree with the top comment, to avoid macros is a sign of Lisp maturity. It is easy and fun to admire them when you are coming from languages with arbitrary restrictions in their macro systems like C, but ones you get used to them you don't treat them with any more wonder than any other arbitrary restriction that a language may lack (bad ad hoc example: nobody praises C for the lack of a CALL keyword).

reply
Meh, that seems to be a bit of a clojure thing. In the Racket world, with hygienic macros and phase separation, they'll routinely write macros returning macros, etc.
reply
Why?
reply