4 ms·

I think it also helps that, in practice, there seems to be a common philosophy (at least among the Clojurists I've talked to) that macros should be used only wh

by austinz 12y ago

I think it also helps that, in practice, there seems to be a common philosophy (at least among the Clojurists I've talked to) that macros should be used only when absolutely necessary. Because of this, the sort of unrestrained, ubiquitous code rewriting that the author mentions is rare.

bmh100 12y ago
Yes, and a lot of that can also be traced back to the built-in macros that Clojure provides and encourages. Macros like apply, ->, ->>, partial, memoize, and even . just make it so much rarer that a developer needs to write a macro outside of DSL development. It's wonderful.
- bmh100 12y ago
  Could someone who downvoted this post please offer feedback? I do not understand why this comment did not contribute to the discussion.
  - tim333 12y ago
    I didn't downvote but as someone who uses Python and doesn't know Clojure, phrases like "Macros like apply, ->, ->>, partial, memoize, and even . just make it so much rarer that a developer needs to write a macro" make me glad I don't have to muck about with that stuff.(?)
dragonwriter 12y ago
> I think it also helps that, in practice, there seems to be a common philosophy (at least among the Clojurists I've talked to) that macros should be used only when absolutely necessary. Sure. One thing about that is that the DRY principle -- and the expanded form, "don't repeat anyone, ever" -- has been a popular mantra throughout the programming community for a while (and even before that particular form, emphasis on reusable code was common), and Clojure has really come into its own in the time when that that philosophy has been strong. One of the great things about macros is that they enable reusable solutions to broader problems than you can effectively address in library code in many languages; a corollary of which is that most programming in a language with macros should need neither to define new macros nor to use the repetitive boilerplate code that macros enable reusable alternatives to.

by austinz 12y ago

bmh100 12y ago

Yes, and a lot of that can also be traced back to the built-in macros that Clojure provides and encourages. Macros like apply, ->, ->>, partial, memoize, and even . just make it so much rarer that a developer needs to write a macro outside of DSL development. It's wonderful.

bmh100 12y ago
Could someone who downvoted this post please offer feedback? I do not understand why this comment did not contribute to the discussion.
- tim333 12y ago
  I didn't downvote but as someone who uses Python and doesn't know Clojure, phrases like "Macros like apply, ->, ->>, partial, memoize, and even . just make it so much rarer that a developer needs to write a macro" make me glad I don't have to muck about with that stuff.(?)

dragonwriter 12y ago

> I think it also helps that, in practice, there seems to be a common philosophy (at least among the Clojurists I've talked to) that macros should be used only when absolutely necessary. Sure. One thing about that is that the DRY principle -- and the expanded form, "don't repeat anyone, ever" -- has been a popular mantra throughout the programming community for a while (and even before that particular form, emphasis on reusable code was common), and Clojure has really come into its own in the time when that that philosophy has been strong. One of the great things about macros is that they enable reusable solutions to broader problems than you can effectively address in library code in many languages; a corollary of which is that most programming in a language with macros should need neither to define new macros nor to use the repetitive boilerplate code that macros enable reusable alternatives to.