Paul McCullough wrote:
[Snip]
> So what, in my opinion, would help? The one thing I've heard of (alas, no
> direct experience) was the Firewall project that Allen Wirfs-Brock & Steve
> Messick (and probably others) worked on. Have a development environment
> where pretty much anything goes. And a target environment which starts out
> empty. If the user doesn't say to add class Point to the target, it isn't
> there. Not much different from importing packages or classes in Java. Or
> having include files in C. But, in those languages, I can easily say "this
> is my program." And I can easily make a reasonable-sized executable. Of
> course, we'd still allow you to modify a system class if you needed to --
> but you'd only be modifying it in the target.
[Snip]
> I have some spare cycles coming up. I am seeking others who think this an
> interesting goal to pursue and are willing to commit to making it happen.

Paul -

What you propose sounds great. We had a discussion of something like
this on the list around late October and early November 1997. It was in
the context of creating modular loadable "object spaces" for Squeak,
along with remote debugging from one VM to another.

I'd be very interested in a project like you describe. Again though, my
major concern is that unless this work is rapidly integrated into Squeak
Central as a major priority, this work would require a major fork or
would get left behind.  I don't say this to bash Squeak Central -- they
are doing great stuff. It is just that I believe that certain core
features need to be a priority of the core team. The analogy of doing
surgery with the patient running uphill sounds apt.

I'm sorry if I keep coming across as a broken record in most of my posts
to the list over the past few years. A major thrust of what I say is
always the same (perhaps becoming clearer over time as other people
refine it).

To become a serious platform, Squeak needs:
* to be modular (namespaces, buildable image, maybe inter-VM/"object
space" debugging),
* to have at least one stable, easy to use, lockable, scalable GUI,
* to be event driven, and
* to interface easily with the outside world of code.

I saw a lot of the need for these in attempting the Squeak->Newton port.
These areas were all major stumbling blocks. Embedded Squeak (inspired
in part by that struggle)
   http://www.kurtz-fernhout.com/squeak/ 
addresses some of these -- but only in a very rough way (shrink once,
discard the GUI, make events only textual code input, interface via
pipes, stir, enjoy). Unfortunately my Mac (Quadra 630) Hard Drive didn't
survive being relocated from Iowa to New York, so getting Embedded
Squeak on the Newton has been put on permanent hold for that and other
reasons. 

The issues of modularity and being event driven are more core than the
GUI and interface issues. I think that is partially why we have seen
approaches to GUI and code interface (pluggable primitives) appear and
then be integrated into Squeak central. 

Interest in the other two (events, modularity) repeatedly appears and
then fades away. The "coreness" of modularity and events make it hard
for momentum on such projects to get going in the absence of a Squeak
Central priority on them -- without a fork. Forking is most likely to be
lead to orphaned code in the absence of a significant commitment to
maintain it separately -- for example, Embedded Squeak is still stuck at
version 2.2.

So, to move forward with your proposal, it seems either one must bring
Squeak Central on board with a significant commitment from them to
integrate the changes rapidly, or one must make a commitment to
indefinitely maintain a parallel system (and perhaps hope that people
including Squeak Central migrate to it if it is really good). Obviously,
your flexibility in doing open heart surgery on running patients does
provide another option...

Unfortunately, modularity touches on so many aspects of the system it
does seem like a daunnting task. Every time I think about it, it almost
seems easiest to start from scratch. I almost think making Squeak
modular will be equivalent to taking a car apart piece by piece to get
it though a doorway -- and then assembling it as an airplane on the
other side. I think it's doable, but it would take several person weeks
at least.

-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