Paradigms / OO vs CO (was: UI, etiquette and OO phobia) [LONG]

[Chris Pressey]

Jay Nelson wrote:

> Chris Pressey:
>
> > I don't want to be misunderstood
>
> Sorry, I was trying to point out that it is possible to
> throw every assumption you have made out the
> window and think from a fresh point of view.  When
> I get stuck thinking about something, or finding the
> cause of a bug, invariably a fundamental assumption
> was violated which made the solution invisible to me.

Yes, I probably didn't appreciate that as much as I should've - I spent
a lot of time working "across paradigms" before I even encountered
Erlang, so I have a tendency to come full circle.  It's good - maybe
critical - to discard assumptions frequently, so I've tried to make it
a habit (but hopefully I've not yet taken it for granted :)

One related problem that I seem to get into because of this is that I
take terminology with a grain of salt - when things can't be discussed
in plain language, jargon (i.e. assumptions) get in the way. So when I
use words like "object", "behaviour" etc, I usually (but due to
circumstances, not always) try to use them in the most informal sense.

> I have a tendency to abuse metaphors against their
> will.  The atom / quark thing was more to say there
> are differing points of view, not necessarily a
> real way of breaking down the problem.

The metaphor is actually quite good, and I basically agree with your
suggested approach to GUI - deconstruct the problem.  A widget need be
no more than a loose collection of behaviours.  I'm actually more
concerned about a general class of implementation problems, into which
the GUI approach seems to be falling.

> > I still think that Erlang, in its honourable effort to
> > subvert OO-mania, is in danger of developing
> > OO-phobia - but that is a more general subject
> > than GUI's and I'll try to address it in a future thread.
>
> That definitely is a new topic.  I was a big OO fan
> before OO was commonly practiced.  I have a tendency to
> get bored and move on to new things and to be on
> the fringe rather than in the pack (I like to think the
> leading edge, but fringe dwellers have no global
> context for relative position).  I'm not OO-phobic but
> I am always grasping at new approaches and new
> ways of thinking, and frankly am bored with the status
> quo of UIs and programming in general.  I want to
> rattle some cages and challenge some stagnant thinking.

Good :)  The world needs more fringe dwellers.

I think the important thing to point out is: OO itself is not a
problem.  Becoming entrenched in and dogmatic about OO (or any
paradigm) is much more problematic.

I guess to illustrate my concern, it would help to contrast OO with CO
(concurrency orientation, i.e. the Erlang philosophy)


OO
--

How do we summarize this approach?
- "Everything is an object."

How do we structure an application?
- We decompose it into objects.  Each object has an explicit interface,
with which it encapsulates some internal state.

How do we organize objects?
- Into classes.

How do we extend existing code?
- We subclass objects.

How do we deal with concurrency?
- We don't.  Objects are dealt with synchronously (when an object
method is called, the caller waits until the object returns a
response.)  To overcome this, perhaps we have a thread class, and we
subclass it to make concurrent objects.


CO
--

How do we summarize this approach?
- "Everything is an process."

How do we structure an application?
- We decompose it into processes.  Each process has an explicit
interface, with which it encapsulates some internal state.

How do we organize processes?
- At runtime, we organize them in a supervision tree; but conceptually,
we don't.  Typically, we try to make each module contain a function
(e.g. "start") which creates the process (or processes) which handle
the functionality related to that module.

How do we extend existing code?
- We create more processes which delegate to/from existing processes. 
Or, if we don't care so much about reusability, we simply alter the
existing processes.

How do we deal with concurrency?
- Processes are concurrent.

How do we deal with *NON*concurrency (sequentiality)?
- If a process requires synchronization, we build a mechanism out of 2
or more asynchronous accesses (as is done in gen_server:call.)


Discussion.  These paradigms are actually quite similar, superficially
at least: applications are structured into parts which present
interfaces to other parts, behind which each part protects its own
state.  But from there they diverge on the issue of *control*: in CO,
control is distributed amongst processes - each process has "agency". 
Each process can "drive" any other process that it is aware of.  In OO
this is basically not addressed - perhaps objects are "driven" by some
"application master" object, but this is not generally specified.

Which paradigm maps naturally to the real world?  I would say neither -
although CO comes much closer, since OO doesn't address the
hard-to-dispute observation that the real world consists of diverse
power centres which, operating independently or in concert, co-operate
or compete for control of things.

But CO also falls short, since the real world is also composed of
"neutral" or "static" elements which don't have any significant
"agency" - and these are often the things which are *being* controlled
by the power centres.

Time for some examples.

Does a business have dynamic behaviour?  "Of course."  Does it have
structure?  Yes, it's composed of many entities which themselves have
dynamic behaviour (employees, customers, invoices, etc) working mostly
asynchronously, but in concert (i.e. with occasional synchronization.)

Does a building have dynamic behaviour?  "Of course not," it just
exists, inert, subject to whatever operations are applied to it by
other entities.  Does it have structure?  Yes, this is probably it's
most important aspect (ask any architect.)

Does a forklift have dynamic behaviour?  Well, sometimes.  When it's
not running, no.  When it is running, it has some dynamic behaviour,
but this is mainly for the purpose of "amplifying" the behaviour of
it's driver - but it certainly could be said to be more dynamic than
the crates it's transporting, which are basically inert.  How about its
structure?  Yes, it has one, but that's probably not of interest to you
unless you're a forklift mechanic.

How about a birthday party?  Yes, the party itself has lots of dynamic
behaviour provided by it's participants.  What about the birthday cake?
Not really (except for the candles, but they're short lived.)  What
about the presents?  No, except maybe when one of them is a wind-up
toy.  What about the invitations?  Sort of, but they're really more
like messages.  Structure of a party?  They tend to follow a general
pattern but are otherwise rather open-ended.

Etc.

What am I getting at in this lengthy analysis?  I think there's a false
dilemma between OO and CO - that there's a gap, but it could be
bridged.

How?  I'm not entirely sure yet.

But the feeling I'm getting is that there ought to be a way to deal
with objects (in the informal sense, remember) regardless of whether
they have dynamic behaviour or not.  OO doesn't address concurrency
well - it doesn't say what is granted agency and what isn't, relying on
some "Grand Orchestrator"-type object (or "mainline code" if you
prefer) to manage the application flow - while CO doesn't address
inertness well - it requires that everything be granted agency, even
things which clearly don't require it (like books and pens and fences.)

One of the more appealing ideas I've had comes from the language Inform
(http://www.inform-fiction.org/) in which virtual "interactive fiction"
worlds can be described.  In Inform, objects are basically static,
reacting only when acted upon.  But any object (up to 16 total IIRC :)
can be assigned a "daemon" which gives it behaviour independent of the
player/observer.

I think this is the germ of a good model, and that, appropriately
developed, it could fit between OO and CO.  Decompose the problem into
objects which may or may not have agency (processes.)  But the hard
part is making sure that objects can be treated the same by other
objects, regardless of whether they are dynamic or not.  I'd like to
see something more transparent than "concurrent objects" or "Erlang
with object extensions" - either of which seems to be a short-sighted
approach where features with essentially incompatible assumptions would
get slapped onto a pre-existing framework - rather than generating a
smooth & novel synthesis of the two.

Anyway, I should stop about now before I start repeating myself, and
allow myself to give it more thought...

-Chris


______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca