connecting with my inner weasel
aaronl: let's say you are a normal unix user. you use the
contents of /usr/bin as your verbs, files and file
descriptors as your nouns, and a shell language as your set
of connectives. you follow the "unix philosophy": make big
things out of little things. lots of us are happy with this
language.
now one day you decide (some people do not decide, but lets
say you do) that you're a little sick of invoking programs
with "flags", especially big programs, and you really want
to have already-running programs interact with one another
in the same way the typical shell pipeline does. hm. that's
a little harder. you'll probably write a special purpose
FIFO-based wire protocol for your particular case and leave
it at that. but then as it's clear, you'll wind up making n!
wire protocols for n programs to interoperate. suckage.
so, you decide to make your program's essential services
into a library, so that rather than having program
A talk to program B, one of them will just "swallow up" the
other's functionality, and be able to call "itself" directly
through C linking. Or python module loading. Or perl module
loading. Or C++ linking. Or lisp module linking. hm.
suckage. these things can't link with one another.
so, you decide to make SWIG, which can generare module
loaders for anything in anything else. there, goddamn it,
now I can load my modules in peace! a perl script can load
up a bunch of C .so's and execute them. unless the module
implements persistent objects with identity. or objects on
other hosts. or objects with existing data. hm. suckage.
you're limited to the scope and lifetime of a single
process. beyond that you're back down to pipes and sockets.
so, you invent CORBA, in which anything can talk to anything
else, regardless of implementation language, host, lifetime,
etc. you can refer to dead objects and re-create them. you
can call methods statically (compiler checked, like a
library), you can call them dynamically (string tokenized,
like a shell). everything's perfect! except you can't tell
how to start objects, or query their capabilities, or name
them, or disconnect them when they're done, or discuss basic
protocol issues like who is going to embed whom. hm.
suckage. looks good on paper, but lacks some infrastructure
to hold it together.
so, you invent a set of component interfaces everyone must
agree to support in CORBA. bonobo, say. hurrah! everything's
solved! yip yip yip!
I too "have a problem" with components, and it is this: all
the time is being spent on making
mechanisms for finding and activating new nouns and
verbs. once they exist, they tend to just get plopped into a
"component bucket" application, wired together (manually) to
make the application do what it's supposed to, and forgotten
about. the task of finding new linguistic connectives is
generally ignored. consider some domain specific languages
developed in higher order languages like haskell.. they have
really powerful connectives, well crafted to seemlessly
"make bigger things out of smaller things" with a single
statement. like the "|" connective accomplishes a reasonably
rich set of "dup2, dup2, close, close, fork, exec"
statements in a single character, higher order connectives
can blend one "behaviour" into another, one "music" into
another, one "animation" into another. now consider the
connectives holding component-architecture programs
(mozilla, nautilus, evolution) together: subobject
activation and embedding, for loops, bulk data transfer,
reference-to-data transfer, and hand crafted method calls.
the trouble with making a clean and useable connective is
that it requires strict adherence to interfaces, and
interfaces with good enough design to be connected together.
in the current landscape of CORBA componentware, people tend
to "just keep adding methods" to single objects, often
critical ones, where they should be developing connectives
and subobjects obeying regular, well designed, readily
combinable interfaces. patterns of
composition are way more powerful than just "my thing can
see your thing". this is what sets fresco's interfaces apart
from other uses of CORBA: its primitives, connectives and
decorators are chosen to construct self-laying out,
event-handling, MVC behavioural composites out of
sub-objects in a natural way. designing those interfaces was
clearly a hell of a lot of work, and they still don't do
everything you'd want them to. but they're a far cry better
than what other people are using CORBA for.
I'm afraid in 5 more years, programming will truly have
regressed to for loops in ECMAscript. and that will be very
sad.