3 ms·

Most of the macros in libraries were saving a pair of parentheses at the cost of making code more obscure and, well, less explicit. A few co-workers also liked

Most of the macros in libraries were saving a pair of parentheses at the cost of making code more obscure and, well, less explicit. A few co-workers also liked macros alot so they did stuff that could have been done in functions. I suppose my experience is that clojure's core macros are sufficient and/or I never saw a good eDSL that would have been worse without macros. (Input is welcome) Also, I don't feel I missed out on something because the biggest productivity features for me are being functional, maps-as-objects + dynamic typing, destructuring, emacs (yeah I know), immutability, threaded execution via pmap, Java libs. However, I suppose these productivity features depend strongly on where you come from (for me: Java)

sklogic 11y ago
> Most of the macros in libraries were saving a pair of parentheses This is an epic misuse of macros. > and/or I never saw a good eDSL that would have been worse without macros eDSLs should almost never be implemented without macros (unless they're message DSLs). Macro, essentially, is a compiler. The only alternative is to implement an ad hoc interpreter. And compilers are much, much easier to write, debug and maintain than interpreters - for some very trivial reasons. Compilers can be split into sequences of very simple stages, each doing something simple and comprehensible. It's easy to debug, easy to insert additional steps in between, easy to cut off at any point and replace the backend with something totally different. Interpreters are deeply tangled, naturally, there is no way to modularise them. > the biggest productivity features for me are being functional Using macros and eDSLs is another huge step forward in productivity that will dwarf everything you liked so far in FP.
- eutectic 11y ago
  > The only alternative is to implement an ad hoc interpreter. You could also have your eDSL calls act as data constructors for an AST and then implement an `eval` function which invokes a run-time compiler.
  - sklogic 11y ago
    This is not any different from a macro. You still translate your DSL into your host language AST, with the only final step different - runtime eval instead of a compile-time macro. All my macros look like (defmacro something (dsl) (compile-dsl-whatever dsl)). You can always pass the same (compile-dsl-whatever dsl) to (eval ...).
- dkersten 11y ago
  I've been very successfully applying the data > functions > macros guideline. Yes, this makes eDSL's look very clojurey, but in practice I've not seen this to be a problem. That is: prefer a data-structure based DSL (eg Datomic queries) if possible. If not, prefer function composition. Failing that, macros to the rescue.

sklogic 11y ago

> Most of the macros in libraries were saving a pair of parentheses This is an epic misuse of macros. > and/or I never saw a good eDSL that would have been worse without macros eDSLs should almost never be implemented without macros (unless they're message DSLs). Macro, essentially, is a compiler. The only alternative is to implement an ad hoc interpreter. And compilers are much, much easier to write, debug and maintain than interpreters - for some very trivial reasons. Compilers can be split into sequences of very simple stages, each doing something simple and comprehensible. It's easy to debug, easy to insert additional steps in between, easy to cut off at any point and replace the backend with something totally different. Interpreters are deeply tangled, naturally, there is no way to modularise them. > the biggest productivity features for me are being functional Using macros and eDSLs is another huge step forward in productivity that will dwarf everything you liked so far in FP.

eutectic 11y ago
> The only alternative is to implement an ad hoc interpreter. You could also have your eDSL calls act as data constructors for an AST and then implement an `eval` function which invokes a run-time compiler.
- sklogic 11y ago
  This is not any different from a macro. You still translate your DSL into your host language AST, with the only final step different - runtime eval instead of a compile-time macro. All my macros look like (defmacro something (dsl) (compile-dsl-whatever dsl)). You can always pass the same (compile-dsl-whatever dsl) to (eval ...).
dkersten 11y ago
I've been very successfully applying the data > functions > macros guideline. Yes, this makes eDSL's look very clojurey, but in practice I've not seen this to be a problem. That is: prefer a data-structure based DSL (eg Datomic queries) if possible. If not, prefer function composition. Failing that, macros to the rescue.