Marcel --

These are just the kinds of directions I was hoping to catalyse. Long ago
we used to say: find the hardest and most important things you need to do,
solve them, and then find ways to get everything else out of them. Please
keep on thinking and writing about these ideas ...

Cheers,

Alan

------

At 2:01 PM -0000 10/13/98, Marcel Weiher wrote:
>[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...