I guess the "problem" with understanding this perspective for us non-lisp people is that we may not be able to imagine all the places that we could have used macros (or something equivalent) if we haven't even learnt it. You don't know what you don't know, or in this case, you don't know how to use something you haven't used. But this seems to be the same for boatload of programming features that many people aren't taught with their first language, but rather later - higher order functions, lazy evaluation/generators/etc., type-level functions... we might at first think "this is a special tool only to be used in certain circumstances/only to be used by wizards". And then it might turn out that they are useful all the damn time.

The net result, at least for me, is that I get spoiled and then it is hard for me to go back 'more primitive ways'. :)

Macros are easy to understand if you are shown that whatever language you are using already has them. The difference is that they are locked in and wrapped behind at least two layers.

Firstly, there rigid surface syntax which customizes the look of every macro at the character level. For instance, in C, the do ... while(); loop must have a trailing semicolon. (No Lisp macro has such requirements.)

Secondly, that surface syntax translates to a limited set of abstract syntax tree forms which is not extensible.

Lisp macros open that up. The outer layer of varnish is stripped away, so any conceivable abstract syntax tree form has a notation; you do not have to invent new character-level surface syntax in order to work with a new form. And then, custom recognizers for arbitrary forms can be written by the language users, which do tree to tree transformations.

So then how you use these things once you have them is the same way that yu use the features of programming languages that you know.

E.g. loop is a macro in Lisp. We use it like this:

  [1]> (loop for x from 1 to 10
             for a = 2 then (* 2 a)
             collect (list x a)))
  ((1 2) (2 4) (3 8) (4 16) (5 32) (6 64)
   (7 128) (8 256) (9 512) (10 1024))

Someone wrote the loop macro, so in this situation I'm just a user. I don't care whether this is a macro, or built-in to the language like "foreach x in list do".

When I use loop, I'm benefiting from macro-writing.

The benefits are far-reaching. For instance, language experimentation takes place in the user base, not behind the closed doors of an ivory tower (ISO committee or whatever). Language ideas are packaged as code and shared around.

Technical problems turn into social problems, as someone noted.

This doesn't really address the issue of readability or understanding though. You still have to go through someone else's uncommented code and figure out what their weirdo macros actually do versus having standard, documented language features that you already understand.

Because there's not a ton of standardization (and for other reasons) you end up with a million different dialects of lisp and a fragmented community, in comparison to other language families.

And you can do open, community-driven standardization and language enhancement. Python is a decent example of this.

If someone writes "weirdo macros" and you take them away, that same someone will write weirdo code using something other than macros. Either way, you will have to understand what they are doing. In the worst case, that person will expand, by hand, the code their macros would have written. Now you can't fix a bug in the expander and cheaply re-expand.