Explicitness as a Weakness?

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.

• Explicit/Implicit
• Expressiveness
• Terseness
• Abstraction

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:

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.