4 ms·

Macros are frowned-upon within the Clojure community, and for very good reasons. EDIT: okay, I got downvoted for some reason. Care to explain why? The mantra

by kaoD 13y ago

Macros are frowned-upon within the Clojure community, and for very good reasons. EDIT: okay, I got downvoted for some reason. Care to explain why? The mantra in Clojure is "don't write macros until you NEED macros" (or some alternative[1]). They make things horribly complicated and are awful to debug and make code that uses them hard to debug too... especially within a JVM environment (your code gets translated twice). [1] http://clojurefun.wordpress.com/2013/01/09/when-do-you-need-macros-in-clojure/ http://clojurefun.wordpress.com/2013/01/09/when-do-you-need-...

RivieraKid 13y ago
I didn't downvote you but the only significant advantage of the lisp syntax is macros. I was always under the impression that the syntax is a price for macros. If macros aren't really used, I don't see reasons for the lisp syntax.
- kaoD 13y ago
  Macros are frowned-upon but used when necessary. To put an analogy: people would've disgusted if you used a life jacket for no good reason, but they're handy when you really need them :) I also like Lisp syntax regardless of macros, mainly because it's simple, consistent and prefix notation is really handy. The S-expr abstraction IS useful when dealing with code blocks (see https://news.ycombinator.com/item?id=5940620 https://news.ycombinator.com/item?id=5940620)
  - RivieraKid 13y ago
    Brainfuck syntax is even simpler and more consistent ;)
    - kaoD 13y ago
      If Brainfuck syntax was half as powerful as powerful as S-expressions that would be a valid comparison.
- dktbs 13y ago
  I would argue that s-expressions are powerful for reasons other than macros, but I agree that the prefix notation and boatloads of parentheses can initially require a lot of extra effort for no apparent payoff. When I began writing clojure code (in vim) this was a constant source of frustration for me. The paredit.vim plugin [https://github.com/vim-scripts/paredit.vim https://github.com/vim-scripts/paredit.vim] made things much easier and led me to give emacs a serious try. Writing lisp in an editor with paredit is a magical feeling. It turns the onion of parentheses into a structure that you can navigate and modify without having to worry about keeping things balanced. For me, this has made the parens effectively disappear from my focus.
gruseom 13y ago
"Don't write a macro when you could write a function instead" has been standard advice since decades before Clojure. "Macros make things horribly complicated" is nonsense, or no skilled programmer would use them. And from the frustrations my Clojure friends recount to me, ease of debugging is an issue quite apart from anything to do with macros.
- kaoD 13y ago
  > ...has been standard advice since decades before Clojure. Yes, but we're in a thread dedicated to Clojure ;) > "Macros make things horribly complicated" is nonsense, or no skilled programmer would use them. Which is what happens, really, and when used it's in a very limited fashion. For example, for quite popular projects inside the Clojure community: Leiningen used one macro[1] and Compojure two[2]. A properly done (and properly used) macro might not make things complicated, but this leads me to the next paragraph. > ease of debugging is an issue quite apart from anything to do with macros. It's usually hard, but macros make it HORRIBLE since you can easily lost track of the generated code. Like if translating from Clojure to Java Stack Traces wasn't hard enough... Whenever you use a macro, the stack traces you receive from the code using it might not like like what you expect at all. Macros are bad because they mutate your code. You usually have to expand the macro and debug there instead of just looking at your damn code. The big problem is not macros, but code which uses macros. [1] https://github.com/technomancy/leiningen/search?q=defmacro&ref=cmdform https://github.com/technomancy/leiningen/search?q=defmacro&r... [2]https://github.com/weavejester/compojure/search?q=defmacro&ref=cmdform https://github.com/weavejester/compojure/search?q=defmacro&r...
  - gruseom 13y ago
    This does not match my experience. I write macros to make my code shorter when I notice a repeating pattern. To see what the macros do, I use macroexpand. Is debugging a problem? Well, I understand the macroexpansions so I can read them when I need to—so no, it's not that big a problem. You're not the first Clojure person I've heard talk this way about macros, and I don't understand why anyone would be so eager to deprecate such a powerful technique. Especially since it actually works (and works well) in Lisps, and not nearly as well elsewhere. Also, these comments seem odd: A properly done (and properly used) macro The big problem is not macros, but code which uses macros. The macros I know are effectively impossible to misuse. They tell you how they're supposed to be used and you just do it. There's not a lot of room to go wrong! Can you give an example of a macro which is hard to use properly?

by kaoD 13y ago

RivieraKid 13y ago

I didn't downvote you but the only significant advantage of the lisp syntax is macros. I was always under the impression that the syntax is a price for macros. If macros aren't really used, I don't see reasons for the lisp syntax.

kaoD 13y ago
Macros are frowned-upon but used when necessary. To put an analogy: people would've disgusted if you used a life jacket for no good reason, but they're handy when you really need them :) I also like Lisp syntax regardless of macros, mainly because it's simple, consistent and prefix notation is really handy. The S-expr abstraction IS useful when dealing with code blocks (see https://news.ycombinator.com/item?id=5940620 https://news.ycombinator.com/item?id=5940620)
- RivieraKid 13y ago
  Brainfuck syntax is even simpler and more consistent ;)
  - kaoD 13y ago
    If Brainfuck syntax was half as powerful as powerful as S-expressions that would be a valid comparison.
dktbs 13y ago
I would argue that s-expressions are powerful for reasons other than macros, but I agree that the prefix notation and boatloads of parentheses can initially require a lot of extra effort for no apparent payoff. When I began writing clojure code (in vim) this was a constant source of frustration for me. The paredit.vim plugin [https://github.com/vim-scripts/paredit.vim https://github.com/vim-scripts/paredit.vim] made things much easier and led me to give emacs a serious try. Writing lisp in an editor with paredit is a magical feeling. It turns the onion of parentheses into a structure that you can navigate and modify without having to worry about keeping things balanced. For me, this has made the parens effectively disappear from my focus.

gruseom 13y ago

"Don't write a macro when you could write a function instead" has been standard advice since decades before Clojure. "Macros make things horribly complicated" is nonsense, or no skilled programmer would use them. And from the frustrations my Clojure friends recount to me, ease of debugging is an issue quite apart from anything to do with macros.

kaoD 13y ago
> ...has been standard advice since decades before Clojure. Yes, but we're in a thread dedicated to Clojure ;) > "Macros make things horribly complicated" is nonsense, or no skilled programmer would use them. Which is what happens, really, and when used it's in a very limited fashion. For example, for quite popular projects inside the Clojure community: Leiningen used one macro[1] and Compojure two[2]. A properly done (and properly used) macro might not make things complicated, but this leads me to the next paragraph. > ease of debugging is an issue quite apart from anything to do with macros. It's usually hard, but macros make it HORRIBLE since you can easily lost track of the generated code. Like if translating from Clojure to Java Stack Traces wasn't hard enough... Whenever you use a macro, the stack traces you receive from the code using it might not like like what you expect at all. Macros are bad because they mutate your code. You usually have to expand the macro and debug there instead of just looking at your damn code. The big problem is not macros, but code which uses macros. [1] https://github.com/technomancy/leiningen/search?q=defmacro&ref=cmdform https://github.com/technomancy/leiningen/search?q=defmacro&r... [2]https://github.com/weavejester/compojure/search?q=defmacro&ref=cmdform https://github.com/weavejester/compojure/search?q=defmacro&r...
- gruseom 13y ago
  This does not match my experience. I write macros to make my code shorter when I notice a repeating pattern. To see what the macros do, I use macroexpand. Is debugging a problem? Well, I understand the macroexpansions so I can read them when I need to—so no, it's not that big a problem. You're not the first Clojure person I've heard talk this way about macros, and I don't understand why anyone would be so eager to deprecate such a powerful technique. Especially since it actually works (and works well) in Lisps, and not nearly as well elsewhere. Also, these comments seem odd: A properly done (and properly used) macro The big problem is not macros, but code which uses macros. The macros I know are effectively impossible to misuse. They tell you how they're supposed to be used and you just do it. There's not a lot of room to go wrong! Can you give an example of a macro which is hard to use properly?