It's all procedural. All the way down.

Given my last few posts, it's simple enough to recognize that I'm a proponent of the advantages that object and aspect oriented development methodologies can bring to our practice of writing software well. Often my arguments could be rationally and fairly be interpreted as being anti-procedural. Actually, I think the ideals and presentation of object oriented (and subsequent clarifications and expansions) development methods are somewhat overblown and fail to recognize one very fundamental and vital fact: it's all procedural, all the way down. I could perhaps restate this saying: it's all processor operations, all the way down. I could perhaps restate this again saying: it's all transistor physics in a limited turing machine model, all the way down. It starts to get a little too abstract going so far down, no matter how valid it is to do so. The object oriented code that you may write is executed as procedural code that is generally less efficient than the alternative procedural code that you could be writing.

It's entirely reasonable to ask then, why I can say this (not a particularly fresh thought) while also advocating for some of the more modern approaches to development. Despite my nerdy leanings and loyalties, it would be disingenuous for me to assert otherwise. Here is the (obviously not secret) reason: we write software and for many of us it is a passionate and satisfying calling but it is also a profession and a position that occurs within a larger organizational context. To be good, the software or more generally, the systems (which can span far outside of the Turing machine), we create must create value in our larger human organization. Largely, this has occurred through the creation of automation and by it (or many other means) greater efficiency which has the potential of freeing up resources that would be otherwise spent, allowing them to be used for arguably lower priorities or improvement of existing services that are none the less important to address. Other provisions of value allowed by the systems we create include the increase of quality in the end products created through creating improvements in accuracy or simply freeing up the focus of those using our systems so that they can concentrate more fully on the fundamental task a user is endeavoring to accomplish and allowing them to work at a higher level and thereby possibly encounter linked concepts that they might otherwise not have been able to place in juxtaposition. Alright... enough run on sentences about why I think the work we do is important and serves a real need within our society. To get back to the subject, the context in which we engineer is one where the actual value of our software is rarely judged by the resource allocators by the sophistication, elegance, or cleanliness with which it is designed. There are some very reasonable and unfortunate situational and organizational realities that cause this to be the case but that too is a different post. There are also some very reasonable and fortunate situational and organizational realities that cause this too to be the case but that too is part of the afore mentioned different post. The point of this post is little more than to point out that while we must, as our duty and obligation, tend to the technical correctness and functional provisions of our systems and that the driver of this most appropriately is the actual value created.

By this, I will have hopefully provided enough of a context in which the following will be naturally agreeable. Our efforts naturally and rightly take place (by providing us with feedback about our actual and less subjective provisions of value) within a context of a larger picture of value. While software written using objects must take advantage of constructs like virtual tables that keep track of the relative locations data and methods or in aspect oriented approaches can add executable instructions for all affected join points and by either method these approaches are less performant or at the very least create a larger amount of instructions that may not otherwise be executed, the costs of not employing these methods can be quite high. As such, these approaches to development have gained support from those that must take on the task of finding acceptable compromises that value certain efforts over others in the very real situation of limited resources that all of our work occurs within.

This value assertion of mine is not one that is largely argued in practice and so trying to convince anyone of this would be a waste of my effort and likely a waste of your time. Instead, I would like to try and build a well reasoned case for why this is the case and how exactly it is that they provide such value. (Geez. Will he ever get to it? Why... Yes!)

The difference between well and poorly written procedural code is the same as the difference between well and poorly written object or aspect oriented code or assembly. Newer approaches like object oriented programming and newer aspect oriented programming are available strategies within a practice that I like to think of as concept oriented programming. This term has been used by at many groups I could google (conceptoriented.org, www.drdobbs.com) for different things but while they seem to have the precursors or off-shoots of what I mean, they seem to fail on the same fronts as the OOP community has: I will explain, but first want to provide a little context. The difference, as I see it between well and poorly written code of any style is effective and clear organization. Because all code in the what I believe (maybe falsely) is the Dijkstra computing architecture is fundamentally procedural (even if that procedural code supports a different code model) what is important in our code is that we have effectively separated out and independently factored the concerns it addresses in a way that clearly identifies the concerns and clearly solves them in an understandable manner. What is really important about providing such clarity and division is that it can make it supremely clear exactly where a new feature/function or modification should occur and to what extent we intend it to have effect (which should be exactly the appropriate extent and no more). The organization must formalize concepts like scope of effect and access, general practices, repeated patterns, security, and much more so that in any one location nothing but exactly the concern being addressed (and nothing more) is represented and solved at exactly the correct scope for all instances of the concern. My notion of concept oriented programming in this way is quite different than procedural/OOP/AOP practices (maybe being a meta-practice in this conceptual context), it is a style and means of using each of those tool sets and methodologies in an effective, reusable, and transferable manner as opposed to being a language feature set or anything of the sort. By effective, I mean "solves the concern"; by reusable, I mean "clearly delineates between itself and other concerns" such that in any case where the concern must be addressed the same code can address it; by transferable I mean, "clear identifies itself as a solution to a specific concern (and what that concern is) as well as being simple to identify and understand (so it actually gets both used, used correctly, and used effectively)".

Just to be a jerk: implementation is left as an exercise to you, the reader.