I was also fascinated by "He (and his wife) wound up making an animated movie to show people who didn't know about lambda expressions and combinators (which was pretty much everyone in CS in those days) what they were and how they reduced." Would love to show this to Phil Wadler, who every year has his students draw pictures of "the very strange creature with a head and a tail, whose tail may have a head and a tail" [1].
Bret Victor created Alligator Eggs! [2] [3] in response to Phil telling him about it. [1] http://wadler.blogspot.com/2010/11/list-is-odd-creature-take-5.html [2] http://wadler.blogspot.com/2007/05/oh-no-alligators.html [3] http://lambda-the-ultimate.org/node/3485 On Fri, Sep 2, 2011 at 11:41 AM, shaun gilchrist <[email protected]>wrote: > For anyone else who was captivated by: "Denis came up with a nice > little language that had a bit of an APL feeling for humans to program > this system in" - here is a link to the 184 page paper describing > "DCPL": > http://content.lib.utah.edu/cdm4/item_viewer.php?CISOROOT=/ir-main&CISOPTR=60083 > -shaun > > > On Fri, Sep 2, 2011 at 9:23 AM, Alan Kay <[email protected]> wrote: > > Hi Jecel > > I think both these sections were reactions to some of the current > hardware, > > and hardware problems of the time. > > > > I remember the second one better than the first. In those days cutting > dies > > out of the wafters often damaged them, and the general yield was not > great > > even before cutting the die out. This idea was to lay down regions of > memory > > on the wafer, run bus metalization over them, test them, and zap a few > bits > > if they didn't work. The key here was that the working ones would each > have > > a register that had its "name" (actually its base address and range) and > all > > could look at the bus to see if their address came up. If it did, it > would > > seize the bus and do what ever. So this was a kind of distributed small > > pages and MMUs scheme. And the yield would be much higher because the > wafers > > remained intact. I don't think any of these tradeoffs obtain today, > though > > one could imagine other kinds of schemes for distributed memory and > memory > > management that would be more sensible than current schemes. > > The first one I really don't remember. But it probably was partially the > > result of the head per track small disk that the FLEX machine used -- and > > probably was influenced by Paul Rovner's scheme at Lincoln Labs for doing > > Jerry Feldman's software "associative triples memory". > > > > I think this was not about Denis Seror's later and really interesting > thesis > > (under Barton) to make a "lambda calculus machine" -- really a > "combinator > > machine" (to replace variables by paths) and to have the computation on > the > > disk and just pull in and reduce as possible as the disk zoomed by. All > was > > done in parallel and eventually all would be reduced. Denis came up with > a > > nice little language that had a bit of an APL feeling for humans to > program > > this system in. He (and his wife) wound up making an animated movie to > show > > people who didn't know about lambda expressions and combinators (which > was > > pretty much everyone in CS in those days) what they were and how they > > reduced. > > There's no question that Bob Taylor was the prime key for PARC (and he > also > > had paid for most of our PhDs in the 60s when he was an ARPA funder). > > Cheers, > > Alan > > > > ________________________________ > > From: Jecel Assumpcao Jr. <[email protected]> > > To: Alan Kay <[email protected]> > > Cc: Fundamentals of New Computing <[email protected]> > > Sent: Thursday, September 1, 2011 3:17 PM > > Subject: a little more FLEXibility (was: [fonc] Re: Ceres and Oberon) > > > > Alan, > > > >> The Flex Machine was "the omelet you have to throw away to clean the > pan", > >> so I haven't put any effort into saving that history. > > > > Fair enough! Having the table of contents but not the text made me think > > that perhaps the section B.6.b.ii The Disk as a Serial "Associative > > Memory" and B.6.c. An Associativeley Mapped LSI Memory might be > > interesting in light of Ian's latest paper. Or the first part might be > > more related to OOZE instead. > > > >> But there were "4 or 5" pretty good things and "4 or 5" really bad > things > >> that > >> helped the Alto-Smalltalk effort a few years later. > > > > Was being able to input drawings one of the good things? There was one > > Lisp GUI that put a lot of effort into allowing you to input objects > > instead of just text. It did that by outputting text but keeping track > > of where it came from. So if you pointed to the text generated by > > listing the contents of a disk directory while there was some program > > waiting for input, that program would read the actual entry object. > > > > It is frustrating for me that while the Squeak VM could easily handle an > > expression like > > > > myView add: <yellowEllipseMorph> copy. > > > > I have no way of typing that. I can't use any object as a literal nor as > > input. In Etoys I can get close enough by getting a tile representing > > the yellowEllpiseMorph from its halo and use that in expressions. In > > Self I could add a constant slot with some easy to type value, like 0, > > and then drag the arrow from that slot to point to the object I really > > wanted. It was a bit indirect but it worked and I used this a lot. The > > nice thing about having something like this is that you never need > > global variable again. > > > >> I'd say that the huge factors after having tried to do one of these were > >> two > >> geniuses: Chuck Thacker (who was an infinitely better hardware designer > >> and > >> builder than I was), and Dan Ingalls (who was infinitely better at most > >> phases > >> of software design and implementation than I was). > > > > True. You were lucky to have them, though perhaps we might say Bob > > Taylor had built that luck into PARC. > > > > -- Jecel > > > > > > > > > > _______________________________________________ > > fonc mailing list > > [email protected] > > http://vpri.org/mailman/listinfo/fonc > > > > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
