craig at netjam.org
Wed Aug 9 00:31:18 UTC 2006
On the squeak-dev list, Dean writes:
> Regarding modularity, wasn't there an Idea that future work would be
> based on Craig's Spoon work? That at least offers a repeatable
> 1) Start with a "full" image version X.Y-Z, execute some method(s)
> designed to exercize the desired funcionality to imprint a new
> "minimal" image
> 2) Save the minimal image and give it a name/version. It seems that
> S-unit tests of some sort would provide the basis for the method to
> imprint the desired functionality.
> Is there any reason why this isn't a good path to follow?
> As the *only* path? Or as part of an overall strategy? If the first,
> I'd say that I'll answer that question once I've seen the first system
> that has been built that way ;-) ["once bitten, twice shy"] As part of
> an overall strategy it's perfectly fine - there are various
> interesting ideas in Spoon which can be helpful in many different
> I'll echo this opinion. Spoon does nothing to make the system more
I assume you mean that Spoon provides no tools for untangling the
current mess of behavior. That's not true. Spoon provides the ability to
"imprint"[1, 2] methods from one system, as they are run, into another
system (leaving all other behavior behind). When driven by unit tests,
this establishes a useful starting point for more detailed refactoring.
I think this is what Dean was citing.
I don't think it's fair to call this mere "unloading". (In fact, I
have a far more aggressive technology for that.)
I agree that this leaves a great deal of manual and careful work
for humans (preferably the original authors of each component). It is
indeed hard and unglamorous work. (It is also work that I will do myself
if necessary, if no one else has done it by the time it becomes my top
But I'd like to point out that (in my opinion) Spoon is the best
place to record the results, and does a great deal to keep the system
modular once the knots have been undone. Spoon provides a module system,
"Naiad" ("Name And Identity Are Distinct") with which one may clearly
establish dependencies, authorship, and many other aspects of related
behavior. Modules are a fundamental part of Spoon's support for software
delivery. For more details (such as they are currently), please see the
Spoon mailing list archives. Please also see the sample module
catalog, although it's still a work in progress (as are Naiad and
I mentioned all of these things here previously.
Without a solution for the modularity problem, I wouldn't have
bothered with Spoon at all. Producing smaller systems is a nice
side-effect, but the primary goal of Spoon is to make Smalltalk easier
to learn. In my opinion, the largest obstacle for learning Smalltalk,
throughout its entire existence, has been the system's poor organization
(it has some, but not nearly enough).
> Spoon is a good tool, but it's not "the answer."
For what it's worth, in my refactoring work so far (mostly on
Augment) imprinting from tests cuts refactoring time by about half. I
also think we could go much further along these lines.
Finally, I'd like to reiterate how unfortunate it is that we seem
unable to discuss the merits of a design before the implementation is
finished. I think this leads to comments such as "X is not the answer".
We should be discussing what's missing, and how a design might be
improved. As it is, one is simply left with the impression that a design
lacks potential. I think Spoon may very well become "the answer" for
I appreciate that we'll get bitten along the way, but I think
demanding a finished system before evaluating the ideas or imagining how
it might work is a bad way to go.
More information about the Spoon