5 ms·

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

> 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 3y ago
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/ff3a34a31ced7a9668fc952d8040ddb13cad17be/test.lisp#L7 https://github.com/codr7/cl-redb/blob/ff3a34a31ced7a9668fc95... [1] https://gist.github.com/codr7/4bb9442c0c66411643eddd8db0164a2d https://gist.github.com/codr7/4bb9442c0c66411643eddd8db0164a...
- kerkeslager 3y ago
  > 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 3y ago
    > 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 3y ago
    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 3y ago
      > 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.
      - kazinator 3y ago
        [flagged]
        kerkeslager 3y ago
        > > assuming I'm an idiot with no experience > 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.
kerkeslager 3y ago
> 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 3y ago
  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 3y ago
    > 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/9781593272814/ch18s03.html https://www.oreilly.com/library/view/land-of-lisp/9781593272... [2] https://www.gnu.org/software/emacs/manual/html_node/elisp/Problems-with-Macros.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Pr... [3] https://redirect.cs.umbc.edu/courses/331/fall10/resources/lisp/onLisp/ https://redirect.cs.umbc.edu/courses/331/fall10/resources/li...

codr7 3y ago

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/ff3a34a31ced7a9668fc952d8040ddb13cad17be/test.lisp#L7 https://github.com/codr7/cl-redb/blob/ff3a34a31ced7a9668fc95... [1] https://gist.github.com/codr7/4bb9442c0c66411643eddd8db0164a2d https://gist.github.com/codr7/4bb9442c0c66411643eddd8db0164a...

kerkeslager 3y ago
> 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 3y ago
  > 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 3y ago
  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 3y ago
    > 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.
    - kazinator 3y ago
      [flagged]
      - kerkeslager 3y ago
        > > assuming I'm an idiot with no experience > 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.

kerkeslager 3y ago

> 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 3y ago
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 3y ago
  > 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/9781593272814/ch18s03.html https://www.oreilly.com/library/view/land-of-lisp/9781593272... [2] https://www.gnu.org/software/emacs/manual/html_node/elisp/Problems-with-Macros.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Pr... [3] https://redirect.cs.umbc.edu/courses/331/fall10/resources/lisp/onLisp/ https://redirect.cs.umbc.edu/courses/331/fall10/resources/li...