5 ms·

Macros are a cop out of language design. They mean "everybody do what you want and create your own language, we don't care anymore".

thibran 8y ago
No, they solve a complex problem. Have a look at modern web development. Because they have no macros, they wrote a bunch of tools which "compile" different domain specific languages (DSL's) to "the real stuff". Nowadays you compile pseudo HTML, pseudo CSS and JavaScript (modern style) to HTML, CSS and JavaScript (backward compatible, a.k.a. old style JS). That's insane. On the other hand, whiteout those code-transformation tools – which are called macros if they are built into the language – all those fancy and simple web-tools would not be feasible. Ignoring macros means to me oversimplifying programming. Which results into not solving the real (meta) problem. For a while you will get away without macros/code generation, but in the long run they are inevitable.
- cageface 8y ago
  One big problem with macros is that they make it very difficult to build good tools. You can't really understand the meaning of any particular piece of syntax without completely evaluating any macros that might be in use.
  - Groxx 8y ago
    That sounds exactly like what a compiler has to do. And what all type-aware Go tools currently have to do. So we're already doing that, we just have no language-level support for doing so, so we have incredibly less-capable workarounds like makefiles and go:generate.
coldtea 8y ago
Well, they sort of give the same message already, but with custom code-level solutions instead of macros... "Everybody go an invent your own way to handle error checking/propagation" etc...
nostalgeek 8y ago
> Macros are a cop out of language design. They mean "everybody do what you want and create your own language, we don't care anymore". I prefer safe AST based macro than runtime reflection like Go has. The latter is actually a cop-out, unlike the former in the context of type safety at compile time.
pjmlp 8y ago
Instead one gets to use go generate for the same purpose.

thibran 8y ago

No, they solve a complex problem. Have a look at modern web development. Because they have no macros, they wrote a bunch of tools which "compile" different domain specific languages (DSL's) to "the real stuff". Nowadays you compile pseudo HTML, pseudo CSS and JavaScript (modern style) to HTML, CSS and JavaScript (backward compatible, a.k.a. old style JS). That's insane. On the other hand, whiteout those code-transformation tools – which are called macros if they are built into the language – all those fancy and simple web-tools would not be feasible. Ignoring macros means to me oversimplifying programming. Which results into not solving the real (meta) problem. For a while you will get away without macros/code generation, but in the long run they are inevitable.

cageface 8y ago
One big problem with macros is that they make it very difficult to build good tools. You can't really understand the meaning of any particular piece of syntax without completely evaluating any macros that might be in use.
- Groxx 8y ago
  That sounds exactly like what a compiler has to do. And what all type-aware Go tools currently have to do. So we're already doing that, we just have no language-level support for doing so, so we have incredibly less-capable workarounds like makefiles and go:generate.

coldtea 8y ago

Well, they sort of give the same message already, but with custom code-level solutions instead of macros... "Everybody go an invent your own way to handle error checking/propagation" etc...

nostalgeek 8y ago

> Macros are a cop out of language design. They mean "everybody do what you want and create your own language, we don't care anymore". I prefer safe AST based macro than runtime reflection like Go has. The latter is actually a cop-out, unlike the former in the context of type safety at compile time.

pjmlp 8y ago

Instead one gets to use go generate for the same purpose.