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
|