OO vs CO vs SO

[Jay Nelson]

Object Oriented programming (OO) defines a static inheritance
hierarchy, and the lifecycle of object instances that interact.  At first
blush the inheritance aspect seemed the most important thing
from a code reuse standpoint and a consistent model approach.
It seems that current attitudes support the view that cooperating
objects are more useful than inheritance hierarchies.  The whole
approach to design patterns is telling, with delegation and class
factories and all that.

Concurrent Oriented Programming (CO) seems to be a similar
approach that defines the world in terms of concurrent activities
and the encapsulation of state to make independent agents.

However, neither objects nor processes exist in a vacuum or a
fixed environment state.  The world is constantly changing and
the "agents" in the world react based on external sensors that
impinge on the internal state, potentially cause a computation
and a reaction that is broadcast to the external world.  To me
the most interesting thing is the interaction of all the agents,
not the modeling of individual agents.

When individual objects, or agent processes, are the focus,
the difficult complexity of interaction is ignored in favor of the
easier modeling problem.  It becomes difficult to think of things
on a larger scale.  I find imperative programming restricts me
to thinking in terms of the current case, or cases one at a time.
The functional approach allows me to think inductively, or
recursively, and to apply code to broader situations, so that I
instinctively think of whole sets rather than single cases. (Once
a "case ... of" function is written, I think of it as a magic handler
of all the known cases and can now consider herds of data at
once.)

I think Stream Oriented Programming (SO) is an alternative that
erlang allows, which is harder to consider in other languages.
Rather than breaking a system down into real-world components,
or logical pieces, consider mass data flows and their implications.
This allows top down design, overall system architecture prior to
worrying about algorithmic details and high-level discussion with
others of the behaviour of the system, the problem space (rather
than an instance of the problem space) and topologically equivalent
solutions to consider as alternatives.  Approaching a problem this
way allows a much more reasonable answer to questions about
failure, liveness, dynamics and appropriate system behaviour under
the panoply of situations that it will encounter.

jay