On 'Explicit is better than Implicit'

I shared a couple of thoughts on Twitter:

https://twitter.com/JEG2/status/1121561197780844544

and there were some replies:

https://twitter.com/ChrisKeathley/status/1121737994657050624

Personally, I love to write rather explicit code (and more code) than implicit code with hidden side effects.

Over the last 1,5 years, I had to work on a few client projects in javascript/nodejs and one thing was the same on all of them:

I wrote rather explicit code where the “data path” is easy to see and reason about. Then a couple weeks in, the javascript/nodejs developers at the client started to rewrite everything just to end up with the minimum amount of code but with maximum complexity and implicity. Especially things like “factories” and “currying” were their favorite solutions to everything.

The functionality to the outside was the same, the performance of the application wasn’t improved but IMO the code smelt like a dead fish.

For me, explicit vs. implicit is mostly about code design and readability. When I look at code, I want to understand what it does without following a handful of helper functions and modelling of the data structure in my head first.

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.

This is so true!

Go is a prime example of this, the sheer huge amount of code just to do simple algorithms obscures the work actually being done.

It’s a fine balance. I’m finding this thread quite interesting to read so far to see everyone’s ideas on it.

To me, “explicitness” must be married to “readable for humans”. I’m fully okay with some implicit variable somewhere – say, an Agent storing a base URL to a 3rd party API, or Ecto’s Repo config (or almost any config really). If that implicit variable changes rarely then the reduced human cognitive cost of calling functions with less arity is indispensable.

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.

This sounds like my regular rant about the habit of many JavaScript developers of using inline anonymous functions instead of factoring the functionality into a well-named function.

However that is not the impression I got from the podcast.

To me the argument seemed to be that the Python-style preference of Explicit Is Better Than Implicit is wrongheaded:

#Explicit
def read_csv(filename):
    # code for reading a csv

def read_json(filename):
    # code for reading a json

#Implicit
def read(filename):
    # code for reading a csv or json
    # depending on the file extension

i.e. read(filename) is implicit but also more loosely coupled; read_x(filename) is more explicit but a) more tightly coupled and b) forces the complexity of determining the file type onto the user 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

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

Hey wait a minute!

This! Anonymous functions complect the function code with the call, turning two (or more) simpler expressions into a single, complicated one. I don’t like this in general and I particularly dislike it when I’m creating a pipeline.

So, I almost always stuff my anonymous functions into local variables and then use them by name. However, I’m still struggling with the definition of a “well-named function”. My current (idiosyncratic) idiom looks like:

|> Enum.map(map_fn)

This works fine for many simple situations, but it can get a bit ugly when there are naming collisions:

|> Enum.map(map_fn1)
|> Enum.map(map_fn2)