Look. I get it. Technology can be difficult. That difficulty is why a lot of us have jobs: we make things easier for those whose focus is the data not the stuff used to store it and manipulate it. Further complicating the inherent difficulty of technology is that it's constantly changing. So, the idea of "simplifying" seems quite attractive ...at least on the face.
If you look at my profile summary, I've been at this nonsense for a long time, now — longer if you count my pre-college and hobbyist years. To say that I've seen a lot of things come and go (and come back with new labels) would be an understatement. And, year after year, one of the things that's struck me is how often a particular technology is seen as "too complex", resulting in a "simplified" alternative or overlay being created. Ironically, and just as frequently, that simplified version of things gets (slowly and inexorably) more and more stuff bolted onto it to return the functionality that was initially sacrificed in the name of simplicity.
All of that is fine, really. What's less fine is the combined impact of all this "simplification". Maybe my use case is fairly unique: the requirements of my job means that, in the course of an arbitrary time-period, I use a number of technologies. Sometimes that usage is sequential, sometimes concurrent ...but, mostly, it's overlapping. Automation tools each seem to have their own domain-specific languages — usually a "simplification" of a more well-known language that's been optimized for the particular automation tool's primary use-cases. Similarly, every tool that is focussed on, or includes as a component, documentation services includes its own, simplified markup language.
At any rate, in isolation, each of these simplifications is fine. However, when you have to deal with a collection of overlapping and quickly evolving simplifications, you begin to ask yourself, "is having to know half a dozen partial re-implementations of a given, 'too complex' technology saving me any learning-effort vice just knowing the source technology?" At least with the source technology, I don't have to worry about idiosyncrasies and limitations created by the simplification processs. I don't have to worry, "is this escape to the underlying technology that I'm remembering correct for this simplification or one of the other simplifications I use?" I don't have to worry about how to protect layered escapes. I don't have to lament "if I was just using the underlying technology, I could do 'X' but can't with this simplified construct." I don't have to worry, "have I properly optimized this simplification's code, or have I let the other simplification's methods slip in." The list goes on.
And the problem is just freaking everywhere: customized "shells" to protect you from the unchecked power of the naked CLI; various flavors of "markdown"; domain-specific languages; etc.
Is anyone no one else running into this "problem", or am I just unique in publicly griping about it?
Top comments (0)