On 14/06/2011, at 4:07 AM, Josh Gargus wrote: > > On Jun 13, 2011, at 9:35 AM, Julian Leviston wrote: > >> >> On 14/06/2011, at 1:17 AM, Alan Kay wrote: >> >>> It would be great if everyone on this list would think deeply about how to >>> have an "eternal" system, and only be amplified by it. >> >> Hi Alan, >> >> You might need to elucidate a little more on this for me to personally >> understand you. Not sure how others feel, but the "Worlds" work seems to be >> just a description of a versioning pattern applied to running program state. > > It seems like much more than that to me. >
Cool :) I'm not saying it doesn't have interesting ramifications ;-) > >> Why is it especially interesting? In the Ruby community, we have "gem" which >> is a package manager and also bundler, the two of which handle dependency >> management and sets of bundles of dependencies in context and situ elegantly >> and beautifully. Depending on your requirements when writing code, you can >> point to "a" version of a gem, the latest version, or say things like >> "versions greater than 2.3". It works really well. It also fits very neatly >> with your idea of (Alexander's? ;-)) the arch and biological cellular >> structure being a scalable system: this system is working in practice >> extremely well. (Mind you, there's a global namespace, so it will eventually >> get crowded I'm sure ;-)) >> > > Consider that in a Squeak image, the compiled methods are reified as objects. > With Worlds, you can make exploratory changes to code in a *complex running > system*, and then back out effortlessly if it doesn't work. You just throw > away the World containing the modified code as well as the objects that were > modified as a side-effect of running the modified code. > Yes, I've considered this. One of the things that crops up, though, is what about "data"? That is to say, what if one of the "world" experimentations one ends up doing involves experimenting with modifying some of the model of a particular piece of code... and this necessarily involve mutating a data type (ie model parent object or "class" implementation)... how does the idea/system apply to this, especially when considering things from the point of view of concurrent simultaneous users... where one person may mutate the state in the discussed manner, but another person is using a different "world" (a previous one with a different data structure in place)... yet they both still need to use the same data (ie imagine an address book application where one person is mutating the model layer live, and both people are using it live and inputting new data)... ... the idea of published / unpublished (ie published being a particular "world" that is being pointed to as the current "live" one) seems to serve well here. ... also, the idea of modelling change ITSELF is an appealing one in this context, and all changes including data "entry" etc being simply represented as a log of mutations using the command pattern. Thus the data represented in the first "world" would be mutated and "propagated" to the new world (actually more like the "view" of it filtered or some-such) according to the new rules, and the inverse would apply as well... ... of course, the question of irreversible transactions (ie destructive or creationist "commands") arises... what to do about when adding or destroying structure inside a data structure when involving those worlds? (in other words, the second, experimental world perhaps has added a "title" field to a person, and then the second world user adds a new person, with the title field... what does the first world user see?, etc. This is a superficially simple illustration - add some code to the second world which would break if things aren't set up in a particular structure, such as a requirement on the "title" for a person, and then the first world entry not actually having a title, and we get a bit stickier - this particular example falls apart rather easily, but you get the gist, hopefully?) The worlds idea seems to ignore the fact that the only way to really get the feel for something is to use it... so an experiment (ie a child world) would need to be using real, live data... so a "user" or "programmer" would end up with the painful situation of having to migrate their created application objects - the "data" - back into the parent world but not migrate the code back if the experiment failed... *or* they would have to treat the experimental world as experimental only and not "real", but doing this wouldn't actually allow one to know whether the experiment was working or not... *or* they'd have to use two worlds simultaneously - the first, un-experimental world to just use their application, and the second world to test things out until they were happy that it would work as they anticipated (ie the experiment worked). Either way, it could bear more thinking... Julian.
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
