Obviously I am playing devil’s advocate a litte - but -
I see incredible power when using abstract code. One can do a lot in a little space, pick out bugs easily, etc.
Sure, explicitness is good when you are learning.
But when you want write something reliable and maintainable you probably should be reaching for a suitable abstraction and that means explicitness is kryptonite in such cases.
What do you think?
For me explicitness is not about “not using abstractions”. It’s that the code I use is explicit in what it does (no matter how abstract it is) and it does not do anything I don’t expect. Take elixir macros for example. I don’t need to know how a macro is implemented to have a macro, which is explicit in what it does. E.g. in a project of mine I’m using macros to setup breadcrumb texts/urls. I still need to supply url/title/parent in the macro for a page, which is the things I need to deal with, but how the elements of the breadcrumb are build up and merged is hidden in the macro. Compare that to an implicit calculation from e.g. a module name. There I’m bound to a naming schema or something and can no longer explicitly set e.g. a different parent. I’d consider both “abstract” ways to build up a breadcrumbs list, though.
Also a functional language goes a long way here, as side effects are not littered all over the place to begin with, so the chance for unexpected results is smaller than in oop.
Personally I think explicitness is a little overrated. What I value more than explicitness is composition (and explicitness certainly helps in that department) and runtime deterministic performance. That means I don’t care much if my elixir macros launch nuclear missiles at compile time, as long as they generate nice “static” and predictable code. Even if such code is divorced from the macro invocation. And most things that macros do is just defining new modules and functions or expand into normal elixir syntax.
Contrast this with python, which doesn’t really support compile time metaprpgramming and must use runtime (load time? Boot time?) metaprogramming.
Elixir does allow you to compile code on the fly, but as long as you keep away from such things, you’re pretty safe.
I don’t like using the nqme of the module in macros (like phoenix does for the MVC part), but as long as it’s easy to override it’s not too bad.
I think you have it the other way around 
Explicit doesn’t mean you can’t have good abstractions. In terms of reliability and maintainability I’d pick explicit over implicit (but as we’ll see it is not that simple)
I’d say in terms of how easy something is to learn I think implicit is probably easier because of information hiding. For example, elixir makes a number of things that are explicit in erlang implicit and from what I understand a big reason behind this is to make it easier to learn. It doesn’t change the abstraction though, it is still the same (think gen server optional callbacks). It is just that it pushes the time a beginner need to learn about a concept further into the future. In the gen server case, the implicit call backs may actually hurt maintainability as you can easily miss to implement a callback. So in general I think things are made implicit to do things faster now so that you don’t have to understand things until later.
I don’t think explicit implicit is enough though so I misuse a few other terms to try to make things clearer.
Are these scientific terms? Yes. Am I using them correctly? Probably not
How these combine gives you an overall idea which trade-offs are being made. Lets take a common example. ORM vs SQL.
SQL is explicit, but not terse. It is a good abstraction accessing relational data. SQL is not very expressive. ORM is implicit and terse. The abstraction is only good at the basic level. The query level of an ORM can be very expressive.
In terms of “learnability” I think ORM seems to have the upper hand, likely because it hides away important information you really should now before using it. Hence, implicit can be technical debt.
Is there a middleground? Yes, some query builders. They have the benefit of SQL in that the abstraction over data is good but they are also terse and expressive. The “query builders” are explicit, while still keeping a good abstraction. They are more maintainable and reliable than SQL and ORM. I’m not quite sure where ecto is in all this. I think somewhere in the middle but towards the ORM layer (just a feeling, no concrete data behind this).
I think you would have to first define what is explicitness.
Some could say that managing your own memory is very explicit but I am sure we would collectively agree that we don’t want to allocate memory by hand. Doing so would get in the way of other things, such as your business logic.
Explicitness is not about lacking abstractions. Often those things go together: macros are a high form of abstraction, so we want their use to be explicit.
Explicitness is not about outlining all of the configurations to a function or a library instead of relying on good defaults. It is not against convention over configuration.
Explicitness is about making the choices clear when we believe those choices matter. It is about readability. We use explicitness when we believe omitting information is harmful to the understanding of the software compared to clearly spelling it out.
We will likely agree on many things that need to be explicit but others things will be guided by opinions and/or personal experience.
Care to elaborate on the “pick out bugs easily” part?
If this is primarily about macros then it is important remember that there are always tradeoffs involved. Example:
defmodule Demo do
use Attr
attr :three
attr :two
attr :one
end
IO.inspect(Demo.get_attrs()) # [:one, :two, :three]
# ???
Evidently it’s equivalent to:
defmodule Demo1 do
def get_attrs(),
do: [:one, :two, :three]
end
which isn’t transparent on first sight unless you are already familiar with
# Blatantly plagiarized from Plug.Build
defmodule Attr do
defmacro __using__(_opts) do
quote do
import Attr, only: [attr: 1]
Module.register_attribute(__MODULE__, :attrs, accumulate: :true)
@before_compile Attr
end
end
defmacro __before_compile__(env) do
attrs = Module.get_attribute(env.module, :attrs)
quote do
def get_attrs() do
unquote(attrs)
end
end
end
defmacro attr(attr) do
quote do
@attrs unquote(attr)
end
end
end
In a way the macro invocation is an alternate representation (compression) of the code that it will leave behind. That succinctness suppresses certain details (which may be desired) some of which could improve clarity (e.g. showing how the resulting code connects and relates to the “rest of the world”). The only way to compensate for that lack of exposed detail is to understand what the macro actually represents. So improved succinctness may also increase the cognitive load for anybody trying to comprehend what the code does.
In many situations the tradeoff is worth it. But every case is still is a balancing act between the benefits of succinctness, reuse potential and the effect on clarity and comprehensibility. Not all abstractions are created equal.
Uh, what? o.O
Abstract is not the opposite of explicit, implicit is the opposite of explicit. You can be perfectly abstract with either explicit or implicit.
As for between explicit and implicit, explicit means things are obvious in what they do, few to no surprises (4 = 2+2), where implicit means that you cannot necessarily understand what is happening or that it is surprising ([2, 2] = 2+2).
Perl may be more succinct than python, but that is because they chose different syntax, the actual ‘tokens’ between them is pretty equal, however perl is more ‘implicit’ in that you cannot always know what, say, a function will return or even ‘do’ at all when called at a certain place unless it is in, oh, a scaler or list context, and even then this can be surprising depending on where ‘this’ code is called and so forth. Perl has a lot of ‘surprise’ because of it’s implicit/hidden state, where Python is far more explicit by default.
Definitely not. That just means you are delaying actual thinking about your code for a later point in time. Usually denoted by the concept of technical debt.
“I will do it later” is a not a good time and effort management technique.
I suppose from my pov, what I was thinking about, is not Ruby on Rails style doing “one thing well in a little space” but Haskelly academic style abstraction etc. : )
Which is a bit more thoughtful up front : )
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…
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:
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.
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.
good pt!
© Copyright Elixir Forum | Terms | Privacy & Cookies
