Macros are bad, but in order to understand why they are bad it helps if you are not a language nut. Most language nuts have one shortcoming: they do not understand their consumer.<p>If you want proof you only need to look at the error messages generated by most compilers. They probably make perfect sense to someone who is trying to debug the compiler, but they usually leave the consumer, ie the programmer using the compiler, somewhat confused.<p>Macros are bad because they redefine the language. The point of having a language in the first place is to make it easy to communicate. This is only possible if the semantics are understood. If you do good language design the semantics are clear. If you do sloppy language design people have to look things up all the time.<p>Now, if everyone gets to extend the language in arbitrary ways, you have suddenly unloaded a massive burden onto your programmers. It is no longer enough to say that you know language X. In order to understand the software you have to understand the specific dialects (plural) of language X -- because for a non-trivial project with lots of people extending the language in various ways, you will end up with multiple dialects.<p>When you can no longer bring up a piece of code in your editor and see what it does without having to reference dozens of other files that may modify the semantics of the language (sometimes in non-obvious ways), you are going to be a lot less productive.<p>I think Joshua Bloch was absolutely right when he said that one of the really good decisions of Java was to NOT have macros. He made some of the same points I made above.<p>Now I understand that people think macros can lead to elegant code, but that code <i>only</i> has value if other people can understand it. If you need to re-learn the language, in big or small ways, to understand it, its value is very limited.<p>And again: what excites language nuts and what has real value is not always the same thing.