Musing about Smalltalk

Paul Fernhout pdfernhout at kurtz-fernhout.com
Wed Sep 13 11:53:24 UTC 2000


Alan-

First, I really like Smalltalk for many reasons. Kevin has a great point
I agree with about how Smalltalk is easier to learn and also to come
back to.

Second, I agree with your point, and it is an issue Smalltalk needs to
address if it is to proceed to whatever its future is. 

I see three aspects related to your point, the last closest to the
question you raise.

=== making smalltalk applications from the user perspective ===

One tangential aspect of your point relates to what the user experiences
as a Smalltalk application. It reminds me of a part of your article in
"History of Programming Languages" Bergin/Gibson where you mention
building a simulation environment for a demo to Xerox executives which
hides Smalltalk's error messages and programming environment so the
executives in an hour or two were learning to program (as it were) at a
higher application specific level. It also reminds me of LearningWorks,
where the debugger was modified to hide complexity of the system and
allow novices to work specifically with say a square on the screen named
for example "Fred", with error messages about "does not understand" or
such elevated to a higher level where the new user could more easily
understood what went wrong. 
To me, both these examples are somehow related (though not directly)
with this issue of how does one work with Smalltalk in an application
oriented way -- and what tools does one need to make this easy. However,
in this case, this is tangential because these would be tools more about
the end user than for the Smalltalk developer (even though the developer
is using these tools to make a pleasant user experience). 

This is one of the problems I have with Morphic as a development tool
(as I've said before) -- it assumes the end user is a Smalltalk (or
script) programmer. It doesn't encapsulate these issues (into probably
some set of permissions and changeability and version control etc.). I
like the direct manipulation aspect of Morphic, and the Self-like ideas,
it is just some aspects of the implementation and this specific design
intent that I think need to take it from good to spectacular.

=== communicating with smalltalk subsystems at the object level ===

A somewhat more core aspect of your point I see as a deep issue in the
Smalltalk world view.  How can a programmer deal with concepts which
emerge from the interactions of many objects? This also relates to a
previous post on the notion that a Smalltalk object can not stand alone
-- its meaning emerges out of its interaction with specific versions of
other objects (including classes). 

The design pattern of a "Facade" gets at this to an extent -- from
Gamma/Design Pattern: "Facade ... Intent: Provide a unified interface to
a set of interfaces in a subsystem. Facade defines a higher level
interface that makes the subsystem easier to use. Motivation:
Structuring a system into subsystems helps reduce complexity. A common
design goal is to minimize the communication and dependency between
subsystems. One way to achieve this goal is to use a facade object that
provides a single, simplified interface to the more general facilities
of the a subsystem". They go onto give an example of a compiler class
providing a facade for all the parse node related classes. However,
Facades while useful don't quite get at the full issue of modularity. It
addresses an issue of interface, although it breaks down a bit once the
user needs to reference internal components behind the Facade (such as
when you need to examine parse nodes for doing a translation task). 

I think there is a deep issue here related to intent and multiple
perspectives on a sets of objects, but it is still hazy in my mind.

To make this issue more specific (still not covering it entirely), I
sometimes think of this in terms of memory management and efficient
garbage collection. You could imagine allocating say 8000K to a
compiler, and let it compile away without GC, keeping all its results in
that area of memory. Then when it is done you could just reclaim that
entire area of memory. That is sort of what happens for example if you
forked a C compiler in a separate process under the Mac with a memory
limit (although of course a C compiler will undoubtedly do some internal
equivalent of memory mangement -- though often C programs neglect
cleanup, assuming all memory is reclaimed on exit). 

Unfortunately, if you are working in Smalltalk with the compiler in the
same VM, and you have acquired a parse node through the facade, you
can't do GC this way. I think this points at a modularity issue in
Smalltalk. I'm not saying one can't solve it within Smalltalk as is (say
by copying objects removed through the facade) -- just that I see this
as an issue current Smalltalk implementations don't address, given the
idea of an image a sea of similar objects with no clear sub-boundaries. 
One could always start up a new VM and image to do a compilation task,
and communicate with it somehow (files, pipes, sockets, etc.), and then
close down the remote image without GC at the conclusion, but part of my
point is this functionality might perhaps be integrated into a single
image and VM.

== creating smalltalk modules ====

This aspect is closest to what you raise. It relates to the management
of complexity for the module developer and inside the VM itself.

I see three subaspects. 

Modularity and Namespaces

One aspect could best be understood by considering Python. While I
prefer the Smalltalk syntax for OO, I think Python has a few interesting
ideas in the area of modularity relating to modularity namespaces. These
are:  
1) It is easy to identify a module as a file. I'm not arguing for files
in Smalltalk, just that Python has clearer module boundaries. This
sometimes makes searching for related code easier.
2) Importing into a namespace is explicit. So, you know exactly what
resources should be available in a module.
3) In the latest Python design, you can change the name of a module on
import. This would be like for example importing OrderedCollection as
"MyList". The utility of doing this is if you have two classes named
"OrderedCollection" from two different developers you need to use.

Versions

Dealing with multiple versions of classes is another subaspect, and it
is a big unaddressed issue in Python and Smalltalk. Python, while
somewhat prototype like (like Self) does not deal that well with the
issue of "versions" of a class -- specifically you can't easily say "use
OrderedCollection version ak 2000-09-13-10:15". But then, neither does
Smalltalk. Python can however load newer versions of modules, and it
leaves the old instances pointign to the old class. I'm not saying I
like this -- just that it does to an effect represent Python handling
multiple class versions. Self handles this better in a way because a
prototype could be considered to be a specific version, but if you are
going to save and reload prototypes in a persistent way, then versioning
might is an issue (when you load an earlier version of a prototype from
one place and then a later version from another place).

Worlds within the Image

Another subaspect is in a way related to the Design pattern of "Factory
Methods" or "Factory Classes". Say I want to create graphical objects in
a graphical world. I want all the objects to be able to interact with
the specific world. In practice, this means every graphical object will
have to have an instance variable pointing to the world instance. And
all requests for new objects are routed through this world object. Such
graphical objects are hard to export and import because a naive
streaming approach would export the world with it. (I know in practice
one could modify the streaming code.) While the language can support
this, I find it somehow inelegant. 

I think the notion of an object being in a world of related objects with
a world object affecting its life and the meaning of its communications
with other objects is somehow "fundamental" in the sense that the VM
could support it directly. Also, to me it would make sense that
communications outside this world (or module, or subsystem) should
somehow be potentially different than communications inside the world,
and also references to objects outside the world might be of a different
type than references to objects inside the world. I'm not saying they
would necessarily look different to the object or syntax -- just that
support for this feature of worlds within one image might help address
modularity.  Worlds aren't quite namespaces, but they have aspects of
namespaces. The Design Pattern of a "Proxy" for commmunicating with
objects in another VM touches on this, but does not quite get at the
root of this issue.

If the VM supported such a notion of "worlds", here are some advantages:
1) GC might be able to collecting an entire world at once.
2) Browsers and stack trace reporters might be set to ignore worlds,
like the development tools world or the error reporting machinery world.
This might reduce apparent complexity when analyzing a problem. (This
might also lead to things being overlooked of course if they are
hidden.)
3) Security might be set up for what is allowed to interact with what
world. For example, the debugger might reach into most any code world,
but a code world might not be able to reach into the debugger world.
4) It might be easier to program some applications in a more modular
fashion. This might tend to make Smalltalk applications more robust and
reuseable in general. 

== conclusion ===

Obviously, there would be many issues to work through if this world idea
was to be feasible. One issue is whether objects need to belong to more
than one world at the same time.  Another issue is whether one would
have nested subworlds. 

Again, one can implement behavior similar to this in Smalltalk as is --
the issue is more whether such behavior should somehow be more
fundamental to the language and VM, to more easily support the
application oriented programming issues you raise.

Naturally, Squeak is a great vehicle for such experimentation.

-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

Alan Kay wrote:
> 
> Kevin --
> 
> This was the original intent for all users (but only a few like
> yourself find the process comfortable in today's system). We plan
> (and need) to make this process more understandable for a much wider
> range of users (and we could really use some help). We have various
> kinds of browsers, debuggers, inspectors and explorers, all of which
> are useful at the object level, but we don't have a browser/inspector
> for larger constructions (the equivalent of apps) -- e.g. like
> Celeste. It's largely a problem of focus and highlighting the parts
> of the nexus that are really important compared to the merely
> supporting players. It would be nice if this kind of brower were
> semiautomatically built as part of the app construction process.  It
> would be nice if there were a stronger larger structure architecture
> than just Morphic, or MVC, etc.
> 
> Any ideas?
> 
> Cheers,
> 
> Alan
> 
> At 10:21 PM -0400 9/12/00, Kevin Fisher wrote:
> >[ beware!  ahead lies coffee-induced speculation and musing! ]
> >
> >I've been polishing off my enhancements to Celeste the past couple weeks (I
> >added a tabbed preferences dialog to replace the ever-growing categories menu,
> >for example) and I've been noticing something rather interesting about the
> >whole process.
> >
> >Morphic is all rather new to me so I've been winging it as I go.  The nice
> >thing about Smalltalk is that I don't have to flip through any reference
> >books--I can just open a browser and jump directly into any class in the
> >system to see how things are done.  I learned Smalltalk from the 'purple' book
> >(Goldberg et al).  I really just picked up the basics from the book...and I
> >really don't need to flip back to it, at all, even for reference.  Even after
> >long absences from Smalltalk (ie over a year) I've still been able to jump
> >right back in.
> >
> >This got me thinking..to me it seems that the whole learning process with
> >Smalltalk is quite different from any other language I've used.  You seem to
> >learn progressively...since every class is open for inspection you CAN grow
> >your knowledge and apply it simultaneously, instead of the traditional
> >learn-in-chunks-and-then-apply way.  It just FEELS different...as I started
> >out with Morphic I knew nothing, and yet without any textbooks or detailed
> >HOWTO's I managed to figure it all out by browsing the system and trying
> >things in a workspace, and in a very short time.  Outstanding!  Just try
> >learning C or C++ from the headers in /usr/include and see how far you can
> >get... :)  More realistically, even with a well documented online system (like
> >MS Visual Studio) it is still very difficult to get up to speed on something
> >like MFC without a detailed book or reference.  Not so with Smalltalk, from
> >what I've experienced thus far.
> >
> >I dunno, maybe the coffee is getting to my brain tonight, but I just find the
> >whole thought process that Smalltalk inspires to be quite remarkable.  It's
> >got me thinking in a whole new way.





More information about the Squeak-dev mailing list