I have written non-trivial programs in C, C++, Java, Javascript, ActionScript, PHP, Python, Haskell, Scheme, Go, and Sawzall, and also played around with prototypes or toy-quality programs in Common Lisp, Ocaml, Dylan, Erlang, Ruby, and Perl. I've written compilers, templating languages, desktop GUIs, web GUIs, mobile GUIs, parsers, machine-learning based data extractors, and distributed systems. I also lead a team, and I'm trying my hardest to bring a large, heavily used product into the modern era when it comes to web technologies. I was a huge fan of macros in college and the few years immediately afterwards. I've now done almost a complete 180 on them, and would encourage anyone I work with not to use them.
The reason is because I've come to understand that social factors trump technical factors nearly every time. The hardest part of writing a software system is almost never solving engineering challenges or writing code, it's communicating the solution to everyone who will have to touch it. Over a software system's lifetime, you will have to read code much more often than you will have to write code. Macros make writing code really easy and communicating everything about what it does, how it does it, and what invariants need to hold for it really hard. That's usually a poor trade-off for anything non-trivial.
I've found that working with a DSL structured around the problem domain improves communication and readability. Macros are a tool to allow you to easily implement these DSLs and have them fit nicely into the host language.
I actually like DSLs, but I think the right level of abstraction to develop them is by exposing the tokenizer, parser, AST, typesystem, semantic analyzer, and execution engine of the language as libraries in the language itself. Things like 'ast' and 'parser' in Python, package 'go' in Go, Clang for C++, etc. I've tried to fill this gap for HTML5 with Gumbo - it was initially designed to support a semantically-aware templating language in Google.
The reason I think DSLs are good but macros are bad is because DSLs make you think long and hard about the costs of implementing a new language. You have to pay for it up-front by writing a compiler and hooking it into your build system, even if you have help from the host language's libraries, and then you'll end up with something that's clearly a separate language and must be documented and learned separately. That cost makes it clear that creating a DSL is not something to do lightly, and you need a problem domain where there really are much higher-level abstractions that can't be captured by an existing programming language.
The problem with macros is that you can create a new language construct with a half dozen or so lines of code, use it in a few hundred places in the codebase, and now your maintainers have a few hundred problems.
But many DSLs can be implemented just as well without the use of macros.
This does not refute your point at all -- that macros can be very helpful when implementing DSLs -- just wanted to point out that macros are not a requirement for doing so.
Also, a DSL expressed using first-class entities will fit into and integrate with its host language more nicely.
While I completely agree with the second part of your comment, you didn't had to throw us your knowledge, skills and experience, it's anecdotal evidence and it weakened your point which was already strong enough.
I disagree completely, it's good to know from what position someone is arguing. And it's also interesting to see that someone with similar experience to mine came at completely different conclusion. So thanks nostrademons for the comment. While I disagree with most of what he wrote (I agree only with social factors trumping technical ones)it was still relevant as a whole.
Well, I think potentially made up (and practically uncheckable) experience and credentials don't make up for a trustworthy position, therefore they are completely unnecessary on a pseudonymous internet forum.
The reason is because I've come to understand that social factors trump technical factors nearly every time. The hardest part of writing a software system is almost never solving engineering challenges or writing code, it's communicating the solution to everyone who will have to touch it. Over a software system's lifetime, you will have to read code much more often than you will have to write code. Macros make writing code really easy and communicating everything about what it does, how it does it, and what invariants need to hold for it really hard. That's usually a poor trade-off for anything non-trivial.