Well, it was very much a "mythical beast" even on paper -- and you really have
to implement programming languages and make a lot of things with them to be
able to assess them ....
But -- basically -- since meeting Seymour and starting to think about children
and programming, there were eight systems that I thought were really nifty and
cried out to be unified somehow:
1. Joss
2. Lisp
3. Logo -- which was originally a unification of Joss and Lisp, but I thought
more could be done in this direction).
4. Planner -- a big set of ideas (long before Prolog) by Carl Hewitt for
logic programming and "pattern directed inference" both forward and backwards
with backtracking)
5. Meta II -- a super simple meta parser and compiler done by Val Schorre at
UCLA ca 1963
6. IMP -- perhaps the first real extensible language that worked well -- by
Ned Irons (CACM, Jan 1970)
7. The Lisp-70 Pattern Matching System -- by Larry Tesler, et al, with some
design ideas by me
8. The object and pattern directed extension stuff I'd been doing previously
with the Flex Machine and afterwards at SAIL (that also was influenced by Meta
II)
One of the schemes was to really make the pattern matching parts of this "work
for everything" that eventually required "invocations and binding". This was
doable semantically but was a bear syntactically because of the different
senses of what kinds of matching and binding were intended for different
problems. This messed up the readability and desired "simple things should be
simple".
Examples I wanted to cover included simple translations of languages (English
to Pig Latin, English to French, etc. some of these had been done in Logo), the
Winograd robot block stacking and other examples done with Planner, the making
of the language the child was using, message sending and receiving, extensions
to Smalltalk-71, and so forth.
I think today the way to try to do this would be with a much more graphical UI
than with text -- one could imagine tiles that would specify what to match, and
the details of the match could be submerged a bit.
More recently, both OMeta and several of Ian's matchers can handle multiple
kinds of matching with binding and do backtracking, etc., so one could imagine
a more general language that could be based on this.
On the other hand, trying to stuff 8 kinds of language ideas into one new
language in a graceful way could be a siren's song of a goal.
Still ....
Cheers,
Alan
>________________________________
> From: shaun gilchrist <shaunxc...@gmail.com>
>To: fonc@vpri.org
>Sent: Wednesday, March 14, 2012 11:38 AM
>Subject: Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
>
>
>Alan,
>
>"I would go way back to the never implemented Smalltalk-71"
>
>Is there a formal specification of what 71 should have been? I have only ever
>read about it in passing reference in the various histories of smalltalk as a
>step on the way to 72, 76, and finally 80.
>
>I am very intrigued as to what sets 71 apart so dramatically. -Shaun
>
>
>On Wed, Mar 14, 2012 at 12:29 PM, Alan Kay <alan.n...@yahoo.com> wrote:
>
>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 <csc...@laptop.org>
>>>To: Alan Kay <alan.n...@yahoo.com>
>>>Cc: IAEP SugarLabs <i...@lists.sugarlabs.org>; Fundamentals of New Computing
>>><fonc@vpri.org>; Viewpoints Research <a...@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.n...@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 )
>>>
>>>
>>>
>>_______________________________________________
>>fonc mailing list
>>fonc@vpri.org
>>http://vpri.org/mailman/listinfo/fonc
>>
>>
>
>_______________________________________________
>fonc mailing list
>fonc@vpri.org
>http://vpri.org/mailman/listinfo/fonc
>
>
>_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
