Well, keep in mind that "macros" in Lisp are really compile-time computing. In Lisp you have the same language at your disposal at runtime and at compile time.

Well, keep in mind that "macros" in Lisp are really compile-time computing. In Lisp you have the same language at your disposal at runtime and at compile time. In C/C++ you have the preprocessor, which is a really lousy language. And in C++ templates. Remember the "template metaprogramming" hype about 10 years ago? How far did they go? Compute some prime numbers? I mean C++ templates are a compile-time language, but they are a language that has only one type - types and no real iterations over collection types. Wait, they have no collection types. The one and only type is types. So, "macros" in Lisp are really a new capability, and they can make code very dense. But think about the alternative - rolling out all this code with generating it at compile time from a single point of origin. That is the real maintenance nightmare. Every time you make an assumption during programming you want to contain that assumption in a single place. So that when the assumption changes later (otherwise known as "always" when other people are involved in telling you what the program is supposed to do in the end) you change a single place, and the rest of the dependent code is generated at compile time - using the full programming language you chose. I started a web series on compile-time computing. Didn't get as far as I wished for now, but here is some: https://medium.com/@MartinCracauer/a-gentle-introduction-to-compile-time-computing-part-1-d4d96099cea0 https://medium.com/@MartinCracauer/a-gentle-introduction-to-... I actually plan to use some of the chemical code I write (for the above mentioned Cando/Clasp chemical package) to make more parts of that series.