One of the best ways to increase understanding of a topic is to contrast ideas and approaches to a topic. To draw a contrast, one gives a name to the two approaches. This way, they can discuss the likely result of the two approaches.
When drawing a contrast, one wants to highlight differences between the items in focus so that we can better understand the difference between the two approaches.
An analogy can be found in photography. Photographers often shine lights on objects to make the object stand out. Photographers shine strong lights when they want stark contrast and diffused lights when they want soft contrast.
The fact that a photographer is shining a light on an object to take its picture does not mean that the object is the only object in the universe.
There is an unlimited number of ideas in the world meaning that there is an unlimited number of constrasts that we can draw. Even worse, there is an unlimited number of filters that we can shine on objects when we draw our contrasts.
When we are trying to draw a contrast, there is a natural tendency to present the contrast as fundamental. Again, lets imagine a wildlife photographer taking a picture of a bird in a park. Teh photographer will position the camera to ignore the telephone poles and playground equipment in the park to take a picture of the bird.
The fact that the photographer focused on the bird does not mean the playground equipment doesn't exist.
There is a great deal that we can learn by contrasting ideas. It is a mistake to treat the contrasts we draw as fundamental dichotomy.
So, I started to write a blog post about two different approaches to programming. I've hesitated to publish the post because some Nimrod out that would probably take my constrast as a fundamental dichotomy, when I am simply trying to contrast the result of different approaches to programming.
In general, I find that the process of contrasting ideas to be enlightening as the contrast helps us understand the different results from different ideas. When drawing contrasts it is helpful to shine a sharp light on the contrast. Unfortunately, when people take the sharp contrast we draw as a dichotomy, the contrast itself often become a negative, for the dichotomy causes us to lose sight of other ideas.
In my article I sought to contrast two approaches to programming: In the first approach, the programmer considers the format of the program to be of primary concern.
In the second approach, the programmer considers the data produced by the program to be of primary importance and the format of the program to be secondary.
One would suspect that concentrating on the form of the program would produce the best program.
My personal experience is that I create better programs when I concentrate on the data produced by the program than on the form of the program.
The reason for this is that the data becomes an objective measure for the quality of the form of the program.
The idea that I wish to state is that a data-centric approach to programming often produces a better result than approaches that focus primarily on the form of the program.
The reason that I want to draw this contrast is that I believe that many object oriented programmers have become too focused on the form of their programs. The end result of this obsession about form is software bloat.
NOTE: I recently bought a new laptop computer to replace my ten year old laptop computer. Although the new computer has substantially more resources and runs faster, the new software has become so bloated that the new computer is slower than the old one.
Anyway, I wish to write a series of articles that state that a good way to address the bloat of software is for programmers to concentrate more on the data produced by the software and a bit less on the form of the software.
The challenge in writing these articles is that I do not wish people to take my discussion of contrast to imply that there is some sort of fundamental dichotomy between the data centered and object oriented programming.