My take on the “explicit better than implicit” is that we want to make the complexity explicit. This makes its interpretation a bit more personal, because what is complex for some is not necessarily complex for others, but I believe it aligns well with FP. Mutability is troublesome? So let’s make it explicitly opt-in. Communication is hard? Let’s be explicit with messages! Oh, you have side-effects? Let’s keep them in their own corner.

In particular, explicit does not mean dropping things like “convention over configuration”. In fact, I would argue that making everything verbose makes it less explicit, because you don’t know what to focus on (i.e. if everything is explicit, then nothing is explicit).

PS: I didn’t listen to the episode yet.

Oh that’s fine lots of people don’t listen to podcasts. No big deal.

Hey wait a minute!

Since a few people haven’t listened to the podcast I thought I would try to explain some of the main points. I’m not sure I can enumerate everything here with as much nuance as we had on the show so I’d still recommend listening. But hopefully I can capture the main points.

I made the case on the show that a lot of the apis that people like in elixir tend to be highly implicit apis. I also made the case that explicit apis tend to be worse apis then implicit apis. That was my contrarian opinion. So now I’ll try to justify it.

When I’m talking about implicit apis what I’m really talking about is encapsulation. A key part of good api design is about hiding large amounts of complexity behind a small interface. If this is done well then the end user doesn’t ever notice the underlying complexity which is really as good as removing complexity altogether. The interface should be small for similar reasons. If you need to chain together multiple api calls in order to use a module then this is a more complicated api then an api that accomplishes the same goal through a single api call. A good example of this would be if every time you wanted to execute a query through ecto you also needed to check out the database connection yourself, parse and compile the query yourself, send the query to Postgres yourself, etc. I refer to APIs like this as “maximally explicit APIs”. They tend to be cumbersome to use and more error prone. But ftmp ecto hides all of this complexity and it’s a better api because of that.

But all of those details are “implicit” to us, the end users of Ecto. We don’t see how any of that stuff is managed from an api perspective. Sure there are escape hatches into that level of the system. But generally you don’t have to wander down there. At our layer of the stack the call to Repo is explicit, the query is explicit, and everything else is encapsulated.

Obviously those details are handled somewhere. If you work on a database pooling solution then you might have to care about them. But at our layer we’re able to ignore them and instead be more explicit about our domain logic.

The trend I see is that people have taken advice like “explicit is greater than implicit” and are carrying it a little too far. If you build a “maximally explicit” api then you quickly start to limit your ability to encapsulate complexity. If you take explicitness to it’s limit then encapsulation becomes impossible.

I think when people say they want explicit APIs over implicit APIs what they really are saying is “don’t surprise me”. If you say to ecto “run this query” you expect it to run the query. You don’t expect it to run the query and also buy you a toaster. The rails example you mention @PragTob is a great example of a surprising api. It’s almost like it was designed to create surprise through indirection.

I think what we ought to be heading for are APIs that encapsulate large amounts of complexity - which means APIs that hide implicit details - and have few if any surprises. It’s a tricky balance. But I think that’s the correct strategy.

Implicit vs explicit is about the functionality of an API and communication. The discussion that we were having on the show was born out of some developers avoiding putting parts of the code into functions and the argument is that things aren’t explicit once they were in another function.

I find this to be a fallacious argument. Placing code into a function doesn’t make it implicit. In fact, it often creates a more explicit API when paired with an intention revealing name. Naming something in a way that communicates the intention and what it does is one secret to a self-documenting API. In the end, we want code that communicates its intention in an explicit way. Often the intention is lost when the reader has to wade through conditionals and Enum calls to figure out the intention of the code.

(didn’t listen to podcast as podcast really isn’t my kinda medium)

Thanks for bringing the discussion here, never thought there would be so many different opinions/views on this

My major interpretation of explicit vs. implicit is to a degree how much I can easily see what’s going on and control it.

My favorite example is ActiveRecord vs. Ecto.

In ActiveRecord I define all the validations and callbacks in the model. Somewhere else I then call save and all of these are magically executed (with all the weird conditions applied in the model). I don’t see what is executed and in what order.
In Ecto on the other hand I specifically choose a changeset that I want this to be run through, I can easily see what is done and in what order. If I don’t want something to happen I can easily remove it or explicitly call another changeset. Makes my intentions very clear.

Similar thing about automatic preloading of associations vs. not or the way in which you need a PhD in ActiveRecord to know what triggers a database case vs. modeling it more explicitly through use of a Repo in Ecto.

As it still rings in my head from an early Ruby Rogues episode where @JEG2 said “magic is always bad” - the more experience I have, the truer that statement rings - kudos James