Hacker News Reader

Comment by austinz | Hacker News Reader

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.

View on HN

> 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.

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.

Could someone who downvoted this post please offer feedback? I do not understand why this comment did not contribute to the discussion.

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.(?)

Reply on news.ycombinator.com