Hmm... I'm not really a macro kind of person - generally speaking I'll just shove everything into a function - but I have no issues with them.
With that said, Crystal has only a few basic functions, and most other "functions" in the language are macros of those basic functions, which makes understanding what those functions actually do a whole lot easier and somewhat self-documenting, and I think that's really cool.
Just like almost everything in life, this type of stuff can be nice when used properly and only when appropriate, and otherwise can quickly be a recipe for disaster. Macros are one of those 'implicit' programming concepts, the stuff that you just can't notice by simply reading code, and I've been bit enough times by all kinds of implicit programming that I started actively avoiding that.
If your macro has some way to let developers notice that it is a macro just by reading the code where it is used, like how you will always notice a Python decorator or a C# attribute, then that's fine as long as the name of macro gives away [...]
Depends on language.
In C, macros can extend the language. These are good to implement some kind of small systems, that do not interfere with each other, would it be Linux drivers or QEMU devices. Implementing any kind of generic (de-)serialization is just better with macros.
In C++? Well... meh... Only when other ways just do not work, depending on target standard.
Well, I really miss them in Java for example. Java isn't the type of language that allows you to write small programs. It also isn't the type of language that prefer different flavors. For example I had problems with Android version of Xash, one that should be [...]
I'm not really a programmer anymore, I primarily read code nowadays. So to me, I prefer to not see macros since it adds difficulty when reading. But I just see my job like how a mechanic sees theirs, I just take whatever rolls into the shop and deal with it. The result is that I'm rather ambivalent on many programming preferences.