On Wed, Mar 14, 2012 at 12:54 PM, Alan Kay <span dir="ltr"><<a href="mailto:alan.nemo@yahoo.com" target="_blank">alan.nemo@yahoo.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div><div style="font-size:14pt;font-family:times new roman,new york,times,serif"><div><span style="font-size:14pt">The many papers from this work greatly influenced the thinking about personal computing at Xerox PARC in the 70s. Here are a couple:</span><br> </div><div><span><br>-- O. K. Moore, Autotelic Responsive Environments and Exceptional Children, Experience, Structure and Adaptabilty (ed. Harvey), Springer, 1966<br>-- Anderson and Moore, Autotelic Folk Models, Sociological Quarterly, 1959<br> </span></div></div></div></blockquote><div><br></div><div>Thank you for these references. I will chase them down and learn as much as I can.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div><div style="font-size:14pt;font-family:times new roman,new york,times,serif"><div><span>2. Separating out some of the programming ideas here:</span></div><div><br><span></span></div><div><span>a. Simplest one is that the most important users of this system are the children, so it would be a better idea to make the tile scripting look as easy for them as possible. I don't agree with the rationalization in the paper about "preserving the code reading skills of existing programmers".</span></div> </div></div></blockquote><div><br></div><div>I probably need to clarify the reasoning in the paper for this point.</div><div><br></div><div>"Traditional" text-based programming languages have been tweaked over decades to be easy to read -- for both small examples and large systems. It's somewhat of a heresy, but I thought it would be interesting to explore a tile-based system that *didn't* throw away the traditional text structure, and tried simply to make the structure of the traditional text easier to visualize and manipulate.</div> <div><br></div><div>So it's not really "skills of existing programmers" I'm interested in -- I should reword that. It's that I feel we have an existence proof that the traditional textual form of a program is easy to read, even for very complicated programs. So I'm trying to scale down the thing that works, instead of trying to invent something new which proves unwieldy at scale.</div> <div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:14pt;font-family:times new roman,new york,times,serif"><div><span>b. Good idea to go all the way to the bottom with the children's language.</span></div> <div><br> <span></span></div><div><span>c. Figure 2 introduces another -- at least equally important language -- in my opinion, this one should be made kid usable and programmable -- and I would try to see how it could fit with the TS language in some way. <br> </span></div></div></div></blockquote><div><br></div><div>This language is JSON, which is just the object-definition subset of JavaScript. So it can in fact be expressed with TurtleScript tiles. (Although I haven't yet tackled quasiquote in TurtleScript.)</div> <div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:14pt;font-family:times new roman,new york,times,serif"><div><span>d. There is another language -- AIML -- introduced for recognizing things. I would use something much nicer, easier, more readable, etc., -- like OMeta -- or more likely I would go way back to the never implemented Smalltalk-71 (which had these and some of the above features in its design and also tried to be kid usable) -- and try to make a version that worked (maybe too hard to do in general or for the scope of this project, but you can see why it would be nice to have all of the mechanisms that make your system work be couched in kid terms and looks and feels if possible).</span></div> </div></div></blockquote><div><br></div><div>This I completely agree with. The AIML will be translated to JSON on the device itself. The use of AIML is a compromise: it exists and has well-defined semantics and does 90% of what I'd like it to do. It also has an active community who have spend a lot of time building reasonable dialog rules in AIML. At some point it will have to be extended or replaced, but I think it will get me through version 1.0 at least.</div> <div> </div><div>I'll probably translate the AIML example to JSON in the next revision of the paper, and state the relationship of JSON to JavaScript and TurtleScript more precisely.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div><div style="font-size:14pt;font-family:times new roman,new york,times,serif"> <div><span style="font-size:14pt">3. It's out of the scope of your paper and these comments to discuss "getting kids to add other structures besides stories and narrative to think with". You have to start with stories, and that is enough for now. A larger scale plan (you may already have) would involve a kind of weaning process to get kids to add non-story thinking (as is done in math and science, etc.) to their skills. This is a whole curriculum of its own.</span><br> </div><div><br><span></span></div><div><span>I make these comments because I think your project is a good idea, on the right track, and needs to be done</span></div></div></div></blockquote><div><br></div><div>Thank you. I'll keep your encouragement in mind during the hard work of implementation.</div><div> --scott</div><div><br></div></div>-- <br> ( <a href="http://cscott.net" target="_blank">http://cscott.net</a> )<br>