5 ms·

> The macros inevitably become so confusing, pervasive and complex that the author winds up inventing his own undocumented mess of a language, unusable for anyo

> The macros inevitably become so confusing, pervasive and complex that the author winds up inventing his own undocumented mess of a language, unusable for anyone else. This is not limited to macros, but any abstraction. Let's step back and rewrite the quote: > The abstractions inevitably become so confusing, pervasive and complex that the author winds up inventing his own undocumented mess of a language, unusable for anyone else. The key fault that trips up so many talented programmers (if not all) at least some point during their career (and hopefully not continuously, though I certainly know a few cases) is confusing convenience with simple. Convenience is almost always more complex, not simpler. Macros happen to wear their complex hearts on their sleeves. You can address any of these problems by _addressing the problems_ you succinctly listed: documentation and usability. Take React for example. It's an abstraction, arguably a new "language", and requires ample documentation and usability concessions to be palatable. You could accomplish this with macros as well. But like any abstraction, the real problems arise during maintenance, and thus it becomes a Software Engineering problem -- whatever that means. This is where Software Engineering as a poorly-defined pseudo-profession has failed to demarcate itself from simple programming: the quality, maintenance and longevity of living code bases. The masses unfortunately still don't see the forest for the trees, so I agree that it's something we've never seemed to learn, if perhaps using a broader definition.

sp33der89 5y ago
So I'm not a fan of metaprogramming or heavy abuse of tricks for convenience either, and I do get and agree with your point! But for some anecdotal nuance concerning the React example: > Take React for example. It's an abstraction, arguably a new "language", and requires ample documentation and usability concessions to be palatable. You could accomplish this with macros as well. I feel like the standard before React was just every (web) framework inventing its own templating language, whereas I found React to be really easy to learn, because the way it abstracted things were straightforward and well explained. It's tooling however is one of the scariest things I've ever seen haha.
- klodolph 5y ago
  I recently wrote a React app without using the “create-react-app” tool… just by writing JavaScript code, later TypeScript, and bundling it with Rollup.js. Doing things this way shows you that the tooling doesn’t have to be complicated. I assume that there are very good reasons why the tooling is complicated—stuff like code splitting, modular CSS, etc. If you’re writing pure JS React and putting the CSS elsewhere, you can squeak by with fairly simple tools.
raverbashing 5y ago
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.
random314 5y ago
> This is not limited to macros, but any abstraction. Disagree here. Unix process, file access api's, programming languages are all abstractions that make life easier.

sp33der89 5y ago

So I'm not a fan of metaprogramming or heavy abuse of tricks for convenience either, and I do get and agree with your point! But for some anecdotal nuance concerning the React example: > Take React for example. It's an abstraction, arguably a new "language", and requires ample documentation and usability concessions to be palatable. You could accomplish this with macros as well. I feel like the standard before React was just every (web) framework inventing its own templating language, whereas I found React to be really easy to learn, because the way it abstracted things were straightforward and well explained. It's tooling however is one of the scariest things I've ever seen haha.

klodolph 5y ago
I recently wrote a React app without using the “create-react-app” tool… just by writing JavaScript code, later TypeScript, and bundling it with Rollup.js. Doing things this way shows you that the tooling doesn’t have to be complicated. I assume that there are very good reasons why the tooling is complicated—stuff like code splitting, modular CSS, etc. If you’re writing pure JS React and putting the CSS elsewhere, you can squeak by with fairly simple tools.

raverbashing 5y ago

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.

random314 5y ago

> This is not limited to macros, but any abstraction. Disagree here. Unix process, file access api's, programming languages are all abstractions that make life easier.