My point is, explicitness is a crutch sometimes, when really we want:
Explicitness /and/ DRY (i.e. a suitable abstraction)…
The good thing is, non-macro code comes is very easily explicit.
On a tangent, I would love somebody to point me to a good resource on how to use macros properly, I really need to get comfortable with that type of abstraction.
Ecto is clearly in the Query builder / DSL region.
Thanks for the thoughtful reply, really appreciate it : )
Personally I think explicitness is a little overrated
Yup, me too, I suppose non-macro Elixir is v explicit, perhaps that’s why many people here picked me up wrong, the ABCs of abstraction are built from composition, parametric and adhoc polymorphism…
Yep, i agree that functional is a big jump already.
But don’t you lose a little from having /such/ an explicit macro?
If I have the some basic atoms which I compose and recompose together, I can reuse and compose to my heart’s content.
that’s why I am sort of suspicious of macros, they are not so much an abstraction, but a concretisation which I cannot really reuse easily..
Nice crystalisation actually, maybe that’s why I don’t like macros - because they often are not easily reuseable abstractions…
I would say that in general, macros belong to libraries. There are very few cases where I would consider defining a macro in an application.
For libraries my rule of thumb is to first define an interface of only functions and data structures and then evaluate if it needs macros to make it less verbose or nicer to use. The important bit is that macros shouldn’t be the first thing you start with. This leads to a much more flexible design.
Additionally if you create a library whose only interface is a macro then it is not usable by other BEAM languages such as Erlang.
Thanks for this. Appreciate it. You are right.
If I think about macros like mini compilers, and ways to create new semantics not readily available in Elixir.
They end up being a little like oil and water when it comes to composition and polymorphism etc.