Turtles All The Way Down

[NoiseEHC]

Okay, it seems that I made the wrong questions (as always) and while got 
perfectly good answers, I did not get the knowledge I wanted to have... 
So it seems that I am looking this from the perspective of software 
development and you see it as research. While I can totally accept that 
research is interesting and cool, I would like to define a working 
usable closed subset of the problems you want to research, to have a 
finished "product" which can be put into the hands of children _now_.

So the real question is what the goal is? I thought that it is part of 
the googleization effort and so it would become a Browser based 
MegaTurtleArt or something like that. But now it seems that it is some 
research into self contained systems or whatnot.

My thinking is this:
A browser based editor written in SimpleJS which can graphically edit a 
subset of SimpleJS programs (the subset which can produced by the editor).
Editing the editor code can be done differently than editing the loaded 
programs (or not at all).
If the user learned the generated SimpleJS then she can edit the source 
of the editor with a text editor and save as a new activity (btw she can 
look the source of the editor graphically if she wants).
Objects can be edited through a name/value editor which saves the object 
to the object literal in the loaded SimpleJS source.
The editor does not save state, it just runs the loaded program after 
loading just like TurtleArt does.
It should have a TurtleArt and Scratch importer as well.

Now my "proposal" has the advantage that it does not need a runtime, the 
source *is* SimpleJS. Since the editor cannot be modified with itself, 
it cannot be destroyed, no undo needed. The generated SimpleJS (or the 
AST in the blocks) can be undo-d. Since it does not want to save state, 
the generated SimpleJS must not be obfuscated with passed in context 
(and neither your editor source is obfuscated). Because only the source 
is saved, it must not use the "macro" system but it has to simply parse 
different AST into blocks by some pattern matching (and this is similar 
to flattening + or &&). This pattern matching must be built into the 
editor source and cannot be extended, the user can only extend via 
functions (like JS programming, wow :).

So it is "just" a matter of finishing the editor and adding a turtle. 
Note that it seems that I am looking at this program as to a user 
interaction problem because I find it hard to design a TurtleArt with 
touch interface and so it is an interesting problem for me. You seem to 
find more interesting the turtle column thing. I really do not want to 
tell you what (not) to do but the question is whether this turtling down 
have so much pedagogical value to worth the added complexity?

So the real question is what the goal is?


On 2011.05.20. 20:02, C. Scott Ananian wrote:
> 2011/5/20 NoiseEHC<NoiseEHC at freemail.hu>:
>> 1. Why do the bytecode stuff? JS seems to be a perfectly good code
>> representation to me and it can be run much faster compared to a naive
>> bytecode interpreter or compiler written without the resources of the
>> Chrome/V8 team.
> It's true.  As described in my blog post, the VM work was an
> experiment to see "how far down the turtles could go".  As the Klein
> VM and other examples have shown -- pretty far down!  Even if you end
> up running the language in the fast V8 VM, you might want to have a
> version with somewhat lower performance which is 99.9% "view
> source"-able.  But I really should be concentrating on the
> higher-level stuff at the moment.
>
>> 2. Why do you want to serialize the stuff? Is not it enough to serialize
>> just the JS code + screenshot and on load run it?
> It relates to the desire to be able to do prototype-style development,
> where you modify existing objects to create new functionality.  (Think
> etoys.)  Once you've got a bunch of user-modified objects floating
> around, you have to start thinking about how to save/load them.
>
>> 3. Why is the pervasive undo necessary? Only for debugging?
> That relates to the goals of Sugar, leaking through into TurtleScript.
>   It's actually pretty easy to screw up your VM pretty badly if you can
> actually access it down all the way to the bottommost turtle.  Once
> you've done this, it would be nice to be able to recover gracefully --
> or at least, more gracefully than "toss the saved image and restart".
> Supporting cheap snapshots of the system image is one way to do this.
>
>> BTW cool project, that is exactly what I wanted to do, now I do not have
>> to... :)
> Oh no!  That's the opposite of my intended goal in talking about this
> stuff -- at some point I badly need other people to adopt the ideas
> and carry on with the implementation, as I'm unfortunately still a
> single-core human.
>    --scott
>