[Edu-sig] FYI: PataPata postmortem link

[Paul D. Fernhout]

Ian Bicking wrote:
> There's certainly tree-like structures in memory (and pipeline, and 
> cubbies, and all sorts of other data structures).  And it's entirely 
> reasonable to create a browser for these objects, where you can inspect 
> and traverse those in-memory objects.
> 
> Where that currently falls down is that while you can change those 
> objects, that change is not generally persistent.  When the process is 
> restarted, it will restart just like it was before.

You previously brought up the issue of "knowing the state of an object vs. 
knowing how it got that way" in the context of development tools for kids 
and the OLPC project. Which makes me think about something related to my 
Pointrel data repository approach, some examples of which (including in 
Python) are here:
   http://sourceforge.net/projects/pointrel/
and also in a subdirectory called Pointrel of the PataPata project code 
(where I implement a crude Smalltalk environment but on top of Python).
   http://sourceforge.net/projects/patapata
Essentially, the Pointrel system stores triples (sometimes quads or octs) 
which denote the change in state of the system over time. So, for example:
Relation# A B C
1:  X value 10
2:  Y value 20
3:  X value 20
4:  Y Value 10
5:  Y Value 20

This could be interpreted as showing two variables X and Y changing their 
values. (In practice this would be more complex, I'm just simplifying this 
here).

You coudl also imagine:

Relation# A B C
0001:  X value 10
0002..0101: [internal changes (e.g. stack) for bytecode processing]
0102:  Y value 20
0103..1002: [internal changes (e.g. stack) for bytecode processing]
1003:  X value 20
1004..2003: [internal changes related to code processing]
2004:  Y Value 10
2005..3004: [internal changes related to code processing]
3005: Y Value 20

The key thing is that if you also use the system to store the state 
related to the processor in one stream of changes (which the version I put 
in PataPata does, although not maybe general enough here as I tried to 
split it up into two memory steams of changes in that particular version), 
then, when you want to know what the state was of the system when any 
variable was changed, your tool could look at the most recent change to a 
field, and then working backward from there, see what the current state of 
the program was. This is sort of like storing a stack trace or the state 
of the machine whenever any pixel is set, but now it is looking at it in 
terms of when any variable is set (or *any* other changer is made). So, 
with the right tools, it would be at least easy for a novice programmer to 
see what was changing a piece of code.

Now there still remains the problem you raise -- where to intervene if you 
want a persistent change. And also, there remain the complex logical 
problem of then pursuing a set of changes back in time and mapping them 
onto programmer "intent".

Anyway, I thought I'd just mention this aspect of some versions of the 
Pointrel system, because with people always choosing to use (more robust) 
relational database systems like Postgres or MySQL, and with the 
ascendance of RDF for storing triadal information, and as other 
opportunities have passed by (e.g. easily adding OO to C) during the more 
than twenty years I've played around with these concepts, the Pointrel 
system has become a bit of a solution still looking for a good problem. 
:-) But clearly here is a problem it could solve (and I have always liked 
the Pointrel system for its promise of being able to do that, although, to 
be fair, OCaml manages something similar when its debugger steps backwards 
in time by using checkpoints and recalculating state from them -- although 
it can't deal well with IO issues which might be different during the 
recalculation from a checkpoint). Anyway, what occurs to me is I have 
never thought of emphasizing this aspect of being able to step backwards 
in the debugger as well as easily find the point in time when a variable 
was changed (as well as the state of the entire system at that time) in 
the context of a programming environment for *beginners*, so that is an 
idea I have to think about. And, it also lets you find out when any pixel 
was changed, if bitmaps are stored within triads. Of course, this is all 
very inefficient in some senses to store all this information and to 
search it, but in a system for small applications it might not be 
noticeable, or if it was noticeably slow, it still might be worth the wait 
for beginners in some situations (although in general beginners need 
faster systems then experts because they make so many more mistakes and a 
fast cycle time lets them learn faster and better).

Again though, it does not solve the problem of how to make changes 
(persistent or not) once you have that information by understanding what 
state the system was in (and the related intent of the code) when of 
interest something happened in a way other than what you wanted. But maybe 
it could be linked with some other approaches that did (perhaps 
Smalltalk-like in terms of an image of live objects).

--Paul Fernhout