Explicitness as a Weakness?

good pt!

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.

Additionally if you create a library whose only interface is a macro then it is not usable by other BEAM languages such as Erlang.

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.

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…

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…

Ecto is clearly in the Query builder / DSL region.

Thanks for the thoughtful reply, really appreciate it : )

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.

Good pt. tbh. the macro abstraction balancing act is still something I have to fully get comfortable with. Perhaps because there is a lot left implicit!! I respect macros, but am constantly slightly worried about them : )

A simple example for “picking bugs out easily”, would be:

1. I have an API
2. I need to retrieve data from the DB
3. many of my queries are similar
4. I will write a function using Ecto queries etc. to cater for all / many of my use cases

I.e. classic parametric polymorphism. Bugs in my DB retrieval code are capture in one place…

Another example:

x) something which uses an interface and adhoc polymorphism, a result type or error type etc.

Bugs in my result / error code are again captured in one place, rather than scattered.

You get the idea. Basically it’s DRY.

Yes 100% true. I was cheekily conflating “implicit” and “abstract”.

I suppose the question is, when someone says, this is well written because it is “explicit”, it can still be explicit and overly verbose, not DRY etc…