> 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.
> 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.)
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.
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.
> That's what you're trying hard to look like, unfortunately; if you're not, then stop.
I encourage you to take a deep breath and consider how you would like to treat people before you make future comments on the internet. Perhaps it's unwarranted optimism on my part, but I would guess you want to behave better than this.
I've responded in other comments to everything else you said in this post. You're not saying anything which hasn't been said more kindly by other people in this thread.
When I mention in a posting the topic of whether or not I'm an idiot and such, that's a signal to people that it's safe to debate that in whatever way they want. (I've been an idiot here and there, and may not be done. I could dig up objective evidence of that and expect people to agree.)
> I've responded in other comments to everything else you said in this post.
Maybe, but not to the message between the lines. Your position can be summarized as "everything is subjective and relative; my negative experience with a tool or technique speaks to the topic in a equally valuable way as do successful experiences by people making something reliable, tested, documented and maintainable by someone other than its author".
That strikes me as objectively untrue, and conductive toward coming to casually dismissive conclusions.
"Well, I think Rust is unproductive (at least for me) because I couldn't figure out the insane compiler messages. But some people who have never seen a type are struck by the novelty. That's okay, 'I like it' is perfectly valid. Everyone's experience is equal!"
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 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.
> 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.
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.
> we chose our goal to be achieving multi-master replication with Async consistency. We believe that this approach strikes the best balance of fault tolerance and transaction throughput.
