Alan Kay said: 
> Thanks Mark --
> 
> At 4:59 AM -0000 10/8/98, Mark Wai wrote:
> -- snip --
> 
> >As a side note, I would have to say that Squeak is not only good for
> >learning Smalltalk/OO but a good live document for computer science in
> >general.  I think Squeak would be an ideal environment to teach, demo,
> >explore and even change/extend for any computer science class ranging from
> >graphics, compiler, electronic music, internet programming, networking, ....
> >and you name it.. and I won't be surprise that one day when I open my Squeak
> >image,  I don't ever need to open up any applications (e.g. Word, netscape,
> >Eudora) since I can do all these from within Squeak.
> 
> This, in a nutshell, is one of our main nearterm goals -- especially (a) a
> "total" environment, and (b) "a good live document for computer science in
> general".
> 
> All on the Squeak list, please think about helping this along over the next
> year.
> 

I don't know.  I've used Smalltalk, Forth, and Lisp (Macintosh Common Lisp,
Harlequin's LispWorks on Unix and Gnu/X emacs) environments, all of which
are "unitary" environments that try to be total.  I also use unix under
Xwindows on a daily basis.

I think, in general, I prefer the "separable" environments where I have a
broad spectrum of small tools I can use whenever I want.  It's very easy to 
incorporate new tools, or to try out somebody else's great ideas.

When I had the job of interfacing Harlequin's LispWorks with the ClearCases
change control system and Task Tracking System we'd developed around
Quintus's QualPro(?) database system, I spent some time thinking about the
issues involved.  This was an early version (version 2) of ClearCase and
they'd assumed a separable environment, with no mechanism to change the
view of the file system provided to a running process.  We had to find a
way around that problem to be able to use it from within the Lisp
environment, since we were unwilling to take the time (on the order of
minutes) to get out of Lisp and back in every time we needed to change
views.  The system we were developing had originally been developed on
Symbolics machines, where Lisp was the Total environment, and ported to
Sparc machines running Unix or RTX.

I may be wrong, but my take on it was that the major advantage the unitary
environments provided, and the major impediment to making them separable
was that the services they provided were a superset of those provided by
current operating systems.  In particular, they provide alternative memory
management / garbage collection. (Well, forth does it's own memory
management, but not gc ).  So far as I know, the process management
capabilities are basically duplicates of that provided by the operating
system.

If one were to be able to push the memory management into the operating
system, would we still need unitary environments?

Well, as soon as I wrote that, I realized that a better way to state it is
that the VMs these environments provide differ from the implicit VMs
provided by typical operating systems.  The VMs define not only the memory
management models, but also file system, process management, and
intra- and inter-process communication mechanisms.   Still, it seems the
major hurdle is the memory management, because all the unitary environments 
I know, even modern Forth environments, can use the OS's filesystem and can 
interoperate with other OS processes.  

So, a question to consider:  If NGOS (the Next Great Operating System) were 
to include generational garbage collection at the process level, would it
still be advantageous to maintain the unitary environment, and why?

If not, could we open up the Squeak VM a bit, to allow partial separation,
or separation that included memory management facilities as part of the
separated pieces?

It seems to me that GNUemacs  or Xemacs may be good models of what such an
environment would be like. They allow me to run separated tools as
"inferior" processes, at least on Unix systems, capturing the output and
interacting with them using the other services provided by the OS.

Perhaps Java, (simplified C++ with garbage collection), is/will be popular
enough to get people beyond their fear of garbage collection.  If so,
moving real memory management into the OS might provide an opportunity to
try something really new with Squeak, or its grandchild...


If you really want a project, consider how the OpenSource community might
push Linux in that direction...


Or, thinking of MkLinux on my PPC machine, what if the SqueakVM were an
alternative library to run on the Mach kernel...


Well, that's probably enough bandwidth used for now...

joe