>>12These "although dynamic and/or functional languages" are not zero-cost - C macros are the lowest overhead that can exist.
The barrier to understanding esoteric macros is not that high, and once you grasp how it works(its basically merging symbols with ## plus __VA_ARGS__ expansion rules) you can decode anything you see.
The problem appears when you use deeply nested macros(only recently gcc has improved their debug display for nested macros) interacting with each other:
since they are not code GCC is unable to show what it sees as wrong macro expansion - it shows where it fails to compile the results of the macro(it does show the macros in descending order, but you already know what produces the code) since C text macros are purely symbolic transmutation of tokens.
it's just more intuitive when you have things like lambda
Does it occur to you that any function macro is a lambda inlined on the spot? Macros don't have any syntax restrictions of a lambdas, and can be passed to other macros as tokens:
foreach_macro(array,lambda_macro) expands to for() loop with lambda_macro being its inner content
I know C preprocessor is really primitive at what it does, but its not unintuitive: its simple, fast and doesn't burden the resulting code with abstraction layers.