Bowers' Law

I've been writing ahead on my promised developer travelogue posts, because I am trying to make them high quality posts useful for programmers both new and old, not just off-the-cuff reportings of what I happened to be doing last night.

I was concerned about the time lost writing these posts, because as I said, time spent writing is time not spent coding. (Though I'm getting much of the writing done when coding is not possible.) An entirely unexpected benefit has accrued, though: I was factoring out a concept from the next two posts and it has prompted a nearly complete re-conceptualization of how the dominant programming paradigms of our day inter-relate.

First, read my post about my immodestly-named Bowers' Law if this sounds like an interesting thing to read about. (If it doesn't, you can stop reading this post entirely.

Now, while it doesn't fit into that essay exactly, I've been completely re-formulating the dominant methodologies of the day into a new synthesis. Paradigm debates are generally framed as "Object Orientation" vs. "Function" vs. "Imperative/Procedural" vs. others. Graphically you can envision them as entirely seperate blobs.

I've been reforming my understanding to be based on the idea that Encapsulation (with my particular definition) is the foundation upon which all other good programming techniques are built. Those programming paradigms that reject it, stereotypical procedural programming ("spaghetti code"), are the useless programs of the past that hit hard limits on their extensibility.

What you put on top of that is modular and can be mixed and matched between programs, between modules, even between objects in the same system. Whether you put Polymorphism, Inheritence, Multiple Inheritence, Prototype-based Programming, or a variety of other paradigms in various combinations on top is unimportent except in a particular problem's context. There is no "One True OO", there's just a collection of techniques that have their time and place. Many now-marginal techniques can be fit into this understanding without breaking anything or denying their usefulness.

I know this seems so simple, but the evidence that few people are seeing it this way is abundent. Certainly this flash of comprehension has significantly affected how I look at programming, so perhaps it can help others as well.

I hope this can move forward a more productive debate with less concerns about how "OO" something is, and with more concern for a given paradigm's usefulness on various engineering scales. "Paradigm purity" is not an intrinsically valuable thing; it is often valuable but it must justify its existence with real benefits for the cost. I think the real world already abundently demonstrates that a mixture of them is always going to be with us.

Side note: The essay was not written in Iron Lute, but the conversion from text to OPML for import into Radio Userland was.