About macros: the author did argue why it's bad. It was actually the final point leading to the conclusion:
salience bias: measuring what is seen and not what is unseen.
And he did not say all macros are bad, giving the example of Common Lisp macros being good. Why? Because you can easily expand them (the language itself gives you the capability, not just an IDE... but of course with SLIME it's one shortcut away) and see the actual code you will get running.
> And he did not say all macros are bad, giving the example of Common Lisp macros being good. Why? Because you can easily expand them (the language itself gives you the capability, not just an IDE... but of course with SLIME it's one shortcut away) and see the actual code you will get running.
That seems pretty unconvincing. If it's important for macros, why isn't it important for regular code? And yet taking a Haskell function and dropping down to the corresponding Core is no easier than expanding a Rust or OCaml macro.
The salience bias can be seen the opposite way: your code base consists of understandable metaprogramming based on principled tools, and the corresponding write-only generated code is unseen.
The OP might have been bitten by bad macros and bad code generation (early and repeatedly).
