| > Expand your experience. That's universally good advice, which you should follow too. But neither of us is going to experience all that exists to experience, so it makes sense to prioritize. I've experienced enough pain debugging Lisp macros to make an educated decision to deprioritize further exploration in that area. > You can "just" get it wrong when the code is used in many places. True, which is why I generally use other abstractions to avoid repeating myself. > Consider this as the hot take: macros reduce the number of characters you have to type. I haven't seen anything that beats macros in this metric. Sure, but within reasonable languages that's not a metric which matters. Typing has never been the bottleneck of my development. Even in absurdly verbose languages like C++, IDEs generate a lot of the code for you: the bottlenecks in C++ are things like stitching together different ways of doing the same thing which were used in libraries or different parts of the codebase. |
I think you mean within reasonable programs that's not a metric that matters because most programs solve problems that don't need much autogeneration to be solved. For problems that do need autogeneration macros are one of the strongest ways.
A good way to become convinced of the power of macros is to try and write a web app in Arc to generate lots of HTML.
IDEs that generate a lot of the code are proof macros are needed because when you want to change the autogenerated code you have to do it by hand. Autogeneration can be done with macros and is simpler with macros.