[IAEP] [fonc] Barbarians at the gate! (Project Nell)

[Jameson Quinn]

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 <alan.nemo at yahoo.com>

> 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 <cscott at laptop.org>
> *To:* Alan Kay <alan.nemo at yahoo.com>
> *Cc:* IAEP SugarLabs <iaep at lists.sugarlabs.org>; Fundamentals of New
> Computing <fonc at vpri.org>; Viewpoints Research <all at vpri.org>
> *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 <alan.nemo at yahoo.com> 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!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20120314/3f8cab55/attachment-0001.html>