Why Some Programmers Buck Convention
The shoes you wore for yesterday’s journey may not be fit for tomorrow’s.
People like to interpret advances in the state of the art of software development through the lens of relativism. For example, any time someone mentions the objective qualities of functional programming over OOP, there is a chance that an older peer (one who may have never excelled at either paradigm) will chime in with an anecdote about how these things are always changing, and how next year it’ll just be something different. And on and on, until five years from now we all wind up back at C (which is their preferred language anyway).
It’s a big hype circle!, they’ll say — so why bother changing at all?
My experience informs me that this attitude is a recipe for getting left behind.
Bloviation of a Relative Expert
As a relative expert in these paradigms, it is my contention that each given paradigm imposes a different practical limit upon the implementation quality of our software systems. For example, we can almost universally agree that the now-ancient paradigm of unstructured programming keeps a pretty low ceiling on the practicable quality for a non-trivial code base. Nothing limits our ability to understand large programs like GOTOs littered with thousands of global (mutable) variables.
In turn, most can appreciate how programming in the procedural paradigm raises the quality ceiling in practice. Sure, there’s still a metric ton of mutating global variables, but at least we don’t have GOTOs short-circuiting our brains.
Or do we not? If you consider that many global variables are used to dictate program flow, and how anywhere in the flow a global variable could be altered in the middle of said flow… You realize that we still have GOTOs, but rathen in an implicit form. It is a GOTO for all intents and purposes, but one that is lexically invisible! A GOTO in an even more pernicious form! But still, strictly one less problem is always an improvement…
A slightly smaller majority also appreciate how the object-oriented paradigm raises the quality ceiling further. Now we have mutable global variables, but we wrap them up in wet newspaper and call them Singletons!
Just kidding! Modern OO code bases use Singletons very rarely and GOTOs not at all. Still, OO is a major step forward from having global variables exposed everywhere and resorting to rat’s nests of function pointers when you need to invert control in your application (such as for UI programming).
But, supposing we’ve no mutable singletons in our OO code base… While we have slayed the implicit GOTO dragons borne of global variables, a similar problem remains. Amidst the pervasive mutable state found in OO programs, we discover GOTOs in yet another form! — one that is just as implicit as global variables, but with slightly better-organization. With OO, we are like a child who knows where all their possessions are — though all of currently lie on the floor.
An organized mess is still a mess.
The functional programming expert, then, is one that knows that they can raise the implementation quality ceiling even further. By eliminating or minimizing organized but mutable state, the functional paradigm successfully eliminates this last implicit form of GOTO.
The larger point is this — whether something will come along to replace the
newest paradigm is immaterial in light of the fact that said paradigm may still be enough of an improvement to justify embracing it. Relative to object-orientation, functional programming does just this.
Hold the Kool-Aid, Please
I understand why many people think the above argument is merely academic in practice. It took me nearly 10 years of object-oriented trial-and-failure to know full well where its ceiling lies. And I think one of the reasons it took me so long is that all the ‘thought-leaders’ in the software community at the time were telling everyone that the ceiling wasn’t there. Your mind may thirst for guidance, but I posit you’ll be better off discarding the OO kool-aid.
Your Peers Will Not Understand
Once you embraced the possibility of a better approach and shelved your copy of ‘Design Patterns’, you may find yourself at odds with peers who have not done so.
Remember what it was like first coding in the now widely-adopted language? I liken it to wearing a new fitted suit for the first time. It gives you a sense of power and pleasure. It might seem a little alien at first, but it quickly becomes cozy, remains surprisingly permissive, and may even generate a little buzz in the office. How could anyone not be perfectly happy in such a fine piece of attire?
But one day, perhaps after a couple years, you’ll notice something has changed. As you put on your fitted attire for the umpteenth time, you find suiting up to be rather more awkward, and the experience of wearing it far less enthralling — uncomfortable, even. It is then you suddenly realize that you’ve grown. Maybe you bought the suit as a young person, and got taller. Maybe you’ve been hitting the gym and have grown some unexpected muscle mass. Or perhaps like many of us, have taken to growing horizontally. Regardless, what was once a comfortable experience has become suffocating.
However, unlike physical appearances, it’s hard to objectively see when another programmer has outgrown their tools or paradigm. You may be intellectually busting out of your Java constraints, but no one will likely see it. They’ll more likely see some whiny programmer prattling on about discomforts that seem to bother absolutely no one else at the company.
Don’t you get paid enough to keep your head down?, your boss may wonder.
Why does he or she keep eye-rolling at my nice design pattern solution?, your peer may wonder.
Why doesn’t he or she just write code like everyone else and be a team player?, wonders the person reviewing your code.
You could try to explain, but probably no one will understand. And that’s okay. Perhaps with some subtle prodding and patient elaboration, a good team will soon join the intellectual journey with you. A not as good team presents you an opportunity to find new peers that are nearer to your current place in the programming journey. Either way, you’re going to end up a winner somewhere down the line!
With such difficult subject matter as software engineering, it’s painstaking enough to truly grow in even the most comfortable conditions. But it’s excruciating to do so when you’ve already outgrown your current attire. It is important to keep in mind, and to explain to others as possible, that your ongoing personal growth may be the primary ingredient to future-proofing your long-term viability in this ever-evolving industry.
I was addressed the following in a discussion of this article on Reddit -
“What I’d love to see is a discussion about variables that are implicit GOTOs and variables that aren’t.”
I would say a variable becomes an implicit GOTO when it is used to decide the program’s flow of control while being mutated from within the same control flow. Once you have enough variables like these, it’s no longer easy to reason about how changing it will affect your program.
This is especially pernicious in the object-oriented world because this variable could be changed from every place its containing object is referenced. Multiple implicit GOTOs often implicitly interact with each other, so even a few of them quickly make your program very hard to understand, maintain and extend.
I hope this clarifies what I mean by ‘implicit GOTO’!