wiljo at mac.com wrote:
> Hi gang,
> 
> After a year away from Smalltalk I have come back to the light.
> Still catching up on all the changes... phew quite a task.
> Still much of the chatter reminds me of my reaction to
> Les Miserables... "such a lot of fuss over a piece of toast!" ;-}>
> 
> On Wednesday, October 16, 2002, at 07:32 AM, goran.hultgren at bluefish.se 
> wrote:
> 
> > I am not so sure - Ginsu is a model describing Smalltalk source code -
> > separately from the Smalltalk model itself. At least that is my
> > understanding. Modules is instead an extension to the Smalltalk model 
> > of
> > classes. Way back when I talked with Henrik about this I found his
> > arguments and model much more appealing than having an "extra" model
> > like Ginsu.
> 
> Well, you have missed the key distinction. "Ginsu" was about a 
> declaration
> of the model of the semantics of a Smalltalk program. A non-reflective

No I didn't miss that. Joseph was even here and showed it to me.

> description language of a reflective execution environment. The 
> essential
> distinction is the separation of the declaration from *any* 
> implementation
> of the semantic model specified. This first distinction is the key to 
> allowing
> the revision of the state of a Smalltalk program... independent of any
> particular image or runtime implementation.

Yes, I know this.

> The draft of the ANSI Smalltalk standard v1.9 has sidebar comments that 
> go into
> some detail in this regard. Also, OOPSLA '88 Alan Wirfs-Brock and Brian 
> Wilkerson
> wrote the seminal paper on Modular Smalltalk which is the mother of
> the ginsu approach to Smalltalk modularity.
> 
> <aside for the interested reader>
> This subtle distinction is a profound one when considering the 
> evolution of form.
> (cf G.-Spencer Brown "The Laws of Form") Follow all the injunctions, 
> contemplate
> the declaration of formal indication, the consequent arithmetic and 
> algebra
> and finally the introduction of formal self reference in a form that 
> experiences
> temporal evolution of signal.
> </aside for the interested reader>
> 
> 
> >
> > For example - the ability to have classes loaded in the image (fully
> > compiled etc so that tools work and so on) but not having them 
> > activated
> > in the name space seemed like a brilliant approach. And activation
> > through  big become-operation seemed very neat.
> >
> 
> How is that distinct from having tools that operate on declarations of 
> the
> program with all methods fully compilable and loadable? At Digitalk,

"distinct" it is not. But it felt like a much more lightweight approach
that delivers much the same benefits of Ginsu but without an "extra
model" of the code. To me, Henrik and several others (including Dan)
this felt more in line with what we need/want in Squeak. And according
to Henrik it is much more lightweight not only codewise but also in RAM.
And it built further upon the Environment stuff that Dan had started.

> Steve Messick did some very cool remote development on headless
> images. Utilities like "cp" could be as small as a 30k image, with the

Yes, I know this can then be done (Joseph also talked alot about
"tethered compilation" etc) - but I can't actually see what this has to
do with anything. It's trivial to hook up to a headless image using
sockets and bang anything over there - I can do that today without any
of Ginsu or Modules... Or perhaps I missed something?!

> capability of attaching the program to the declaration giving full debug
> and development support. (Imagine programs being a kind of project
> with a completely separate namespace living in a separate runtime
> process somewhere on the network... all with development ui's switchable
> the way in which we switch between projects.) That is my definition of 
> neat.

But... what has this capability (remove development) to do with modules
(small m for the general meaning)?

> OBTW, the development environment itself was just another program...
> 
> > I talked with Henrik about Ginsu and he said that he had looked at it
> > and thought that similar goals could be achieved better using other
> > techniques. And then he wrote Modules. Since he knows this stuff
> > infinitely better than me (especially compared with Ginsu) I can only
> > hope he posts his thoughts.
> 
> Perhaps that is indeed the case. Nevertheless, dig up a copy of VSE if
> you can. Load Team/V. Open a standard class browser and edit away.
> Use the disk browser and file in a bunch of module unaware code.
> All of that stuff winds up in a module called, *Unpackaged*. Most folks
> never knew that the old fashioned browser was no longer editing the
> classes and methods themselves, but instead declarations of the 
> aforesaid.
> I suppose my point is that all of this is based upon many years of
> experience with making Smalltalk more modular.

Yes, I am aware of that. And it is a very CM oriented approach. Even
Joseph has said that Ginsu is "Envy done right". But that is not what
Squeak needs! Well, some of use do need a good CM tool - that is not
what I meant. I meant that it's more about packaging, deployment, image
stripping/building, namespaces, runtime components, dependencies between
modules, conflict detection and *above all* detangling the darn image.

And almost all of the above has nothing to do with classic CM problems
which more or less focus on "how do we build a BIG system using 20
developers". That is where Envy comes in. And Team/V - just listen to
the name of the product.

Anyway, I am blabbering now - thanks for clearing up some parts about
the Ginsu origins.

regards, Göran