The devil’s in the details

There are two schools of thought in the programming world:

  1. Explicit is better than implicit (configuration over convention)
  2. A developer should only have to program the unconventional aspects of a program (convention over configuration).

We’ll call #1 the Python school and #2 the Ruby school. In fact, I
would argue that this is an issue that’s at the core of whether code
is considered “Pythonic” or “Rubyic” (I doubt the last one is a word).

So which school of thought is right? I personally think they both
are. It doesn’t really take a whole lot to demonstrate that the
Python school of thought isn’t always right. Think about it. Did you
know that the Python runtime has a component that goes around deleting
objects from memory totally implicitly? How unpythonic is that?

The Ruby school of thought takes a bit more work though. After all,
if it’s unconventional, why should you have to configure it? Of
course, the problem here is in defining “conventional”. What’s
conventional to me is likely unconventional to others. And what’s
conventional to others could be unconventional to me.

I wish I had more advice on how to reconcile these two schools of
thought. The truth is that I struggle with them daily. But I think
having an intuition about this is the dividing line between
“experienced programmer” and “newb”. After all, if programming were
merely about “make everything explicit” or “make everything implicit”,
any idiot could do it.

I think this is also the core skill for writing readable code. You
need to determine what details are relevant to each piece of code.
Whatever the case, you need to make a conscious decision as to what
details shine through and what details you obscure. Because if these
things happen on accident, they’re almost guaranteed to be wrong.