2 ms·
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 w
by brabel 3y ago
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.
- lmm 3y ago> 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.
- HelloNurse 3y agoThe 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).