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

[martinflack]

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

Which is why pg advocates symbol count. (Although he seems to love brevity too.)

[codr7]

I urge you to try that theory on the expansion linked in my comment and see where it takes you compared to the macro code.

No, but it's the most effective one.

[kerkeslager]

> No, but it's the most effective one.

That's a perfectly valid opinion which is probably based on your experience, just as my opinion that macros aren't a good tradeoff is based on my experience.

I understand the initial joy of macros, and I'm well aware they're powerful for generating code. But in my experience, they are also not well encapsulated, and as a result, areas of code which use macros tend towards being write-only, where the code becomes hard to read and you're afraid to make changes lest the fragile pile of expansions you've created comes crashing down. In the short run, they seem great, but in the long run, the errors they create don't seem worth it.

I don't know why I've experienced this and you haven't, but I'm sure you have some different experience with macros that leads you to have a different feeling on macros than I do. If you disagree with me, I'd appreciate it if you approached that disagreement without making without assuming I'm an idiot with no experience, and without making arguments like "fewer characters = better" which even you don't believe.

[codr7]

You're right, I do think macros make a good tradeoff. And you're not alone in thinking otherwise, I remember attending a heated panel debate at the International Common Lisp Conference about the pros and cons of macros.

In my case it's based on 20-ish years of using Common Lisp for personal projects.

Admittedly mostly prototyping and figuring things out, but that's my main use case for CL since using it at work is mostly politically impossible.

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

[kerkeslager]

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

No, I meant languages (as in programming languages), not programs.

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

I'm already convinced macros are powerful. The problem is that they're also extremely error prone, and can be extremely difficult to debug when errors inevitably occur.

This isn't controversial. Land Of Lisp[1] has a section titled "Macros: Dangers and Alternatives". The elisp docs[2] contain a section on "Common Problems Using Macros". Paul Graham's On Lisp[3] contains a chapter on variable capture which consists mostly of sections on avoiding variable capture problems, followed by a chapter called Other Macro Pitfalls.

These are the people who like Lisp writing these things. The controversial thing I'm saying is that I don't think the power/danger tradeoff is worth it. That's pretty subjective and it's reasonable to disagree with that, but you can't reasonably disagree that macros are error prone when even the people writing Lisp variants are saying they are error-prone.

The best HTML generation I've experienced is with Ruby templates. They're not as terse as Lisp macros, but I don't end up having to debug them very often, and when I do end up debugging them, the bugs are usually trivial to find and fix.

> Autogeneration can be done with macros and is simpler with macros.

I have never spent hours debugging an IDE autocomplete. I have spent many hours debugging macros.

You're only looking at the positives of macros and ignoring everything I've said about the negatives.

[1] https://www.oreilly.com/library/view/land-of-lisp/9781593272...

[2] https://www.gnu.org/software/emacs/manual/html_node/elisp/Pr...

[3] https://redirect.cs.umbc.edu/courses/331/fall10/resources/li...

[foodoos]

Thanks for sharing your experience with Ruby templates and for the links.

> I don't think the power/danger tradeoff is worth it.

The power/danger tradeoff might not be worth it for the overwhelming majority of programs. For some kinds of programs I don't see how this power can be got with anything less powerful than macros.