[JulianMorrison]

It's the difference between "programmable programming languages" (which the lisps are, as are haskell and ruby) versus "languages for programming in" (exemplified by go and java).

Go code is very terse compared to the general run of "languages for programming in". And if you know the language, you can just read it.

On the other hand, you've got some serious digging to do if you want to understand a clojure macro. Metaprogramming like that is seriously brain twisty.

[gruseom]

On the other hand, you've got some serious digging to do if you want to understand a clojure macro. Metaprogramming like that is seriously brain twisty

I wish this meme would stop. Your "if you know the language, you can just read it" applies just as much here as it does there.

[rsanders]

I think you can be pretty proficient in writing regular Clojure and still find macros "twisty". Most Clojurians would agree that "The first rule of Macro Club is Dont Write Macros".

[gruseom]

Well, I wish that meme would stop too. It makes macros sound all freakazoid, when really they're just another technique. The obvious and natural and historically standard guidance is "Don't write a macro when a function will do."

[mheiler]

The concrete example is a perfect use case for a macro: In other languages you have to understand and change the compiler implementation to achieve the same effect. That's most likely more work.

[tome]

Another interpretation is that you can read "programmable programming languages" at the level of the problem domain, rather than at the level of the base language. (Assuming the problem domain is encoded sufficiently decently in a DSL).