Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
ent 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 >> *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 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> 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 >> *To:* Alan Kay >> *Cc:* IAEP SugarLabs ; Fundamentals of New >> Computing ; Viewpoints Research >> *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 wrote: >> >> The many papers fro
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
On Fri, Mar 16, 2012 at 8:26 AM, Ryan Mitchley wrote: > ** > On 15/03/2012 14:20, Alan Kay wrote: > > Alex Warth did both a standard Prolog and an English based language one > using OMeta in both Javascript, and in Smalltalk. > > > > I must have a look at these. Thanks for all of the references. I was > working my way through Warren Abstract Machine implementation details but > it was truly headache-inducing (for me, anyway). > > A book I keep meaning to get is "Paradigms of Artificial Intelligence > Programming: Case Studies in Common Lisp", which describes a Prolog-like > implementation (and much more) in Lisp. > > The Minsky book would be very welcome! > Another Lisp approach is Dan Friedman, Oleg Kiselyov, and William Byrd's miniKanren system. It's purely functional and is incredibly only about 200 lines of Scheme. Even more surprising is that the minimal design is *stunningly* efficient. The beauty of such a tiny system is that it's simple to improve. They recently added constraint logic programming over any domain with about 600-700 more lines of code. David ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
The WAM and other fast schemes for Prolog are worth looking at. But the Javascript version that Alex did using his and Stephen Murrell's design for compact Prolog semantics (about 90 lines of Javascript code) is very illuminating for those interested in "the logic of logic". But Prolog has always had some serious flaws -- so it is worth looking at cleaned up and enhanced versions (such as the Datalog with negation and time variants I've mentioned). Also, Shapiro's Concurrent Prolog did quite a cleanup long ago. I particularly liked the arguments of Bill Kornfield's "Prolog With Equality" paper from many years ago -- this is one of several seminal perspectives on where this kind of language should be taken. The big flaw with most of the attempts I've see to combine "Logic and Objects" is that what should be done about state is not taken seriously. The first sins were committed in Prolog itself by allowing a non-automatic undoable "assert". I've argued that it would be much better to use takeoffs of "situation calculus" and "pseudotime" to allow perfect deductions/implications/functional-relationships to be computed while still moving from one context to another to have a model of before, now, and after. These are not new ideas, and I didn't have them first. Cheers, Alan > > From: Ryan Mitchley >To: Fundamentals of New Computing >Sent: Friday, March 16, 2012 5:26 AM >Subject: Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell) > > >On 15/03/2012 14:20, Alan Kay wrote: >Alex Warth did both a standard Prolog and an English based language one using >OMeta in both Javascript, and in Smalltalk. >> >> >> >I must have a look at these. Thanks for all of the references. I was working my way through Warren Abstract Machine implementation details but it was truly headache-inducing (for me, anyway). > >A book I keep meaning to get is "Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp", which describes a Prolog-like implementation (and much more) in Lisp. > >The Minsky book would be very welcome! > > >___ >fonc mailing list >fonc@vpri.org >http://vpri.org/mailman/listinfo/fonc > > >___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
On 15/03/2012 14:20, Alan Kay wrote: Alex Warth did both a standard Prolog and an English based language one using OMeta in both Javascript, and in Smalltalk. I must have a look at these. Thanks for all of the references. I was working my way through Warren Abstract Machine implementation details but it was truly headache-inducing (for me, anyway). A book I keep meaning to get is "Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp", which describes a Prolog-like implementation (and much more) in Lisp. The Minsky book would be very welcome! ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
Hi Shaun I'll take a look at this when I get a chance (probably a few weeks from now). As I think I mentioned back in 1993 when the history was written, I had to try to do a recreation of this because I couldn't find the original one pager, and there are likely to be bugs. In the original (done in '72) I committed the classic blunder of trying to be too clever and to accomplish too many goals in this one project -- in particular I wanted to show how this could be actually done on a sequential machine with a small memory. So instead of writing a recursive program in a recursive language using cons pairs, I wrote it as a loop with an explicit activation record structure, "states" for indicating where the different jumps to "eval" should be returned to, and arrays and indices instead of lists.This was like trying to write the second illustration of the Lisp interpreter (how it really ran on the 709) that is given in the Lisp 1.5 manual. Another big complication in the original was that I tried to have "returns" be symmetric with sends (by interpreting the results in a similar fashion). I also wanted this to be "network like" and "language like" at the same time, "function like" and "object like", "dynamically extensible with nice syntax", etc. etc. I wanted to use the Dave Fisher extensible control ideas as well as extensible forms. I would have been much better off to have written it McCarthy-style first and then hand-compiled it to its loop and jump form (and John's several versions had bugs because it was hard to hold the whole thing in one's head, even in his amazing head). Or, even better, to have written it in the style of the Flex Machine, which was a takeoff on the way Wirth did his Euler byte-code compiler and B5000-like interpreter with a better parsing scheme. This latter would have been clearer -- and more like the eventual Smalltalk-76, but I was pretty sure that it wouldn't fit into a half page (or even one page). Wirth's didn't, even though it was nice and small. One way to recreate this is to take a look at the logic of the approach, which in Lisp terms would be to use something like FEXPs to be able to look at raw expressions, and to APPLY results from functions to the rest of an expression list to avoid have to parenthesize every expression individually. Once looked at this way the functions can be seen as also being like the "meta-linguistic procedures" of Meta II (and you have something that is like a parser being used as a direct interpreter). Meta II could make itself (but not its VM) in about half a page, so this was suggestive also. A key to this last point is that it meant that the "ways of matching and binding" could be written as separate functions and did not have to be part of the actual interpreter. These functions would have to use the Fisher environment context to allow this to be done, and the idea was that one was making/extending "too powerful" control environments to make "still powerful but safe" control and environment structures. The "grammar as interface" scheme also has some of the flavor of Irons' IMP. Objects would be like closures and you would be unifying functions and objects. In abstraction, one would thus have a "message send" to an object just notify the object that a message is there and to give the object just the pointer to the message. The object would then try to recognize and receive the message via pattern matching/parsing. This preserves complete encapsulation and implements a real "Internet" style of sending and receiving messages between perfectly protected virtual machines. "Extensible languages" are created via new object classes that implement new grammars. The logic of this approach heavily influenced the subsequent development of Hewitt's Actors formalisms (though they didn't seem to understand that the "APPLY" technique didn't "consume" anything -- so the metaphor I unfortunately used of "objects eating their messages" was vivid but not accurate and led to misinterpretations). Dan Ingalls was a much better programmer than I was, so it only took him about a month to reimplement the "one-pager" in a real form to produce a real language. This history was interestingly like that of Lisp, where McCarthy was able to find a nice model, and Steve Russell reimplemented it to make a working Lisp. Looking back: "Wow, why did I try to win the bet that way?" Cheers, Alan > > From: shaun gilchrist >To: Fundamentals of New Computing >Sent: Thursday, March 15, 2012 9:28 PM >Subject: Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell) > > >Alan,
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
hing 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 > *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 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 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 > *To:* Alan Kay > *Cc:* IAEP SugarLabs ; Fundamentals of New > Computing ; Viewpoints Research > *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 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 >
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
The theory Algebra of Communicating Processes (ACP) offers non-determinism (as in Meta II) plus concurrency. I will present a paper on extending Scala with ACP next month at Scala Days 2012. For an abstract, see http://days2012.scala-lang.org/node/92 A non-final version of the paper is at http://code.google.com/p/subscript/downloads/detail?name=SubScript-TR2012.pdf André Op 15 mrt. 2012, om 03:03 heeft Alan Kay het volgende geschreven: > 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 > 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 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 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. >
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
On Thu, Mar 15, 2012 at 10:55 AM, Alan Kay wrote: > It's in the book "Semantic Information Processing" that Marvin Minsky put > together in the mid 60s. I will get it scanned and send around (it is paired > with the even more class "Advice Taker" paper that led to Lisp ... Thanks Alan. That's very generous of you! wes ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
It's in the book "Semantic Information Processing" that Marvin Minsky put together in the mid 60s. I will get it scanned and send around (it is paired with the even more class "Advice Taker" paper that led to Lisp ... Cheers, Alan > > From: Wesley Smith >To: Alan Kay ; Fundamentals of New Computing > >Sent: Thursday, March 15, 2012 10:13 AM >Subject: Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell) > >On Thu, Mar 15, 2012 at 5:23 AM, Alan Kay wrote: >> You don't want to use assert because it doesn't get undone during >> backtracking. Look at the Alex Warth et al "Worlds" paper on the Viewpoints >> site to see a better way to do this. (This is an outgrowth of the "labeled >> situations" idea of McCarthy in 1963.) > >I found a reference to this paper in >http://arxiv.org/pdf/1201.2430.pdf . Looks like it's a paper called >"Situations, actions and causal laws". I'm not able to find any >PDF/online version. Anyone know how to get ahold of this document? > >thanks, >wes > > >___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
On Thu, Mar 15, 2012 at 5:23 AM, Alan Kay wrote: > You don't want to use assert because it doesn't get undone during > backtracking. Look at the Alex Warth et al "Worlds" paper on the Viewpoints > site to see a better way to do this. (This is an outgrowth of the "labeled > situations" idea of McCarthy in 1963.) I found a reference to this paper in http://arxiv.org/pdf/1201.2430.pdf . Looks like it's a paper called "Situations, actions and causal laws". I'm not able to find any PDF/online version. Anyone know how to get ahold of this document? thanks, wes ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
I'd recommend Logtalk ( http://en.wikipedia.org/wiki/Logtalk ) when thinking about Prolog-based systems. Yield Prolog ( http://sourceforge.net/projects/yieldprolog/ ) is an interesting embedding of Prolog into procedural languages using 'yield'. A little bit of syntactic sugar could probably go a long way towards integrating the two programming methodologies. JMatch ( http://www.cs.cornell.edu/Projects/jmatch/ ) is another interesting take on "backward execution". --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
Sure ... (and this is what Lisp-70 did also ... and a number of systems before it, etc.) Cheers, Alan > > From: Peter C. Marks >To: Fundamentals of New Computing >Sent: Thursday, March 15, 2012 6:09 AM >Subject: Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell) > > > >WRT: patterns, I wonder if the list is aware of the work by Barry Jay with his >Pattern Calculus, wherein he introduces patterns as first class citizens at >the lambda level. > > >Peter > > > >On Thu, Mar 15, 2012 at 8:23 AM, Alan Kay wrote: > >You don't want to use assert because it doesn't get undone during >backtracking. Look at the Alex Warth et al "Worlds" paper on the Viewpoints >site to see a better way to do this. (This is an outgrowth of the "labeled >situations" idea of McCarthy in 1963.) >> >> >>Cheers, >> >> >>Alan >> >> >> >> >>>____________________ >>> From: Ryan Mitchley >>> >>>To: Fundamentals of New Computing >>>Sent: Thursday, March 15, 2012 5:02 AM >>>Subject: Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell) >>> >>> >>>On 15/03/2012 13:01, Ryan Mitchley wrote: >>>> It still doesn't fit well with a procedural model, in common with Prolog, >>>>though. >>>> >>>> >>> >>>Although, it has to be said that a procedural approach can be faked with a >>>combination of assertion and forward chaining. >>> >>>e.g. >>> >>>IsASquare(X, Y) iff line(X, blah), angle(blahblah) etc. >>>assert IsASquare(100, 200). >>>(System goes ahead and forward chains all of the subgoals, asserting facts >>>and creating a square as specified. Excuse the made-up syntax.) >>> >>>Forward chaining doesn't come standard with micro-PROLOG (or Prolog), but >>>can be added. >>> >>> >>>Disclaimer: http://www.peralex.com/disclaimer.html >>> >>> >>>___ >>>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 > > >___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
WRT: patterns, I wonder if the list is aware of the work by Barry Jay with his Pattern Calculus <http://www-staff.it.uts.edu.au/~cbj/patterns/>, wherein he introduces patterns as first class citizens at the lambda level. Peter On Thu, Mar 15, 2012 at 8:23 AM, Alan Kay wrote: > You don't want to use assert because it doesn't get undone during > backtracking. Look at the Alex Warth et al "Worlds" paper on the Viewpoints > site to see a better way to do this. (This is an outgrowth of the "labeled > situations" idea of McCarthy in 1963.) > > Cheers, > > Alan > > -- > *From:* Ryan Mitchley > > *To:* Fundamentals of New Computing > *Sent:* Thursday, March 15, 2012 5:02 AM > *Subject:* Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell) > > On 15/03/2012 13:01, Ryan Mitchley wrote: > > It still doesn't fit well with a procedural model, in common with > Prolog, though. > > > > > > Although, it has to be said that a procedural approach can be faked with a > combination of assertion and forward chaining. > > e.g. > > IsASquare(X, Y) iff line(X, blah), angle(blahblah) etc. > assert IsASquare(100, 200). > (System goes ahead and forward chains all of the subgoals, asserting facts > and creating a square as specified. Excuse the made-up syntax.) > > Forward chaining doesn't come standard with micro-PROLOG (or Prolog), but > can be added. > > > Disclaimer: http://www.peralex.com/disclaimer.html > > > ___ > 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
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
You don't want to use assert because it doesn't get undone during backtracking. Look at the Alex Warth et al "Worlds" paper on the Viewpoints site to see a better way to do this. (This is an outgrowth of the "labeled situations" idea of McCarthy in 1963.) Cheers, Alan > > From: Ryan Mitchley >To: Fundamentals of New Computing >Sent: Thursday, March 15, 2012 5:02 AM >Subject: Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell) > >On 15/03/2012 13:01, Ryan Mitchley wrote: >> It still doesn't fit well with a procedural model, in common with Prolog, >>though. >> >> > >Although, it has to be said that a procedural approach can be faked with a >combination of assertion and forward chaining. > >e.g. > >IsASquare(X, Y) iff line(X, blah), angle(blahblah) etc. >assert IsASquare(100, 200). >(System goes ahead and forward chains all of the subgoals, asserting facts and >creating a square as specified. Excuse the made-up syntax.) > >Forward chaining doesn't come standard with micro-PROLOG (or Prolog), but can >be added. > > >Disclaimer: http://www.peralex.com/disclaimer.html > > >___ >fonc mailing list >fonc@vpri.org >http://vpri.org/mailman/listinfo/fonc > > >___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
Alex Warth did both a standard Prolog and an English based language one using OMeta in both Javascript, and in Smalltalk. Again, why just go with something that happens to be around? Why not try to make a language that fits to the users and the goals? A stronger version of this kind of language is Datalog, especially the "Datalog + Time" language -- called Daedalus -- used in the BOOM project at Berkeley. Cheers, Alan > > From: Ryan Mitchley >To: Fundamentals of New Computing >Sent: Thursday, March 15, 2012 4:01 AM >Subject: Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell) > >I wonder if micro-PROLOG isn't worth revisiting by someone: > >ftp://ftp.worldofspectrum.org/pub/sinclair/games-info/m/Micro-PROLOGPrimer.pdf > >You get pattern matching, backtracking and a "nicer" syntax than Prolog. It's >easy enough to extend with IsA and notions of classes of objects. It still >doesn't fit well with a procedural model, in common with Prolog, though. > >___ >fonc mailing list >fonc@vpri.org >http://vpri.org/mailman/listinfo/fonc > > >___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
On 15/03/2012 13:01, Ryan Mitchley wrote: It still doesn't fit well with a procedural model, in common with Prolog, though. Although, it has to be said that a procedural approach can be faked with a combination of assertion and forward chaining. e.g. IsASquare(X, Y) iff line(X, blah), angle(blahblah) etc. assert IsASquare(100, 200). (System goes ahead and forward chains all of the subgoals, asserting facts and creating a square as specified. Excuse the made-up syntax.) Forward chaining doesn't come standard with micro-PROLOG (or Prolog), but can be added. Disclaimer: http://www.peralex.com/disclaimer.html ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
I wonder if micro-PROLOG isn't worth revisiting by someone: ftp://ftp.worldofspectrum.org/pub/sinclair/games-info/m/Micro-PROLOGPrimer.pdf You get pattern matching, backtracking and a "nicer" syntax than Prolog. It's easy enough to extend with IsA and notions of classes of objects. It still doesn't fit well with a procedural model, in common with Prolog, though. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
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 >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 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>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 o
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
You can get around the idea of ubiquity of languages if you're prepared to build tiny easily understandable (in 5 minutes or less) micro languages. Consider "how to use iOS touch" as if it were a language and how easy it is to learn. Afterall, a user interface is simply a visual / behavioural language, right? ;-) Julian On 15/03/2012, at 11:34 AM, C. Scott Ananian wrote: > On Wed, Mar 14, 2012 at 6:02 PM, Jameson Quinn > wrote: > 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). > > I think you are underestimating the value of using a standard widely-deployed > language. I love languages as much as the next guy---but our previous > learning environment (Sugar) has had incredible difficulty getting local > support outside the US because it is written in *Python*. Python is "not a > commercially viable language" (not my words) and you can't even take > university classes in Python in many countries (say, Uruguay) because there > is no company behind it and no one who will give you a "certificate" for > having learned it. > > This is very sad, but the true state of affairs. > > JavaScript is not perfect, but at heart it is a functional object-oriented > language which is pretty darn close to Good Enough. There are huge benefits > to using a language which is supported by training materials all over the > web, university systems outside the US, etc, etc. > > I am open to *very* slight extensions to JavaScript -- OMeta/JS and > quasiquote might squeeze in -- but they have to be weighed against their > costs. Subsets are even more problematic -- once you start subsetting, then > you are throwing away compatibility with all the wealth of JavaScript > libraries out there, in addition to confusing potential contributors who are > trying to type in examples they found in some book. > --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
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
On Wed, Mar 14, 2012 at 6:02 PM, Jameson Quinn wrote: > 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). I think you are underestimating the value of using a standard widely-deployed language. I love languages as much as the next guy---but our previous learning environment (Sugar) has had incredible difficulty getting local support outside the US because it is written in *Python*. Python is "not a commercially viable language" (not my words) and you can't even take university classes in Python in many countries (say, Uruguay) because there is no company behind it and no one who will give you a "certificate" for having learned it. This is very sad, but the true state of affairs. JavaScript is not perfect, but at heart it is a functional object-oriented language which is pretty darn close to Good Enough. There are huge benefits to using a language which is supported by training materials all over the web, university systems outside the US, etc, etc. I am open to *very* slight extensions to JavaScript -- OMeta/JS and quasiquote might squeeze in -- but they have to be weighed against their costs. Subsets are even more problematic -- once you start subsetting, then you are throwing away compatibility with all the wealth of JavaScript libraries out there, in addition to confusing potential contributors who are trying to type in examples they found in some book. --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
I'm sure that if you took a pretty clean PEG grammar approach to composable mixfix phrasing and cues from Inform 7 and Ruby's Cucumber DSL, Smalltalk-71 would feel as real as any bytecode-native language. On Wed, Mar 14, 2012 at 11:38 AM, shaun gilchrist wrote: > 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 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> 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 >> *To:* Alan Kay >> *Cc:* IAEP SugarLabs ; Fundamentals of New >> Computing ; Viewpoints Research >> *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 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
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 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 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 > *To:* Alan Kay > *Cc:* IAEP SugarLabs ; Fundamentals of New > Computing ; Viewpoints Research > *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 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 --
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
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 > From: C. Scott Ananian >To: Alan Kay >Cc: IAEP SugarLabs ; Fundamentals of New Computing >; Viewpoints Research >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 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
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
On Wed, Mar 14, 2012 at 12:54 PM, Alan Kay 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
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
Hi Scott This seems like a plan that should be done and tried and carefully evaluated. I think the approach is good. It could be "not quite enough" to work, but it should give rise to a lot of useful information for further passes at this. 1. Psychologist O.K. Moore in the early 60s at Yale and elsewhere pioneered the idea of a "talking typewriter" to help children learn how to read via learning to write. This was first a grad student in a closet with a microphone simulating a smart machine -- but later the Edison division of McGraw-Hill made a technology that did some of these things. The significance of Moore's work is that he really thought things through, both with respect to what such a curriculum might be, but also to the nature of the whole environment made for the child. He first defined a *responsive environment* as one that: a. permits learners to explore freely b. informs learners immediately about the consequences of their actions c. is self-pacing, i.e. events happen within the environment at a rate determined by the learner d. permits the learners to make full use of their capacities to discover relations of various kinds e. has a structure such that learners are likely to make a series of interconnected discoveries about the physical, cultural or social world He called a responsive environment: “*autotelic*, if engaging in it is done for its own sake rather than for obtaining rewards or avoiding punishments that have no inherent connection with the activity itself”. By “discovery” he meant “gently guided discovery” in the sense of Montessori, Vygotsky, Bruner and Papert (i.e. recognizing that it is very difficult for human beings to come up with good ideas from scratch—hence the need for forms of guidance—but that things are learned best if the learner puts in the effort to make the final connections themselves—hence the need for forms of discovery. 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 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". 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. 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). 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 Best wishes Alan > > From: C. Scott Ananian >To: IAEP SugarLabs >Sent: Tuesday, March 13, 2012 4:07 PM >Subject: [IAEP] Barbarians at the gate! (Project Nell) > > >I read the following today: > > >"A healthy [project] is, confusingly, one at odds with itself. There is a >healthy part which is attempting to normalize and to create predictability, >and there needs to be another part that is tasked with building something new >that is going to disrupt and eventually destroy that normality." >(http://www.randsinrepose.com/archives/2012/03/13/hacking_is_important.html) > > >So, in this vein, I'd like to encourage Sugar-folk to read the short paper >Chris Ball, Michael Stone, and I just submitted (to IDC 2012) on Nell, our >design for XO-3 software for the reading project: > > > http://cscott.net/Publications/OLPC/idc2012.pdf > > >You're expected not to like it: t
