3 ms·

Suppose you were forced to use a language with no objects, and no closures. Since you're an effective dev, you'd find ways to cope. But we invented object syste

by shawn 8y ago

Suppose you were forced to use a language with no objects, and no closures. Since you're an effective dev, you'd find ways to cope. But we invented object systems to do better work. Closures were another step up the ladder of abstraction, and now it's hard to imagine not being able to use them. Macros are no different. It seems worth being skeptical of the idea that it's better for a programmer to have less power. And Emacs Lisp shows macros can work at scale without causing friction. To your point on debugging, it all depends on the language. Elisp has an excellent debugging facility: https://www.gnu.org/software/emacs/manual/html_node/elisp/Edebug-and-Macros.html#Edebug-and-Macros https://www.gnu.org/software/emacs/manual/html_node/elisp/Ed... The key is to internalize that macros are no different from functions. If you know how to call a function, you know how to use macros. The only difference is that they return code rather than values.

lucozade 8y ago
This was kind of my original point though. If you do treat them as compile time functions i.e. for a bit of light code gen then they can be super useful. But that's often not the case. In fact, OO is a nice example. It's probably less true now that OO seems to be a bit out of fashion, but the number of crappy, poorly documented OO systems I've seen in Lisps over the years is staggering. It's not really a criticism of macros so much as an observation. It's also possible that the type of developer who is attracted to adding a bijou OO system into their application is the type of developer that is attracted to Lisps. It may well be the case that adding a macro system to JS wouldn't have the same attraction so wouldn't have the same downside.
- deleted 8y ago
  [deleted]
xfer 8y ago
> If you know how to call a function, you know how to use macros. Wrong, there are many macros that are impossible to grok without reading the docs carefully, there are also scoping rules. They are nowhere near at the usability of functions, macros should be written judiciously. Most uses of macros can be eschewed by higher-order functions, unless you are making a language.

by shawn 8y ago

lucozade 8y ago

This was kind of my original point though. If you do treat them as compile time functions i.e. for a bit of light code gen then they can be super useful. But that's often not the case. In fact, OO is a nice example. It's probably less true now that OO seems to be a bit out of fashion, but the number of crappy, poorly documented OO systems I've seen in Lisps over the years is staggering. It's not really a criticism of macros so much as an observation. It's also possible that the type of developer who is attracted to adding a bijou OO system into their application is the type of developer that is attracted to Lisps. It may well be the case that adding a macro system to JS wouldn't have the same attraction so wouldn't have the same downside.

deleted 8y ago
[deleted]

xfer 8y ago

> If you know how to call a function, you know how to use macros. Wrong, there are many macros that are impossible to grok without reading the docs carefully, there are also scoping rules. They are nowhere near at the usability of functions, macros should be written judiciously. Most uses of macros can be eschewed by higher-order functions, unless you are making a language.