> Given that it all compiles down to JS before execution, I'm not sure I agree.
Most likely, they meant "simple" more in the syntactical sense than in the sense of language abstraction level.
> Macros are the old LISP fallback, but seem very counter to any argument of 'simplicity'
Macros is just transformation over a data structure, albeit a data structure that is interpreted as code later on. It shouldn't add more complexity than other forms of data transformation.
> I very rarely find need for macros in the front…
Neither do I, but I'm glad they exist. Core.async is built with macros, for example. They are part of what makes it possible to have core.async as a library rather than having to build it into the language.
Macros de-risk themselves by going away before compile time. So even if they are complex, they are not complex in a way that causes us to lose sleep at night wondering "does that have a hidden bug that will blow up in the field".
Even if a macro is buggy, if the particular instances (i.e. macro calls) don't step on the bug, then we are okay. The expansion is done, and it is good.
Macros are deterministic and susceptible to regression testing with simple "X translates to Y" assertions.
We don't have to be overly concerned with the time and space performance of macros, either. The code in a macro expander can be structured for clarity and remain that way.
(Even in situations in which running Lisp apps are patched, the macro expansion doesn't have to be done in the application image. The translation unit can be compiled using a separate development image, and loaded as compiled files in the running app.)
>> Most likely, they meant "simple" more in the syntactical sense than in the sense of language abstraction level.
Outside of the Clojure world this would be a reasonable interpretation. However, if you watch 'Simple made easy' by Rich Hickey - that was the definition of simple I was going with (as opposed to easy.)
>> Macros is just transformation over a data structure, albeit a data structure that is interpreted as code later on. It shouldn't add more complexity than other forms of data transformation.
Because they specifically inject before the eval section they _do_ add a lot of complexity. Writing complex macros is a lot of guesswork.
>> Neither do I, but I'm glad they exist. Core.async is built with macros, for example. They are part of what makes it possible to have core.async as a library rather than having to build it into the language.
I'm not sure what the benefit of this vs 'language features' is at this point.
Most likely, they meant "simple" more in the syntactical sense than in the sense of language abstraction level.
> Macros are the old LISP fallback, but seem very counter to any argument of 'simplicity'
Macros is just transformation over a data structure, albeit a data structure that is interpreted as code later on. It shouldn't add more complexity than other forms of data transformation.
> I very rarely find need for macros in the front…
Neither do I, but I'm glad they exist. Core.async is built with macros, for example. They are part of what makes it possible to have core.async as a library rather than having to build it into the language.