Thoughts about programming paradigms
Yesterday our CEO confronted me with his idea of solving search engine troubles. Hope he's not angry to be cited: "Maybe my idea of solving this comes from a more procedural point of view". This made me think a bit about object-orientation and procedural programming. My first idea was: There's no task in this world where procedural paradigm is better. But when thinking of the project I did and the software I wrote I shifted to a more willing to compromise position.
Like explained in my (not finished/not public) article "The philosophy of a programmer" my basic idea of technical programming is the manipulation of information, which is in most cases the duplication of information. The information I talk about is often referred to as data, while the underlying structure - presenting, manipulating, extracting - the data might be referred to as functional objects. These parse or process the data and also generate outputs (but do not necessarily, don't mix this up).
Premise A : Programming means manipulation of data.
So we have a structure (the controller in MVC model), the data (model) and view - which will become important here. I think there cannot be argued about, that the controlling core of each result of programming is best to be written following the object orientated paradigm, because it will in the best case never get in touch with data, so wouldn't need to know which of what kind of data is to be processed. Otherwise the core cannot be reusable in every given situation and thus would betray the virtue of reusability.
Premise B : Reusability is a virtue
and
Premise C : can only be achieved, iff the controlling entitiy does not know what kind of data is manipulated.
This leads to the simple conclusion, that only object-orientated paradigm can comply with.
But there's more to it. As stated above we still have a view in the MVC model. And at least most software (which is the typical product of programming work done) has at least some parts, that require interaction with a user, and thus a User-Interface (UI). Reaching this point, the software will have to display information or react on arbitrary information. The data that comes into play here is well defined (might even have to be for security reasons when we look at web-apps) and thus named, type-defined and underlying specific rules. Let's use an example from maths here to clarify things:
Take a formula as simple as
x + y = z
The parts highlighted here are syntactic rules, that apply all over, with no difference if x is 4 or x is 1.5 or x is 1/2. The data won't influence the model, we're talking about the core.
But If we change x's contents from f.e. 4 to 4/2 or 4², the rules for handling our variables change. we will need to know certain rules to complete the calculation (f.e. that 4/2 is 2 and 4² is 16). Maybe my example is a bit lame, since these are also syntactic rules which might not be called "more specific" by a mathematician. But I think you get the point. A better example might be if you insert needed computations for the variables, like in a geographical search engine. One might accept, that the algorithm to calculate distances between latitude/longitude value pairs are not core functions anymore (at least not as core-close as a string function like PHPs substr).
At this point we know that,
Premise D : Adding an UI will force usage of non-core components
and
Premise E : these components cannot be OOP if we assumed {A,B,C} are right.
Now we can start to argue which paradigm is best to use from here on. We can use objects for the last mentions algorithm, too, maybe ones that extend the Maths object. But at some point (and that is the case in all projects I did) the UI requires you to write "dirty" functions, that are not encapsulated and reusable And even code that isn't structured in functions at all. At least one line of code will not be a object defining code, which is the code that initialized the object.
In reality there's much more than this line. Small snippets of code that observe different input-valves (in HTTP we have GET and POST as examples), an access layer for databases always contains database specific informations (at least a hostname or address) and so on.
The poor reality shows: we cannot even use a paradigm, looser than the OO-paradigm, like the procedural one for everything needed at this point. If we manage to halfway-encapsulate every code by defining it in functions, we still need function calls outside functions (at least one again), which react.
Returning to the HTTP example, we can imagine one function that is always called which checks the mentions valves for input and delegates further work to other functions and so on. But does it make sense to have a function like the following:
function checkInput() {
if ($_GET["login"]) {
react('login');
} elseif ($_GET["logout"]) {
react('logout');
} else {
//...
}
}
How flexible and thus maintainable would such a system be?
Since this log entry is calls "Thoughts about..." I'll leave the answers to the question which paradigm is now best to the reader. But I'll be glad to read your thoughts in the comments.
RSS
