[Squeakfoundation]Image Builder

[Paul Fernhout]

danielv@netvision.net.il wrote:
> 
> That's what many people want. The problem is that without modularity,
> there's no way to make the pieces work independently. Remove Celeste,
> and the TheWorldMenu does a walkback. StableSqueak and the Modularity
> work in 3.3a both address the same problem.
> 
> Daniel

I very much agree.

However, [and maybe this should move to SqueakDev, except as it impacts
Foundation priorities -- although I'm unsubscribed there] I think one
deep issue is a deep conceptual flaw in thinking about Smalltalk
"objects". This was discussed about two years ago on SqueakDev. 
Essentially, Alan Kay historically presents the "object" as a small
computer which responds to input and outputs using a hidden state. This
object lives in a world of other objects (or computers) which it
communicates with. There is nothing wrong with this -- it is a fine
metaphor and is very useful and leads to the notion of a live image --
which is a world of objects which communicate with each other (and the
best software development environment on earth -- Squeak :-)

Where this notion breaks down is the intent (or meaning) behind the
messages or sequences of messages objects send each other, as implied by
the desired effect accomplished by sending a message, depends very much
on the specific ecology of other objects which an object sending a
message lives in. So, meaning emerges out of the specific collection of
communicating objects, not just from one object and its intent in
sending one message. 

Classically, many other languages like C have fairly large modules
(often, essentially files) which are sort of collections of functions
(or objects) which sometimes work well together to define a well defined
interface which the developer takes pains to preserve -- but these
modules are much larger than a typical Smalltalk object (say, 1000s of
lines instead of 10s). The interfaces to these larger modules are slower
to change than the interface to a typical Smalltalk object, and often
the interior objects and data structures just can't be accessed. The
interdependencies between these C-ish modules are also perhaps slower to
change, and changes within a module are usually done behind the scenes
by a single developer at a time, who may be aware of some of these
brittleness issues. Smalltalk historically lacks this extra layer of
decoupling (or perhaps what could be called modularity). Further, most
proposals to add decoupling or modularity (for example ENVY, which loads
modules called applications atomically) do not address this entire issue
because, for the most part, Smalltalk style permits object to object
communication across modules, which rapidly breaks down clear interfaces
between modules, reducing the firewall value of an extra hierarchical
layer of modules.

Real world ecologies -- like a collection of bacteria souring milk --
tend to have a large number of organisms (objects) which step in at
appropriate times and are each way more complex than a typical 10s of
lines Smalltalk class. Also, if the system gets stuck at any one state
(for the absence of some bacteria that can breakdown another's waste
product) no one minds and the system just stays there until an
appropriate organisms shows up through chance. In this sense, real world
organisms are closer to the large modules mentioned above as opposed to
Smalltalk classes, and the overall systems also have to meet lower
expectations about performance.

As a consequence of all this, images tend to need specific versions of
objects to achieve the designers purpose. Any changes to any of the
objects tends to produce unexpected brittleness in the image. So, the
image as a whole ends up evolving. This makes it hard to subdivide the
image into submodules, since with objects talking across module
boundaries, the brittleness will quickly return even when one
modularizes. I think this is one reason some people have historically
resisted modularity or building an image from scratch as opposed to
evolving it towards a dedicated purpose. But, while a useful strategy,
this does not directly address the deep issue of managing emergent
meaning in a modular way.

I think this is a deep issue in the design of Smalltalk, and I don't
have an easy answer for resolving it. One approach is essentially for
images to talk to each other using well defined protocols (such as via
email) within one operating system or across networks. Another
resolution might be to (within a "meta-image") have objects (or small
mini-images) nest within other objects hierarchically, where nested
objects look like regular objects. That is somewhat easily accomplished
using Smalltalk within a single image, but in practice over time the
interior objects are communicated with directly by other objects outside
the enclosing object, reintroducing brittle dependencies. Namespaces
help a little with avoiding name and intent collisions regarding
specific classes, but they don't resolve the brittleness through
excessive across boundary coupling problem. What these enclosing object
need is something like a "cell membrane" that prevents the interior
objects from establishing close couplings with objects outside the cell
membrane. Yet, that brings up solutions people glorify in C++ (friends,
protected members etc.) which I think people often justifiably reject.
Perhaps what I want to see is many mini-cell-like-images within an image
each performing a well defined function, and duplication of class
definitions in prototypes within each image a more Self like way, but
with cell membrane firewalls routing messages between such cells made of
prototypes. But then someone might try to start shipping flattened
objects across these cell membranes which might refer to prototypes in
another cell to defeat this (unless unflattening references to objects
within other cells were disallowed). So it's a complex issue.   

Essentially, to summarize, in order to further promote the evolution of
meaning in Smaltlalk, I think Smalltalk needs a notion of a "cell" of
objects, where objects within a cell can only send messages to other
objects in the same cell or to the cell itself, and can only reference
other objects in the cell or the cell itself. Probably this also implies
moving to a more prototypish system, or at least, class definitions need
to be cell specific. (As a plus, the cell can be garbage collected as an
entire entity, if all its internal objects are stored in the same are of
memory).

Given the above, an ImageBuilder would load "cells" (mini-images) made
of specific prototypes/classes into an "ecology" (meta-image). Some
cells or versions of cells wouldn't get along with each other, but
that's life, and the ImageBuilder could know something about that if it
knew something about the person's intent in doing the image composition.

That's one of the reasons for my lessened involvement in Squeak (and the
Squeak Foundation); I don't see the big way forward to just patch Squeak
or to focus on making VisualWorks-lite, which seems to be the main
thrust here.

With all that said, clearly modules as currently pursued will be a big
improvement for the reasons Daniel mentions.

ObFoundation: While I don't know how legitimate these people are, the
National Heritage Foundation 
  http://www.nhf.org/
(which is not the same as the conservative Heritage Foundation) lets a
single individual create a public tax exempt foundation for a few
hundred dollars in a week or so. They use a sort of cellular model, with
these subfoundations being underneath the main foundation. Problem is,
they might own copyrights and trademarks and equipment and I don't know
how the liability issues (say for a patent lawsuit) would work out. I
came across it as I was fishing around for an easy foundation forming
process because I've decided I want to do my free software and free
content work as an (unpaid?) employee of a foundation or other
non-profit to minimize personal liability for unintentionally infringing
software patents, being an ISP supporting a CVS repository or such which
others might post infringing stuff to without my knowledge, being
challenged on "fair use", etc. But I'll probably have to go the whole
nine yards and make one to be on the safe side. Some links about how
Apache Foundation did it are here:
  http://www.apache.org/foundation/records/
  
-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com