If you're going to base it on Javascript, at least make it Coffeescript-like. I also agree that some basic parallelism primitives would be great; it is probably possible to build these into a Coffeescript-like dialect using JS under the hood (though they'd probably optimize even better if you could implement them natively instead of in JS).
2012/3/14 Alan Kay <[email protected]> > Hi Scott -- > > 1. I will see if I can get one of these scanned for you. Moore tended to > publish in journals and there is very little of his stuff available on line. > > 2.a. "if (a<b) { ... }" is easier to read than "if a<b then ..."? There is > no hint of the former being tweaked for decades to make it easier to read. > > Several experiments from the past cast doubt on the rest of the idea. At > Disney we did a variety of "code display" generators to see what kinds of > transformations we could do to the underlying Smalltalk (including > syntactic) to make it something that could be subsetted as a "growable path > from Etoys". > > We got some good results from this (and this is what I'd do with > Javascript in both directions -- Alex Warth's OMeta is in Javascript and is > quite complete and could do this). > > However, the showstopper was all the parentheses that had to be rendered > in tiles. Mike Travers at MIT had done one of the first tile based editors > for a version of Lisp that he used, and this was even worse. > > More recently, Jens Moenig (who did SNAP) also did a direct renderer and > editor for Squeak Smalltalk (this can be tried out) and it really seemed to > be much too cluttered. > > One argument for some of this, is "well, teach the kids a subset that > doesn't use so many parens ...". This could be a solution. > > However, in the end, I don't think Javascript semantics is particularly > good for kids. For example, one of features of Etoys that turned out to be > very powerful for children and other Etoy programmers is the easy/trivial > parallel methods execution. And there are others in Etoys and yet others in > Scractch that are non-standard in regular programming languages but are > very powerful for children (and some of them are better than standard CS > language ideas). > > I'm encouraging you to do something better (that would be ideal). Or at > least as workable. Giving kids less just because that's what an existing > language for adults has is not a good tactic. > > 2.c. Ditto 2.a. above > > 2.d. Ditto above above > > Cheers, > > Alan > > > > ------------------------------ > *From:* C. Scott Ananian <[email protected]> > *To:* Alan Kay <[email protected]> > *Cc:* IAEP SugarLabs <[email protected]>; Fundamentals of New > Computing <[email protected]>; Viewpoints Research <[email protected]> > *Sent:* Wednesday, March 14, 2012 10:25 AM > *Subject:* Re: [IAEP] [fonc] Barbarians at the gate! (Project Nell) > > On Wed, Mar 14, 2012 at 12:54 PM, Alan Kay <[email protected]> wrote: > > The many papers from this work greatly influenced the thinking about > personal computing at Xerox PARC in the 70s. Here are a couple: > > -- O. K. Moore, Autotelic Responsive Environments and Exceptional > Children, Experience, Structure and Adaptabilty (ed. Harvey), Springer, 1966 > -- Anderson and Moore, Autotelic Folk Models, Sociological Quarterly, 1959 > > > Thank you for these references. I will chase them down and learn as much > as I can. > > > 2. Separating out some of the programming ideas here: > > 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". > > > I probably need to clarify the reasoning in the paper for this point. > > "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. > > 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. > > b. Good idea to go all the way to the bottom with the children's language. > > 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. > > > 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.) > > 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). > > > 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. > > 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. > > 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. > > I make these comments because I think your project is a good idea, on the > right track, and needs to be done > > > Thank you. I'll keep your encouragement in mind during the hard work of > implementation. > --scott > > -- > ( http://cscott.net ) > > > > _______________________________________________ > IAEP -- It's An Education Project (not a laptop project!) > [email protected] > http://lists.sugarlabs.org/listinfo/iaep >
_______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
