Squeakers -

With the awesome 2.3 beta release proving beyond a shadow of a doubt how
cool Squeak is, it may now be time to think about some underlying Squeak
"plumbing" issues.

In my opinion the issues of events, modularity, and exceptions are the
leaky plumbing that needs to be addressed to make Squeak a great
programming system (beyond merely good). I'll even go further: these
need to be addressed (and soon) if Squeak is to grow and prosper. They
need to be addressed to make Squeak ready for prime-time limelight --
into which it seems (ready or not) about to head.

Each of these issues also makes a big difference in embedding a headless
Squeak (my current interest). However, they also make a big difference
in terms of making Squeak more changeable in other ways (thus addressing
"pink" and "blue" planes simultaneously).
 
Exception handling allows one to more easily remove GUI dependence. It
also is becoming accepted practice. This is because use of exception
handling leads to cleaner code, helps one to securely manage unique
resources, and supports modules working together more cleanly (i.e. you
don't have to know what a bad return code would be, just that a call
could fail). I know you can replace the error handler for a process, but
this isn't really a complete solution. For an example of what I am
talking about, compiler code should not launch windows on detecting a
syntax error -- it should throw an exception. The top level exception
handler could open a window, in response to a compiler related
exception. Or, your code that calls the compiler could catch that
exception and process it itself.

Events allow Squeak to cooperate better with an OS (i.e. as a component)
and removes any tendency towards a high idle cycle stealing from
polling. Base Squeak still relies at the heart of it on polling loops. I
know Morphic addresses these, but Morphic brings along its own set of
performance and use issues. One needs to have events in the base system
without Morphic. I use "events" loosely here -- being "event driven"
also means (to me) being able to call in and call out of the system in a
coherent fashion (such as asking Squeak to evaluate an expression and
return a result). I understand that Squeak as an OS might require some
polling (ideally based on timer events). But Squeak as a component under
an OS would be better if it just dealt with events (like mouse move)
rather than asked hardware for them on a regular basis.

Modularity allows one to deploy a Squeak system with the minimal
footprint (like with only text handling classes and a compiler).
Stripping out what you don't want is not good enough. One should have
precise control over building an image up from modules to get exactly
what you do want -- with every byte accounted for (and none accidentally
left over from ST-76). Addressing modularity also entails addressing
version interdependency (something ENVY is good at). Ideally, the
standard image released for new versions should be as small as possible,
with new code being added by end users as desired. Of course, for
convenience people would create an image with everything, but that
should only be as a time-saver. One might also want to load precompiled
modules as object code (not source) over the web. Finally, modularity
makes it easier to conceive of shrink-wrapping a Squeak product.

Obviously, individuals have addressed these somewhat -- especially
exceptions (in different ways). Yet these enhancements have not made it
into mainline Squeak.

We are all grateful for the fantastic job done by Squeak Central of
integrating contributions and creating ever greater versions of Squeak.
Still, in the interests of moving Squeak forward, it would be nice to
know if these core issues of events, modularity, and exceptions anywhere
on Squeak Central's priority list for the near future. 

If not, since these issues are so fundamental to the system, how could
these be addressed by others in such a way as to avoid splintering off
another development line of Squeak? I seems obvious (to me) that having
proper solutions for these in mainline Squeak would not detract one bit
from efforts at Disney to use Squeak in-house (except in the sense of
time if they implemented them or merged them). Yet, every time I think
of coding up something to address any of these (or using someone else's
solution), I realize all that work is going to get left behind in a new
release, because it entails making many fundamental changes to the
system (sprinkled throughout the code).

At OOPSLA '97 it was brought up that there are two main Squeak camps.

The first camp is people who want to experiment. It seems this includes
the mainline Disney maintainers much of the time -- after all they are
not paid to provide a free Smalltalk system -- it just helps their work
to be using one. Working on Squeak's plumbing isn't as convincing to top
management of progress as the next cool Squeak Morphic applet/thingy,
and it's not as much fun either (regardless of how essential it might be
to sustained progress). 

The other camp is made up of people who wants an open and stable
Smalltalk to do real business-like work (typically grungy, non
glamorous, often text-oriented and standard widget-oriented). It's not
necessarily that we wouldn't pay for Smalltalk, or don't have several
purchased copies on the shelf. It's more like we want to ship the
compiler, or we might want to change the VM in the future, or we want
the really small footprint Squeak offers, or any of several other
reasons (often related more to open source issues than money itself).

Some people, like myself, are in both camps at various times. Perhaps
this is common. Obviously, being able to justify Squeak use to
management for grungy apps (like processing text files) would get it in
the door for other fancier uses. Does this make sense at all? Is the
second camp (or sentiment) present on this list to any extent? Am I the
only one out here thinking Squeak could become an acceptable scripting
language up there with Perl, TCL, and Python/TK? I would think many
people would adore feeding program/text files to Squeak which were
written in their favorite text editor (David Pennell brings this issue
up in a recent "Re: Squeak book" post).

As something to be concerned about, when the bulk of newbies show up as
Squeak gets more publicity, I'd think they would expect Squeak to do the
boring stuff, even if they other stuff (Morphic, Music, Wiki, Web, VM)
wows them. But if Squeak can't do the boring stuff (i.e. the stuff
Delphi does, VB does, C++ does, Python does), potential converts may not
stick around (unless they got faith, like me :-). They certainly will
have a hard time being able to convince their supervisor to use it for
utilities or apps.

Alternatively, if someone was going to maintain another line of Squeak
(focusing on stability, minimal footprint, shrink-wrapping, events,
modularity, exceptions, compatability like all code using := assignment,
standard GUI widgets, etc.) would that do other than wither as the
current mainline Squeak forged ahead? Or would experimental Squeak work
reorganize around the stable version? Would people want to use such a
release (beginners, servers, embedders, business types)? Would
experimental Squeakers be comfortable pointing newbies to a separate
line of development?

I'll conclude by mentioning that Python has exceptions, and handles
events and interoperation, and is modular. In fact, while I like
Smalltalk syntax better, and I think Squeak's potential is greater than
that of Python, availability of these features (events, modules,
exceptions) are key reasons I think Python is currently a more practical
development system for pure OO deployable applications. I'd like to see
Squeak/Smalltalk as the better Python alternative (just like Python is
the better Perl alternative). That's not going to happen if these core
issues are not addressed -- no matter how many fancy things make it into
a huge base image.

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the GPL Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com/squeak