Live data from Hacker News

Gödel, Escher, Elisp: The Beauty of Macros

chiply.dev

41–44 of 44 posts

Re: Gödel, Escher, Elisp: The Beauty of Macros

#41
post #36
post #28

Earlier quoted context omitted.

Macros returning macros happens in every Lisp, including Clojure. It’s no biggie. Hygiene has nothing to do with it and there are ways of properly managing unique symbols in all Lisps, even if some dialects are more manual than in Scheme/Racket.

I know, but the point is that in Clojure there's a bit of a culture of not writing macros unless you have to, while in Racket there's no such thing. Agreed that you can write macros just fine in other lisps.

The Clojure community is definitely less macro-crazy than other Lisp communities. But it’s also very programmer-specific. I’ve worked on OSS Clojure code where the original programmer loved macros. In general, I found it more annoying because reading through recursive macros is just more difficult than reading a simple function. So, I think it’s better for the community to de-emphasize macros, in general. Even if I want back to programming in CL or Scheme/Racket, I think I’d be much more judicious about using macros. Again, nothing against macros in general. They are a powerful tool in Lisp. But, to quote Spider-Man, with great power comes great responsibility.

Re: Gödel, Escher, Elisp: The Beauty of Macros

#42
post #3

Remember the golden rule of Lisp macros: don't write a macro.

I agree! A Lisp coder should define a new macro only rarely. Junior coders should avoid doing it altogether.

Macros make Lisp code hard to read. Every time I see a call to define-minor-mode, a groan a little: that macro saves about 5 tokens (relative to just writing out code involving only functions everyone knows) at the cost of making me bounce back and forth at least 3 times between (a buffer showing) define-minor-mode's doc string and the call.

Re: Gödel, Escher, Elisp: The Beauty of Macros

#43
post #35
post #34

Earlier quoted context omitted.

Ok, common-lisp newbie here. Could you explain why Paul Graham's book "On Lisp" is wrong? Or misguided? Or misunderstood by newbies like me? 30 years of c++ with a lot of dealing with templates and I'm not feeling the mandatory function purity here.

I don't think that is a reasonable request for a response to a comment post, but in my experience, many lisp macro advocates come from other procedural / OO languages and aren't well acquainted with other programming paradigms, so they don't generally know what the don't know about other styles, say functional programming, and how to solve problems using higher order functions, etc. instead of reaching for macros. Wh…

Suppose I accede to every claim you make here. Where may I see the advantage in the long run, in any dimension? I'm willing to go with hearsay.

The word "dimension" is chosen to be so vague that you can surely do it. I would be easy to impress.

Re: Gödel, Escher, Elisp: The Beauty of Macros

#44
post #43
post #35

Earlier quoted context omitted.

I don't think that is a reasonable request for a response to a comment post, but in my experience, many lisp macro advocates come from other procedural / OO languages and aren't well acquainted with other programming paradigms, so they don't generally know what the don't know about other styles, say functional programming, and how to solve problems using higher order functions, etc. instead of reaching for macros. Wh…

Suppose I accede to every claim you make here. Where may I see the advantage in the long run, in any dimension? I'm willing to go with hearsay. The word "dimension" is chosen to be so vague that you can surely do it. I would be easy to impress.

>Where may I see the advantage in the long run, in any dimension?

The advantage of what?

Post reply on HN