Bowers' Law
Jan 18, 2004
Iron Lute

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

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

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.


Site Links


All Posts