[foodoos]

> the power of Lisp macros isn't actually ever worth the responsibility in my experience

Expand your experience.

> At the very least, you can just write the code the macro would expand into.

You can "just" get it wrong when the code is used in many places.

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.

[codr7]

More importantly, they reduce the number of characters you have to read and maintain.

Macros allow writing code that's both compact and readable [0], in lesser languages you have to choose.

[0] https://github.com/codr7/cl-redb/blob/ff3a34a31ced7a9668fc95...

[1] https://gist.github.com/codr7/4bb9442c0c66411643eddd8db0164a...

[kerkeslager]

> More importantly, they reduce the number of characters you have to read and maintain.

So does giving all your variable names one-letter names and putting your entire codebase on one line. Surely we can agree that character count is a poor measure of readability or maintainability.

> Macros allow writing code that's both compact and readable [0], in lesser languages you have to choose.

Macros aren't the only abstraction that does that, even within Lisp.

[kerkeslager]

> 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.

[foodoos]

I appreciate and I'm impressed you're gratuitously positive.

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.