Modular Squeak

Paul Fernhout pdfernhout at
Mon Sep 25 13:13:27 UTC 2000

Stephen Pair wrote:
> Probably everyone agrees that getting to a more modular Squeak is absolutely
> essential in accomplishing many of the things mentioned in the recent thread
> on Python at Disney.

> [Snip]
> Of course, I realize that none of this is all that important to the
> essential research that is taking place at SqC.  And it shouldn't be.  There
> is a well defined path of research that SqC seems to be heading, and dealing
> with these issues would only be tangentially interesting at best, and
> completely distracting at worst.

Agreed. The people there who created Smalltalk should in my opinion be
allowed to do whatever they want for the rest of their lives, as their
reward for inventing the future. 

> I do think that SqC is very aware of the many benefits to be had by making
> the image more modular.  It enables code to age more gracefully, reduces
> version skewing, enables better memory management, enables a more immersive
> web experience with projects on the net, and yes, it enables Squeak to look
> more like traditional development tools.

Agreed. Modularity provides flexibility and resilience.

> I guess the point I'm trying to make is that modularity should be a high
> priority.


So where do we go from here? 

Here is my take on it. Fancy applications and libraries are great.
Squeak needs them. But they are in the end almost worthless as far as
production use unless the central core is modular (and thus likely more
stable and possessing other good qualities). 

Any end user of Squeak can make a fancy application or library. In
practice, only a group in charge of a fork can make the central core
modular and stable. IMHO, If SqueakC wants to see Squeak prosper in a
big way, they must address this fundamental issue of modularity.
Everything after that can be added by the community a piece at a time.

Frankly, I wish I had the time and resources to make this happen myself
as a fork. But I don't at the moment. I've considered it several times,
but repeatedly turned back from it -- out of concern my changes will get
swept away as the core keeps changing, and out of concern of the months
this will take away from other things, and also frankly, because other
alternatives are attractive (eg. VisualWorks or DrScheme). 

I'm sure eventually Squeak may get coser to production quality. Slowly
things are happening. Exceptions got in finally and are likely to be
used more widely. Events are now happening in 2.9. The compiler has been
improved by Mats. I hear a rumor of Morphic being refactored. Replacing
the fonts are finally becoming higher on the priority list. The Squeak
Stable World Tour is happening.  It is just a very painful, slow, and
expensive (in developer time and emotion) way to go about this -- and
the only savings to SqueakC is a few person-months of refactoring. And
so other things (Java, Scheme, Python, Kylix, VisualWorks) grab momentum
and developer mind share.

Here's the bottom line as I now see it. There is the "pink plane" and
the "blue plane" Alan Kay discussed way back at Oopsla '97. It was
represented at that first BOF as half of the BOF crowd interested in
Squeak to do new things and tinker with the environemtn, and half the
BOF crowd wanting to use Squeak as a better (and free in many senses)
Smalltalk. SqueakC seems mainly interested in the blue plane. People
interested in pink plane work (maybe with a touch of blue in one area)
come to the list and leave after a while (thus making the list mostly
self-selecting for blue plane interests). What I am seeing here (and
with the Disney Python job postings) is that people (even at Disney) may
not take blue sky work seriously unless it rests on living pink flesh.
To an extent, you either have both -- or eventually neither.

And after all the long discussions about various needed Squeak features,
it comes down to the issue of modularity (or management of complexity
and uncertainty) as the key factor that will enable both pink and blue
use of Squeak. Modularity of the image (built from scratch). Modularity
of the code (made of mostly independent subsystems with well defined
interfaces). Modularity of the GUI (including controlled developer and
user changes to it). Modularity of the error handling system (by
exceptions). Modularity of the compiler and development tools as Mats is
interested in (so Squeak can handle inputting and outputting code in
multiple languages). Modularity of namespaces. Modularity of the update
streams (getting only the modules you want updated). And so on.

Obviously there is more to making a production system than modularity
(or management of complexity and uncertainty). However, it the single
most core issue, and one not one someone outside of SqueakC can easily
fix in the main line fork. After that issue is solved, all the needed
specific modules or enhancements can be created by smaller and
tangential efforts.

Steve Jobs, you out there listening? Maybe Apple needs to invest a
little more in Squeak Smalltalk, as by supporting such a great cross
platform tool, Apple can keep Mac development on a level playing field
with Win32 and Linux.

-Paul Fernhout
Kurtz-Fernhout Software 
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator

More information about the Squeak-dev mailing list