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 <shaunxc...@gmail.com>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 <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
>
>
--
-Brian T. Rice
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
