OOMP: (Programmer) Religion

By | October 13, 2025

In almost every field, people will grab onto some belief without any (rational) reason. Programmers often act and seem to believe that they are actually rational people and would not hold an irrational belief (at least where our field is concerned). When you look at your fellow developers, you can usually spot counter-examples.

Like many more experienced developers, I hold with a different belief.

There is No One, True Way

  • Not language
  • Not paradigm
  • Not brace/indenting style
  • Not editor

For any case you can imagine there is a situation or group of people for which your obvious choice is sub-optimal. This doesn’t necessarily imply that every possible choice is equally reasonable. It just means that none of these is right in every circumstance.

Language

Most of the people who argue for one language for every use case either only have experience in one language or learned the wrong lesson from the fact that almost any problem that can be solved in one general purpose programming languages can also be solved in any other.

Although any program can be expressed in any language, that does not mean that the expression is equally easy in all languages. Some languages make some kinds of problems easier to solve, at the cost of being more awkward in other cases.

Paradigm

Like language, it is usually possible to express any program in terms of any particular paradigm. But, not all paradigms fit all problems. Object oriented programming works very well in some domains. It also has a tendency to help manage complexity in large programs. Unfortunately, it also tends to make large programs larger through adding abstractions that may not always be necessary.

Some smaller problems are much easier to represent in a purely procedural style, without the overhead of a number of abstractions. The functional paradigm is a relatively new darling, that failed to gain traction a few decades ago because the hardware could not keep up with the implementations of the time.

Many programs benefit from combining paradigms maybe a small number of relatively simple objects processed in a functional style may fit your problem.

Programming Style

I once got into a really heavy argument with another senior programmer about C brace style and after some time, I suddenly realized that he was literally seeing the code differently than I did. I find it easier to see blocks if the opening and closing brace are vertically aligned. He just noticed the first character in the column. This wasn’t really a choice either of us made, it’s just how each of our brains matches patterns. We could actually work with the other style, but they required thinking about the style, not just recognizing it.

It’s very likely that whatever style you first learned is more likely to look right to you. Or there may be a pattern that just makes sense. (My earliest programming was not in a language with braces, so it’s more the pattern than habit.)

Editor

Although you will sometimes still hear people arguing vi vs emacs, that’s mostly at the level of joking. There was a time when it was a serious cause for debate, but that is long over. Now, you will run across the “programmer editor” vs “IDE” debate more often. Or maybe you have a particular editor that you believe is the best thing ever.

The reality is that the editor you use for writing code is a pretty personal tool. The interface is the result of a large number of trade-offs and decisions on the part of the author (or team of maintainers). For the editor you prefer, those decisions match the way your mind works. The decisions for other editors don’t measure up.

Different Things Work for Different People

Different people, in different circumstances, working on different kinds of problems, in different environments will definitely make different choices. Some of those choices will result from an agreement in the company or within your team: language, paradigm, style. Others, like your editor, debugger, or terminal layout, may only affect you.

Be prepared to adjust to work together with your team. And remember, that what seems obvious to you, may not match with the rest of your team.

Leave a Reply

Your email address will not be published. Required fields are marked *