As I hinted at in my previous
post, this is not as easy to answer as you'd think. To give you a
hint on how hard it is, I'm currently up to my fourth major version of
my fundamental data structure. The best way to answer "What is an
outline?" is probably to take you through the same development process
I used to get to where I am now.
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
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.
This is the first public posting regarding my next major project, Iron Lute (links to
a screenshot). Iron Lute is an outliner, written in Python and using Tk as its toolkit; as a
result it should run on Mac, Linux, Windows, and anything else that supports Python and Tk.
(Off hand I don't know how many platforms that is, but it is plausible
this would work on palmtops and some other obscure ones with few
changes.) The license is currently undetermined, but will initially
be open barring surprises; more details in a forthcoming post.