wiljo@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@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