At 05:15 PM 1/1/99 -0500, Paul Fernhout wrote:
[snip]
>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.
[snip]
>Exception handling allows one to more easily remove GUI dependence. It
>also is becoming accepted practice.
[snip]

I've sent my implementation of the ANSI Exception protocols to a half a
dozen folks to try out but haven't received any comments on it back from
them yet.  I had no experience with exceptions until I implemented them so I
don't know whether my implementation is a useful starting point or junk.  I
wanted to finish the ANSI Numeric protocol (now done) and give the folks I
sent my exception stuff to a chance to try it out.  I'll check back with
them and if they think my exceptions stuff is usable, I'll send it on to
Squeak Central in the hope they will incorporate into the base system.

As I understand it a robust exception implementation requires VM support to
properly handle returns (up arrow) in the protected and action blocks.  I
won't consider digging into Squeak internals to do this until after I have
ported the remaining ANSI protocols, if at all.


[snip]
>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).

I think the declarative model, as I understand it from the description given
in one of Allen Wirfs-Brock's documents at his web site, would address this
issue.  I planned on trying to implement it, but again only after I've
finished the ANSI stuff.


[snip]
>Obviously, individuals have addressed these somewhat -- especially
>exceptions (in different ways).

I was sort of hoping we could finally get them addressed in a "standard" way.

[snip]
>We are all grateful for the fantastic job done by Squeak Central of
>integrating contributions and creating ever greater versions of Squeak.

I'll second that.


>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).

I have those same concerns.


>At OOPSLA '97 it was brought up that there are two main Squeak camps.
>
>The first camp is people who want to experiment.
[snip]
>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).

Open source is my main reason for turning to Squeak.


>Some people, like myself, are in both camps at various times. Perhaps
>this is common.

I'm in both camps.  I am unwilling to port the same core code of lots of
tools to new dialects.  The tools make it easier to do grungy stuff and
experimental stuff.

I never know if a bug in a tool in one dialect (or a terrific enhancement)
is fixed (added) in other ports.  Maybe the ANSI standard will not prove to
be all that advantageous in writing dialect portable applications, but I'
inclined by my experience in other languages to put the work into it to find
out.  Doing this also keeps me out of pool halls and away from questionable
influences.


> 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?

Perfect sense to me.


>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).

And if it is useful, how many times should this application be sliced,
diced, and re-edited to get the same functionality in different dialects?


[snip]
>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?
[snip]

I have been wondering what to do after I've finished adding the ANSI stuff
to Squeak.  Do I stay with Squeak and hope the grungy apps camp stays
interested and active, and those knowledgeable (and interested) enough to
work on the VM don't move on to Java?  Do I commit to a branch of Squeak
that like old solders and SE never die, but just fade away?  Or is Dolphin a
better bet in the long run?  Or is VWNC?


Thanks for putting it so elegantly Paul.

--
Richard A. Harmon          "The only good zombie is a dead zombie"
harmonra at webname.com           E. G. McCarthy