Scientific Method Over Anecdotal Evidence in Technology Choices
*Note: This was originally posted as a comment on Goodbye, Object Oriented Programming*
A friend sent me your article, and I had replied to him with this, telling him what I think (he suggested I post it here, so I am):
Yeah, I’ve been thinking about this one a little bit lately. This article is a good example of the pendulum of programming paradigms swinging in the direction of functional programming. Some people think that it’s only Functional vs. Object-Oriented programming, but they have probably but dipped their toes in the pool of programming knowledge, because there are many paradigms — https://en.wikipedia.org/wiki/Comparison_of_programming_paradigms. These two are not the only programming paradigms, but the most commonly talked about I think.
Let me start with a salient political analogy — Liberalism vs Conservatism. In my mind they are two factions that are always at odds on the fundamental ‘how do we get things done’ question. On any issue, they are almost at polar opposites on how to approach the problem, or even in opposition if said issue even is a problem. They provide a bifurcation in our approaches for people to choose from. Sometimes people are one ideology or another because they’ve made the conscious choice, and then there are people who are one or another because that’s what they were brought up on and may not understand the differences between the two, they just know which one they ‘believe in’.
Programmers are not immune to this kind of upbringing. If the programmer is making a educated choice in which language to use based on it’s functional or object-oriented properties, I’ve rarely heard a valid, non-anecdotal, thought out reasoning for choosing one or the other in conversation. In a team setting, often the loudest voice, the most experienced in a particular language, chooses that language for the team or company. I’ve never seen a scientific, purposeful approach to a language choice, when that was made for a new project at a company. It is often driven by experience in one over the other, inertia in already using one at the team/company, and the operations team comfort in supporting it. If any of those fall down in making a different choice, then they fall back to the default. Even in passing programmers are passive-aggressive or standoff-ish — recently I was at the water cooler talking to someone about NodeJS, and someone getting a coffee, butted in and said, “Well, right now, I think GoLang is more compelling than NodeJS.” And they left it at that, no reasoning, no scientific data, just ‘compelling’. This also was, whether that person knew it or not a functional vs object-oriented debate they were trying to incite (nodejs — functional, golang — object oriented). I ignored them. No data backing up your claim, you get no debate, I have more important things to do.
While the tech community enjoys quibbling about this subject and any others, and they each have their voices for either side, I think we need to approach this more academically, methodically, and scientifically. See this great talk explaining some of the myths we all believe to be true (10x engineers, etc): https://vimeo.com/9270320 also calling for a more thoughtful approach to how build software, and software teams.
I don’t know the definitive answer to the question (object-oriented vs functional). I think some people would like you to believe that (1) there is a definitive answer, and (2) it can apply to any software situation. But let’s be honest, depending on what you’re doing, your choices are limited by: (1) environments — if you want to do embedded devices, you’re probably using a object oriented programming language with a compiler (2) team/company — the choice may have already been made for you (3) time — you may not have the time to really dig into a couple of choices of languages even and compare results (often these evaluations are extremely flawed anyhow).
On this subject I’m driven by these philosophies:
(1) Follow data/facts/scientific approaches, not feelings/past anecdotal data saying what is better
(2) Always keep an open mind. Try everything. Experiment with both kinds of languages in your free time; become a generalist expert, that way you know pros and cons. Neuroplasticity always wins; be a life-long learner.
(3) Don’t hold allegiance to one language/paradigm — you’re just putting yourself in a box, know computer science fundamentals that are evergreen, so no matter what language you use, you’ll be effective, and write it idiomatically.
Thanks for the article. Always interested in hearing more about Elm and others.