[Alan Kay]
> The big idea is "messaging" -- that is what the kernal of  
Smalltalk/Squeak
> is all about (and it's something that was never quite completed in our 
> Xerox PARC phase). The Japanese have a small word -- ma -- for  
"that which
> is in between" -- perhaps the nearest English equivalent is
> "interstitial".
> The key in making great and growable systems is much more to  
design how its
> modules communicate rather than what their internal properties and 
> behaviors should be.

This is what excited me about Smalltalk when I first saw it.   
Instead of taking the notion of stringing together machine  
instructions and trying to scale that up, for example with procedure  
calls, it took the notion of module interconnectivity and  
(successfully!) scaled it down all the way to being able to model  
procedure calls and even the very fundamental operations such as  
conditionals and iteration.

To take the next steps, I think we have to apply the same principle:  
 try to find higher level concepts that can scale up to meet our  
needs and then implement them in such a fashion that they can scale  
down to completely substitute the mechanisms we use today (blue  
plane).  In addition, we should find ways to let our present tools  
scale down better in order to meet a wider variety of needs (pink  
plane).

I know of two research areas that show promise for the first goal,  
software architecture and aspect-oriented programming (an off-shoot  
of meta-object-protocol research).  The second goal


Blue plane 1: Software Architecture

The software architecture people concentrate on the large-level  
structure of systems, primarily on the 'connectors' that are used to  
connect different computational modules.  They argue that connectors  
need to become first class objects with full linguistic support so it  
becomes possible to create new connectors by composing or refining  
existing connectors.  Examples of simple connectors include procedure  
calls, messages, notifications, pipes, blackboards etc.  Complex  
connectors can include bi-directional communication protocols etc.

Sadly, their focus is very much on "legacy systems" and formal  
methods etc.  For example, there are several architectural  
description languages (ACME, RAPIDE) that allow compositions to be  
written down instead of constructed procedurally (like we have to  
do).  However, the syntax is usually sufficiently baroque that it  
isn't much of a benefit.  I wonder what a squeaky-clean approach  
would look like.

Example 1:  OO pipes and filters

One concrete pink-plane project that might give an idea of the  
blue-plane software architecture concept is objectifying the great  
UNIX pipe-and-filter architecture.  What makes this architecture so  
powerful is the simple interface (stdin,stdout) that makes  
composition a breeze, complete with a mini-language for specifying  
composites.

The problems have been use of a heavyweight connection mechanism  
(processes and IPC), byte-stream encoding and the inability to  
incrementally refineme the filter components, all of which can be  
cured with OO techniques.  The result is something that looks a  
little like a visitor pattern, but happens to be more powerful due to  
the compositional approach.

One feature that is still missing is a simple connection language  
like UNIX shell syntax.  One option for now would be to simply use  
that syntax, but a better solution would be to find a general  
language for object-composition that simplifies to something similar.

Example 2:  Protocols

It would be great to formalize Smalltalk protocols along the lines  
of Objective-C, the Strongtalk type system for Smalltalk (Java  
interfaces are also similar).  Apart from various immediate benefits  
(auto-documentation, explicit modularization, class-independent  
methods,...) , protocols could be enhanced to support the notion of  
potentially bi-directional communication between objects/subsystems,  
with the current signature-type protocols as a uni-directional  
subset.


Blue plane 2: Aspect Oriented Programming

Whereas software architecture remains on the concrete level of  
modules and interconnects, AOP  
(http://www.parc.xerox.com/spl/projects/aop/)  draws on meta-level  
concepts to try and address non-local software factorization.  The  
basic premise is that there are some features of software systems  
that cannot be easily modularized by traditional functional  
decomposition because they have global effects that are often  
sub-procedural in nature.

Their approach is to explicitly model these aspects, possibly using  
a custom language, and then create custom 'weavers' to integrate them  
into the code instead of manually weaving intricate object  
structures that achieve the same effect.  They have examples where  
this process reduced the total code by over an order of magnitude,  
even when taking the weaver itself into account!

This idea of composing sub-method chunks of code in module-size+  
entitites has also been used by the 'predator' project at the  
University of Texas.  They don't go as far into the meta level, but  
have some things worked out in greater detail.


There are quite a few more topics I'd like to cover, including more  
compositional iteration abstraction, expanding the subset(ST)->C  
idea, scripting, composition+refinement and the language/framework  
circle, but this is more than enough for one message already.

Marcel

....just an egg...