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.