3 ms·

As a OO programmer, I would still argue that: if I define a set of functions repeatedly, I will try to find an elegant object design to abstract that. One good

by lolive 8y ago

As a OO programmer, I would still argue that: if I define a set of functions repeatedly, I will try to find an elegant object design to abstract that. One good point, then, is that I can debug that object design at any line of code. Whereas (I feel that) macros are undebuggable by design.

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.
chriswarbo 8y ago
I get where you're coming from, and it's something that's been debated at length. For everything-is-an-object languages like Smalltalk, the dynamic features seem to be enough to cover lots of problems that macros are used for (e.g. https://news.ycombinator.com/item?id=14333824 https://news.ycombinator.com/item?id=14333824 ). I hear that Ruby uses monkey-patching more than other languages, which may also be an alternative (although I think macros are better than monkey-patching, since they're local transformations rather than "spooky action-at-a-distance"). Simula-style languages like C++ and Java don't offer the same sorts of dynamic features. > Whereas (I feel that) macros are undebuggable by design. I'd be interested to know what you mean by this. I've written macros in Emacs Lisp and Racket, and both were pretty easy to debug. In particular the tooling for each (Emacs and DrRacket) can "expand macros" to show what code a particular macro usage will turn into (at which point, we're back to debugging non-macro code; although potentially messier than we'd right by hand). In that sense they're more debuggable than functions, since we can't calculate the result of a function until run time (which is why functions need test suites, to provide a run time that's not the production application).
chriswarbo 8y ago
Note that the Blub Paradox ( http://wiki.c2.com/?BlubParadox http://wiki.c2.com/?BlubParadox ) applies to this sort of thing, which is important to keep in mind. Essentially it says that we understand the things we're used to using, but not those we're not. Hence we can appreciate, instinctively, the problems caused by languages which lack a thing we're used to (for example, the standard "Go needs generics" arguments). Yet it's harder for us to appreciate those same problems if we're not experienced with that feature (e.g. someone who's only ever programmed in Go).

by lolive 8y ago

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.

chriswarbo 8y ago

I get where you're coming from, and it's something that's been debated at length. For everything-is-an-object languages like Smalltalk, the dynamic features seem to be enough to cover lots of problems that macros are used for (e.g. https://news.ycombinator.com/item?id=14333824 https://news.ycombinator.com/item?id=14333824 ). I hear that Ruby uses monkey-patching more than other languages, which may also be an alternative (although I think macros are better than monkey-patching, since they're local transformations rather than "spooky action-at-a-distance"). Simula-style languages like C++ and Java don't offer the same sorts of dynamic features. > Whereas (I feel that) macros are undebuggable by design. I'd be interested to know what you mean by this. I've written macros in Emacs Lisp and Racket, and both were pretty easy to debug. In particular the tooling for each (Emacs and DrRacket) can "expand macros" to show what code a particular macro usage will turn into (at which point, we're back to debugging non-macro code; although potentially messier than we'd right by hand). In that sense they're more debuggable than functions, since we can't calculate the result of a function until run time (which is why functions need test suites, to provide a run time that's not the production application).

chriswarbo 8y ago

Note that the Blub Paradox ( http://wiki.c2.com/?BlubParadox http://wiki.c2.com/?BlubParadox ) applies to this sort of thing, which is important to keep in mind. Essentially it says that we understand the things we're used to using, but not those we're not. Hence we can appreciate, instinctively, the problems caused by languages which lack a thing we're used to (for example, the standard "Go needs generics" arguments). Yet it's harder for us to appreciate those same problems if we're not experienced with that feature (e.g. someone who's only ever programmed in Go).