Macros are good, but in order to understand why there are good you have to lift your head out of the common mindset of most developers that spend half their day

Macros are good, but in order to understand why there are good you have to lift your head out of the common mindset of most developers that spend half their days configuring their application in some poorly designed XML-based DSL that's only necessary because doing the same thing in their programming language is too awkward. They coincidentally spend the other half of their days writing code in the same basic procedural style they learned as a kid, copying and pasting bits of code everywhere and making a general highly-coupled mess because they don't how to do it any better. It has been said that at any given point, every project implements their own programming language, usually as some kind of DSL, and they do it really really badly. I've seen this borne out in practice in EVERY commercial project I've worked on. I've seen it, I've lived, and I continue to live it every day. Macros are one of the ways out of this mess that we've created for ourselves. While a lot of macro research is still cutting edge, slowly different techniques are becoming more proven and starting to disseminate more and more into mainstream languages and runtimes. The problems you mention with macros have honestly already been dealt with in the past decade or two. I've dealt with people like you at work before. Your kind are those that stare at any abstraction they don't understand with immediate suspicion and reject it without any real consideration. They refuse to learn new things or improve their programming abilities or toolset. While this in of itself isn't a crime, they hold the rest of the industry back by rejecting superior technologies as they come along because they refuse to take the time understand them. Your kind and mine, sir, are in direct opposition.