environments vs. files

Craig Latta craig at netjam.org
Thu Aug 18 00:03:37 UTC 2005


 > > I'm just putting in a word for an approach which I think is more
 > > worthwhile, despite taking longer to realize (because the work is
 > > less incremental).
 >
 > Less incremental is a pain in the rear.

	Sometimes it's worthwhile. I find it can be less a pain in the rear 
than being forced down a dead-end, constantly led forward by the 
short-term ease of "the simplest thing which could possibly work". :)

	Surely this is just the old "blue/pink planes" dialectic.

 > What makes it less incremental?

	In the particular technical design I advocate, what makes it less 
incremental is producing a very small object memory to use as a starting 
point, reorganizing existing modules to work with it, and actually 
making the switch. I grant this is less interesting if one isn't 
interested in very small systems, and in knowing how every single part 
fits together, but I do. :)  One reason I am is that it'd be useful to 
have small object memories which are responsible for housing a small, 
focused portion of behavior (e.g., live mirroring of changes made to a 
normal development system).

 > ...why couldn't/shouldn't it be done as incrementally as what I
 > mentioned above (an alternative substrate for MC versioning)?

	I think Monticello's model of package composition and behavior transfer 
is too coarse. As I understand it, applying changes via Monticello is 
built around a one-way bulk transfer of information from producer to 
consumer, using a declarative model. I think computing what ought to be 
transferred should take into account what the consuming system already 
has; there should be a live conversation between the systems. (Note that 
the producing system might be run from an object memory snapshot which 
is transferred in advance, and that this snapshot might have only what 
is needed to conduct the conversation-- another motivation for minimal 
snapshots.)

	Instead of using that declarative model, and transferring that data, I 
think it makes more sense to get the system elements themselves 
communicating directly, with the help of annotation (e.g., compiled 
method version IDs, class IDs). I think that would be simpler, smaller, 
result in less network traffic, and lead to fewer undecideable 
situations during behavior transfer.

	I guess a shorter way of saying this is, if you can do it with files 
(non-interactive data transfer) you're doing the wrong thing. :)

 > > I must say, though, I'm continually surprised how the "everything
 > > happens by sending messages" idea goes out the window at physical
 > > machine boundaries. It's just weird.
 >
 > Well, a lot of nice assumptions go out the window at physical machine
 > boundaries.

	But not the ability to send messages and get answers, right?


-C

-- 
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]





More information about the Squeak-dev mailing list