Throughout our lives we rely on the technological designs of others. From baby formulas and clothing to transportation and education the world we live in is an extraordinary mashup of legacy and new technology. For the majority of tech we use, it’s a process of adopting some one else’s standards. We treat the majority of our world as a black box.
This is no different in the space of software. In fact due to complexity of organization we have an ever growing reliance on layers of software that we don’t understand which knowingly or not inflict constraints on derivative work. We’re constantly exploring other group’s thought systems and mental constructs in order to accomplish tasks. And based on time restrictions we are forced in many cases to adopt “techno religions” without spending sufficient time understanding the nuances of previous design decisions.
c++ is killing me softly
In my work life as an engineer I’ve coded and recoded many thousands of lines of software, the majority of which is written in c++. I struggle to maintain consistency between several engineers working with the same source, and git has recently become a helpful tool for that task (if I can only get them to embrace it).
We are often stuck writing throw away customized interfaces and massaging data to conform to legacy software. I categorize this activity as painfully tedious. But this work’s pain was only exasperated by needless restrictions and complications of the c++ language. On a regular basis I come to the conclusion that the folks in charge of designing the language standard don’t use it for real problems.
The standard libraries for all their utility and potential processing speed are an obvious product of group think and feature bloat.
What’s wrong with c++:
- The standard is hundreds of pages long and chock full of surprises and exceptions
- The abstraction of the language is mired in a swamp of backwards compatibility with ill thought component libraries
- Looking through those libraries source code exposes a cacophony of arcane bloated syntax with splashes of needless complexity to interpret objects and compile down to assembly. No offense to the poor ladies and gents who manage the libraries, they are doing the best they can in a bad situtation
- Confining structures to heirarchies of static types introduces a level of syntactical weight and complexity in exchange for a first order level of testing and in many cases a minor boost in implementation speed. It is not a fair exchange in my opinion, the casualty is the inhibition of developer clarity and creativity
The root of this design disaster may be assembly or it may be group think, or the dreaded feature bloat. C++ may be the perfect language for some developers but I can’t count myself among them. Still with many years of sunk costs, I’m bound to it as an unwilling servant (in my day job). Over time as a painter is affected by their brush and canvas, my thinking has been bent in ways I wasn’t capable of seeing until I explored other programming languages. It causes me to wonder at how deeply our native spoken language influences the way we think (another great reason for continually learning new languages be they software or spoken).
Refactor Technology to Best Fit Your Imagination’s Need
It’s clear I have very strong biases for certain styles of software development tools, but there’s a general principle beneath the frustration.
To unleash our most creative abilities, we must master our tools. We must make them our own. Only by crafting tools that are an extension of ourselves and the way we think, can we realize the depth of what we’re capable of
At the very least we should make a regular effort to experiment with tools that better harmonize and amplify our personal style of thinking.
