4 ms·

Disagree. There are abstractions and there are abstractions. Macros are too big of a footgun of an abstraction. Because they can change the syntax of the langu

Disagree. There are abstractions and there are abstractions. Macros are too big of a footgun of an abstraction. Because they can change the syntax of the language, they can hide functionality in non-obvious ways and they're just another band-aid on top of the languages limitations (the two latter points are especially true for C). And more often than not they're worse than just writing using the languages capabilities. Yes I'm sure people writing C macros will sit down and document them, and make them usable. Not. That being said, Rust macros are a world apart from C macros.

Hermitian909 5y ago
> another band-aid on top of the languages limitations Those limitations are real though, and getting in peoples way. I'd also add most language designers would not consider C macros as "real" macros. Think of abstractions as power tools, you want to use the least powerful one that solves the problem so you don't lose a hand. If you're cutting a string you pull out some scissors, if you're cutting a 10 foot thick steel rod, you grab some hydraulic shears; so it goes with abstractions. Most people never need macros, the abstraction equivalent of hydraulic shears, because most of the time your problem isn't that difficult. That doesn't mean those problems aren't out there or that macros shouldn't exist.
fouric 5y ago
There are macros, and there are macros. You've used C and Rust macros. Have you seen Common Lisp macros? I've read a fair amount of Common Lisp code written by other people, and every time I had difficulty understanding something, it was invariably plain CL, and not a macro. Maybe C programmers just have difficulty exercising restraint when writing their macros. Or perhaps the design of the language and the macro system (which is basically just text pre-processing) don't mesh well together. Regardless, I haven't noticed macros being a footgun in CL. Sure, there are doubtless people out there who have abused it (and will continue to do so) - but that's true for every language feature; meanwhile, it doesn't seem like macros themselves are actually a problem, in the sense that they're particularly easy to abuse compared to the rest of the language (a distinction that I might give to C raw pointers, for instance). If anything, (good - CL) macros are easier to understand than many other features, because they're (usually) referentially transparent functions with a clearly defined input and output that runs once at compile-time, on known data, which you can manually expand and inspect, and they tend to rarely interact with other features of the language. With rare (but useful) exceptions, macros don't involve networking, async, threads, dynamic environments, databases, stack limits, or any of the other strands in the spider-web complexity that tends to make programming hard.
- mike_hock 5y ago
  In other words, they're a completely different language feature than the one in C that happens to go by the same name.
  - deleted 5y ago
    [deleted]
  - germandiago 5y ago
    Lisp macros can get super obtuse, no matter what people tell me. When I have used Common Lisp, I try to avoid them most of the time.
    - fouric 5y ago
      I addressed this in my comment: > Regardless, I haven't noticed macros being a footgun in CL. Sure, there are doubtless people out there who have abused it (and will continue to do so) - but that's true for every language feature; meanwhile, it doesn't seem like macros themselves are actually a problem, in the sense that they're particularly easy to abuse compared to the rest of the language (a distinction that I might give to C raw pointers, for instance). Nobody contests that CL macros can get obtuse - but that's not special. You can write obtuse code in any Turing-complete language. Does that mean that we should abolish Turing-completeness? Of course not. How much Common Lisp have you read and written?
WalterBright 5y ago
At one point, I decided to unwind all my use of macros in C. I was actually very happy with the result. My code was much better.

Hermitian909 5y ago

> another band-aid on top of the languages limitations Those limitations are real though, and getting in peoples way. I'd also add most language designers would not consider C macros as "real" macros. Think of abstractions as power tools, you want to use the least powerful one that solves the problem so you don't lose a hand. If you're cutting a string you pull out some scissors, if you're cutting a 10 foot thick steel rod, you grab some hydraulic shears; so it goes with abstractions. Most people never need macros, the abstraction equivalent of hydraulic shears, because most of the time your problem isn't that difficult. That doesn't mean those problems aren't out there or that macros shouldn't exist.

fouric 5y ago

There are macros, and there are macros. You've used C and Rust macros. Have you seen Common Lisp macros? I've read a fair amount of Common Lisp code written by other people, and every time I had difficulty understanding something, it was invariably plain CL, and not a macro. Maybe C programmers just have difficulty exercising restraint when writing their macros. Or perhaps the design of the language and the macro system (which is basically just text pre-processing) don't mesh well together. Regardless, I haven't noticed macros being a footgun in CL. Sure, there are doubtless people out there who have abused it (and will continue to do so) - but that's true for every language feature; meanwhile, it doesn't seem like macros themselves are actually a problem, in the sense that they're particularly easy to abuse compared to the rest of the language (a distinction that I might give to C raw pointers, for instance). If anything, (good - CL) macros are easier to understand than many other features, because they're (usually) referentially transparent functions with a clearly defined input and output that runs once at compile-time, on known data, which you can manually expand and inspect, and they tend to rarely interact with other features of the language. With rare (but useful) exceptions, macros don't involve networking, async, threads, dynamic environments, databases, stack limits, or any of the other strands in the spider-web complexity that tends to make programming hard.

mike_hock 5y ago
In other words, they're a completely different language feature than the one in C that happens to go by the same name.
- deleted 5y ago
  [deleted]
- germandiago 5y ago
  Lisp macros can get super obtuse, no matter what people tell me. When I have used Common Lisp, I try to avoid them most of the time.
  - fouric 5y ago
    I addressed this in my comment: > Regardless, I haven't noticed macros being a footgun in CL. Sure, there are doubtless people out there who have abused it (and will continue to do so) - but that's true for every language feature; meanwhile, it doesn't seem like macros themselves are actually a problem, in the sense that they're particularly easy to abuse compared to the rest of the language (a distinction that I might give to C raw pointers, for instance). Nobody contests that CL macros can get obtuse - but that's not special. You can write obtuse code in any Turing-complete language. Does that mean that we should abolish Turing-completeness? Of course not. How much Common Lisp have you read and written?

WalterBright 5y ago

At one point, I decided to unwind all my use of macros in C. I was actually very happy with the result. My code was much better.