Information radiators are commonly used in operations to display the status of servers, network segments,…
It so happened that earlier in the week I had stumbled across a 2011 talk by Rich Hickey, Simple Made Easy, and had also re-read an influential piece from 2002 by Joel Spolsky, The Law of Leaky Abstractions.
Hickey makes a clear and practical distinction between the notions of simple and easy. Spolsky observes that an unreliable implementation may “leak” through abstractions built over it.
These ideas were still fresh in my mind when my eyes scanned the phrase, “dead simple,” to describe an abstraction over HTTP. Spolsky had even used TCP/IP as an example in his explanation. And there it was: The very problem Hickey had pointed out. We programmers tend to conflate the notions of simplicity and ease of use.
Axion is easy to use, but it is not simple: It hides complexity, which is just what an abstraction is supposed to do. But the thing it hides – HTTP – isn’t so reliable that it remains invisible under all circumstances.
As I proceeded to work the exercise, the installation and scaffolding process further underscored the difference between simplicity and ease of use. It was easy to get everything installed and verified. The tools provide convenient scaffolding to jump-start a new project and to include various components like a linter and a test framework, and to choose from among available compilers and so forth.
But as I watched the console messages flowing by, I began to get a sense of just how much complexity was hidden under the abstraction provided by the vue and vue-cli tools. To accomplish the equivalent setup manually would definitely not be “easy,” but it would be “simple,” in the sense that it consists of a series of steps that somebody else has already figured out.
The abstractions provided by vue, vue-cli, and axios are definitely useful. They enabled me to focus on the learning objective of the exercise without getting tangled up in unfamiliar installation details. I’m grateful for the work people have put into those tools.
One point is that “simple” isn’t necessarily “easy,” and “easy” isn’t necessarily “simple.” Another is that it can be dangerous to assume an easy-to-use abstraction won’t leak. When something appears “simple” we have a tendency to assume nothing much can go wrong. An abstraction is a convenience, not a crutch. It’s wise to learn something about what’s under the covers, or it’s liable to poke through the abstraction layer unexpectedly and surprise us.