The main problem with macros (and similar language features) is that they turn every codebase into its own DSL. When done tastefully it makes the code more readable, but there's still an overhead for newcomers to the codebase - they need to learn your DSL before they can be productive.
LLMs may make this overhead less visible to you, but surely it's still there? I'd rather more of my tokens went towards solving the actual task at hand, vs figuring out a custom syntax (and re-learning it on every fresh context window).
I'm not stoked about macros, but the overhead for newcomers to the codebase, as an argument, I find weak. There's so many things that make understanding a new (to you) codebase hard, and I'm not hearing an argument that macros stand out, there.
An example DSL I wrote implements a prolog subset inside an imperative language (C++). Can you imagine the confusion a poor junior would have the first time they look at a file and it's all logic programming? It's hilarious, but definitely not a sledgehammer to be used lightly.
The patterns that macros express are still there in the codebase, usually via uncompressed repetition.
You would need to learn the pattern regardless if you used a macro or not, and a macro at least formally codifies the repetition.
Indeed, one can make bad abstractions, or messy extensions to the macro, but that's true of functions or classes just as much.
Not supporting macros seems to me as an arbitrary limitation put in place as a stop gap for a symptom with a different root cause. (I.e. removing expressive power to solve poor engineering or immature macro tooling).
It's definitely easier to mess things up with macros, but it's also easier to mess more up the higher up you go in any abstraction ladder.
Now that I'm writing this comment, the very fact that we have to distinguish a macro vs regular code feels like a design smell to me.
Functions should operate on data or code, and controlling when it applies, comp time, run time, or some JIT, should be a separate lifecycle configuration detail, or decoupled in a different manner.
Retr0id · · focus · HN ↗
LLMs may make this overhead less visible to you, but surely it's still there? I'd rather more of my tokens went towards solving the actual task at hand, vs figuring out a custom syntax (and re-learning it on every fresh context window).
sverhagen · · focus · HN ↗
AlotOfReading · · focus · HN ↗
aeonik · · focus · HN ↗
The patterns that macros express are still there in the codebase, usually via uncompressed repetition.
You would need to learn the pattern regardless if you used a macro or not, and a macro at least formally codifies the repetition.
Indeed, one can make bad abstractions, or messy extensions to the macro, but that's true of functions or classes just as much.
Not supporting macros seems to me as an arbitrary limitation put in place as a stop gap for a symptom with a different root cause. (I.e. removing expressive power to solve poor engineering or immature macro tooling).
It's definitely easier to mess things up with macros, but it's also easier to mess more up the higher up you go in any abstraction ladder.
Now that I'm writing this comment, the very fact that we have to distinguish a macro vs regular code feels like a design smell to me.
Functions should operate on data or code, and controlling when it applies, comp time, run time, or some JIT, should be a separate lifecycle configuration detail, or decoupled in a different manner.