I wrote this without reading the very latest http://www.vpri.org/pdf/tr2011001_final_worlds.pdf so if I say anything that is obviously missing that understanding, please bear with me :) I'll read it shortly.
Julian. On 14/06/2011, at 5:26 AM, Julian Leviston wrote: > > 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
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
