Dynamic Languages vs Static Languages (round two)

Recently, I was looking (don’t ask why, maybe I will tell you in the future, if I ever get the time and focus) at Docker Engine SDKs, searching if you could start/stop containers programmatically.

It seems that you can, and in a variety of languages, like golang, python or via a REST API.

The first example to just run a simple command within a container image, was in Golang.

It is straightforward, you get the client instance, you pull the image, you start the container and finally you wait and print out the container logs. Really nice, huh? With a few lines of code, you have all this power; at your fingertips.

I was then ecstatic when I saw that the second example was in Python. Cool, let’s see this one too:

What!? It’s only three lines! Three!

So, what’s going on? Why there is so much difference in lines of code, when trying to write such a program.

From the example, it seems that Golang engineer excel at error handle (and spreading panic as well :)). But I think that deep down it is a matter of mentality. Somehow, I believe that the manual handling of all those erroneous conditions, give the perception of control, or at least more control. While having all these functional properties on the APIs, you lose high-level methods that can just do the work, with some defaults in place.

The opposite phenomenon happens on dynamic languages. Everything is super simple, but powerful and pretty often slow. This is the case with Python, or Perl for example.

My take is that you Dynamic does not mean, one-liners and static does not mean over-engineered. We must design and implement, solid orthogonal APIs that are flexible and make sense. This is not the case these days where the communities decide the level of complexity of each languages/framework APIs.

This could a series of articles, see also round one on this topic.