> I was talking about this topic to a friend (the most impressive  
Smalltalker
> I know), and his response made me think.  He said:
>
> 	Anybody can learn to write a one page program.
> 	A ten page program.... that's harder.
> 	A hundred page program...

So what we have to do is figure out a way to make programs that are  
no larger than one page!

The 'Uniform Metaphor' principle (outlined for example in the  
'Design Principles Behind Smalltalk' Byte article -- side note: the  
article is surrounded by ads for Apple II, Atari 800 and Color  
Computer peripherals :-) is probably the clue for making this work.   
I especially like the part "...large applications are viewed the same  
way as the fundamental units from which the system is built".  This  
is an admirable goal, but no unifying metaphor seems to have  
delivered it so far.

We basically have two mechanism for creating new structures out of  
existing objects, we can 'statically' refine a class by subclassing,  
or we can dynamically compose objects.

Two things are odd.  First is the asymmetry between static  
refinement and dynamic composition: we can't compose classes and we  
can't really dynamically refine objects.  Multiple inheritance and  
mixins are more or less successful attempts to address the first  
issue, aspects might takes us event further.  The second is addressed  
by prototype languages and can be side-stepped in a fully dynamic  
languages such as Smalltalk.

The second , although refining classes yields classes that can be  
refined further and whose objects can be composed, dynamic object  
compositions are not really accessible by our languages for further  
manipulations as a whole.  This is where the Uniform Metaphor  
principle breaks down for OO:  Object composites are not objects and  
we have no really integrated way of dealing with them!

It is probably those people who can manipulate these dynamic  
structures in their head even without the appropriate language  
support that make good object-oriented designers.  The pattern  
movement is about describing some of these (smaller scale) structures  
in ways that make them accessible.

Making these structures accessible for direct manipulation seems to  
be essential for further progress at this point.  A look at domain  
specific frameworks and languages may provide a clue to how we can  
accomplish this.

Larger scale frameworks, especially domain-specific frameworks often  
consist of a variety of different objects that can be combined  
according to framework-specific rules.  In effect, they are languages  
with different parts of speech (the different class-trees),  
different words to fit each part of speech (usually subclasses of the  
framework-provided base classes) and a grammar for forming sentences  
(object  composites).

Not surprisingly, there is a strong correlation between  
domain-specific frameworks and domain-specific languages.  Domain  
specific frameworks have often replaced domain-specific languages as  
more flexible alternatives, but domain-specific frameworks have also  
been complemented by domain-specific languages to be used by domain  
experts / programming laypeople (scripting etc.).

The problem with domain-specific languages is that they are usually  
very limited (for 'ease of use' and because their one-off nature  
doesn't allow expending the effort to make them more general), and in  
the context of refinement/composition they only allow the  
construction of sentences with the words (objects/classes) already  
pre-defined, so if you need something slightly different you're  
absolutely hosed.  I think anybody who has had the joy of trying to  
program something in a 4-GL that was slightly different from the  
optimized standard use knows what the #$%! I'm talking about.

The source-language with the frameworks on the other hand allows the  
definition of new 'words' (usually by subclassing existing classes)  
and also has much more powerful general programming facilities  
available (control-structures, other libraries etc.).  However, here  
the domain-specific language stays implicit and thus difficult to  
manipulate, essentially impossible for most domain experts.

So, one way of improving the situation might be turning the source  
language capable of serving as a domain-specific (scripting)  
language.  Making this happen requires framework writers to think  
hard about re-integrating their new components back into the base  
language.  It also means making the base-language flexible enough to  
let new components play well with the other core language elements.

Smalltalk's flexible syntax seems like a very suitable base.  For  
example, I have experimented with making collection/iterator  
operations play along better with the 'core' syntax than the block  
mechanism does (in my opinion).  The same method can be extended to  
create a Smalltalk query language mechanism that can be made to  
interoperate with SQL or other query systems without breaking out of  
Smalltalk syntax.

Still, the current system is probably not enough.  As stated above,  
object-composites are not easy to specify, we either have to find  
ways of expressing object-composites as composite messages (sort of  
the approach I take in the example above) or find a better way of  
expressing object compositions.

There are probably many other pieces of the puzzle (reducing  
cognitive load using interfaces, 'sub-frameworking' and compositions,  
separating messaging into abstract operations and 'delivery' with  
various delivery methods, etc.), but I think this has been enough  
rambling for one post.

Marcel