Re: [fonc] HotDraw's Tool State Machine Editor
The idea of using a grammar to create a user interface goes back at least as far as Engelbart's AHI group. They used a distant past cousin of OMeta (called Tree Meta) to do this. Ca. 1966. One of the first systems to specify and make graphical grammars (and UIs) via user interactions was William Newman's The Reaction Handler PhD thesis about the same time. (William is the Newman of Newman and Sproull). It's worthwhile to contemplate that a state machine (recursive or not) is the opposite of modeless -- it is the epitome of modes. So this is not a great way to specify a really nice modeless interface (because you have to draw arrows outward from pretty much every state to pretty much every other state). Modeless at PARC meant you don't have to explicitly back out of your current 'mode' to initiate any other command. Cheers, Alan From: Benoît Fleury benoit.fle...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Sent: Sat, July 23, 2011 11:05:49 PM Subject: [fonc] HotDraw's Tool State Machine Editor Hi, I found HotDraw's tool state machine editor [1] very interesting as a graphical editor for a syntax-directed translator. The state machine transforms a stream of mouse events into a stream of commands on the structured drawing. Did I push the analogy too far? I was wondering if anyone knows similar examples of graphical editor for grammars? Moreover, we didn't find (yet) a good metaphor for writing programs in general purpose programming language in a graphical editor. Do you think that might change with domain specific languages? Thank you to everyone on this list for the very interesting discussions and links. - Benoit [1] http://st-www.cs.illinois.edu/users/brant/HotDraw/Conversion.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] Re: [squeak-dev] [ANN] Alan Kay to talk about Next steps for qualitatively improving programming at HPI in Potsdam
Dr. Kay, Thank you for giving this talk. Do you recall the list of papers Bob Barton instructed you to read, learn, and understand in 1966? Can you share that list of papers with us? On Jul 23, 2011, at 1:38, Alan Kay alan.n...@yahoo.com wrote: Converting the file to something generally playable is fine with me, and you have my permission to do so (insofar as I have any rights to the talk heh heh ...) Cheers, Alan From: Hans-Martin Mosner h...@heeg.de To: Fundamentals of New Computing fonc@vpri.org Sent: Fri, July 22, 2011 11:27:12 PM Subject: Re: [fonc] Re: [squeak-dev] [ANN] Alan Kay to talk about Next steps for qualitatively improving programming at HPI in Potsdam Am 23.07.2011 04:47, schrieb Juan Vuletich: Casey Ransberger wrote: I did this dance too... Hmm... Seems the Mac installer comes with some kind of translation tool that's advertised to be able to output MPEG, maybe we can use that to save others the trouble of installing the Real client. If I figure out that I can handle the conversion without spending any money, would folks have interest in the artifact produced? This is a fun talk, I'm only about halfway through it, but I must admit having cracked up when he said, (and I have to paraphrase, because I don't have it in front of me,) ...if we were physicists, and we didn't understand what Newton did [slight dramatic pause] we should be shot. LOL! I'd really like to have it in my local disk, and in any format that lets me pause and resume, or go back to listen to some part again! Cheers, Juan Vuletich I'm currently converting it to AVI files, could make them available when that is ok with HPI (don't want to infringe on any rights). Cheers, Hans-Martin ___ 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] Re: [squeak-dev] [ANN] Alan Kay to talk about Next steps for qualitatively improving programming at HPI in Potsdam
Wow, what a question! Let me ponder this. I can certainly come up with a few of them. The class was actually taught starting Jan 1967 (I entered grad school a few months before this), so all the papers were from 1966 or earlier. For example, a big deal back then was the design and implementation of programming languages. One of the things on his list was to read a book of papers that had been gathered by (Stanley?) Fox from the UK. I recall that some of the papers in this book were classics by Strachey and Landin on foundations of programming languages, lambda calculus equivalents of Algol, etc. I recall that most of the papers in this slim book were very good. Another book on his list was by Iliffe (who among other things was the designer of the Rice University computer, an early one using keywords which were called Descriptors on the -- even earlier -- B5000). This book was about a new machine design of his. Another book on his list was A Programming Language by Iverson. This was before there were any real implementations of what we now call APL, and there was much discussion about how to implement it in a reasonable way. McCarthy's Lisp 1.5 Manual van Wijngarten's A Generalization of Algol Wirth's paper of the same name (and drawn from the above), ... and his very good paper with Weber on Euler -- which used a B5000-like byte-coded interpreter (what some would call a VM today) -- though it was anticipated in a much stronger way by the B5000 itself. The first Simula (I) paper by Nygaard and Dahl (Sept 1966 in CACM -- which was a very good source in those days). The papers by Irons, Floyd, Evans, Shorre, and many others about how to make syntax directed parsers, and how to think about them. There were also Wirth's Systems Programming Notes from his course at Stanford. Randall and Russell's classic book about their Algol Compiler/Interpreter system for the KDF9 computer (still a very good set of ideas today). Quite a few papers in The Annual Review of Automatic Programming. Knuth's notes and drafts for what was originally planned to be one book. Anatole Holt's notes on Petrie Nets and Occurrence Systems Barton liked to be mysterious about his own work and did not include any of his own writings in this list. But I tracked much of it down. I also had learned the B5000 as my 3rd machine while in the Air Force a few years earlier, so I had some sense of it. However, I did not appreciate many of the great ideas in it until I started actually wrestling with systems design (and had Sketchpad and the first Simula for context). Barton is probably the most deserving computer scientist who never was given the Turing Award (this was a real miscarriage, though he did receive the first Eckert-Mauchly Award for HW Architecture). And tons more! (Many students today would think this to be a lot for a one semester course -- but this kind of density was pretty common back then where there was a certain amount of filtering and selection done in grad school). For a more general idea of what the ARPA research community thought about computing, take a look at the special issue on Information, Scientific American, Sept 1966. Each article was written by the best person in each area -- and the whole gives a sense of what had been done up to 1966 (and for me, what had been done by my mentors and inspirators before I went to grad school). I hope this will serve for now Cheers, Alan From: Christopher Bratlien chrisbratl...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Cc: Fundamentals of New Computing fonc@vpri.org Sent: Sun, July 24, 2011 1:59:02 AM Subject: Re: [fonc] Re: [squeak-dev] [ANN] Alan Kay to talk about Next steps for qualitatively improving programming at HPI in Potsdam Dr. Kay, Thank you for giving this talk. Do you recall the list of papers Bob Barton instructed you to read, learn, and understand in 1966? Can you share that list of papers with us? On Jul 23, 2011, at 1:38, Alan Kay alan.n...@yahoo.com wrote: Converting the file to something generally playable is fine with me, and you have my permission to do so (insofar as I have any rights to the talk heh heh ...) Cheers, Alan From: Hans-Martin Mosner h...@heeg.de To: Fundamentals of New Computing fonc@vpri.org Sent: Fri, July 22, 2011 11:27:12 PM Subject: Re: [fonc] Re: [squeak-dev] [ANN] Alan Kay to talk about Next steps for qualitatively improving programming at HPI in Potsdam Am 23.07.2011 04:47, schrieb Juan Vuletich: Casey Ransberger wrote: I did this dance too... Hmm... Seems the Mac installer comes with some kind of translation tool that's advertised to be able to output MPEG, maybe we can use that to save others the trouble of installing the Real client. If I figure out that I can handle the conversion without spending any money, would folks have interest in the artifact produced?
Re: [fonc] Alan Kay talk at HPI in Potsdam
Hi Alan, as usual, it was inspiring talking to your colleagues and hearing you speak at Potsdam. I think I finally got the Model-T image, which resonated with my fondness for Objective-C: a language that a 17 year old with no experience with compilers or runtimes can implement and that manages to boil down dynamic OO/messaging to a single special function can't be all bad :-) There was one question I had on the scaling issue that would not have fitted in the QA: while praising the design of the Internet, you spoke less well of the World Wide Web, which surprised me a bit. Can you elaborate? Thanks, Marcel On Jul 22, 2011, at 6:29 , Alan Kay wrote: To All, This wound up being a talk to several hundred students, so most of the content is about ways to think about things, with just a little about scaling and STEPS at the end. Cheers, Alan ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alan Kay talk at HPI in Potsdam
Hi Marcel I think I've already said a bit about the Web on this list -- mostly about the complete misunderstanding of the situation the web and browser designers had. All the systems principles needed for a good design were already extant, but I don't think they were known to the designers, even though many of them were embedded in the actual computers and operating systems they used. The simplest way to see what I'm talking about is to notice the many-many things that could be done on a personal computer/workstation that couldn't be done in the web browser running on the very same personal computer/workstation. There was never any good reason for these differences. Another way to look at this is from the point of view of separation of concerns. A big question in any system is how much does 'Part A' have to know about 'Part B' (and vice versa) in order to make things happen? The web and browser designs fail on this really badly, and have forced set after set of weak conventions into larger and larger, but still weak browsers and, worse, onto zillions of web pages on the net. Basically, one of the main parts of good systems design is to try to find ways to finesse safe actions without having to know much. So -- for example -- Squeak runs everywhere because it can carry all of its own resources with it, and the OS processes/address-spaces allow it to run safely, but do not have to know anything about Squeak to run it. Similarly Squeak does not have to know much to run on every machine - just how to get events, a display buffer, and to map its file conventions onto the local ones. On a bare machine, Squeak *is* the OS, etc. So much for old ideas from the 70s! The main idea here is that a windowing 2.5 D UI can compose views from many sources into a page. The sources can be opaque because they can even do their own rendering if needed. Since the sources can run in protected address-spaces their actions can be confined, and we the mini-OS running all this do not have to know anything about them. This is how apps work on personal computers, and there is no reason why things shouldn't work this way when the address-spaces come from other parts of the net. There would then be no difference between local and global apps. Since parts of the address spaces can be externalized, indexing as rich (and richer) to what we have now still can be done. And so forth. The Native Client part of Chrome finally allows what should have been done in the first place (we are now about 20+ years after the first web proposals by Berners-Lee). However, this approach will need to be adopted by most of the already existing multiple browsers before it can really be used in a practical way in the world of personal computing -- and there are signs that there is not a lot of agreement or understanding why this would be a good thing. The sad and odd thing is that so many people in the computer field were so lacking in systems consciousness that they couldn't see this, and failed to complain mightily as the web was being set up and a really painful genii was being let out of the bottle. As Kurt Vonnegut used to say And so it goes. Cheers, Alan From: Marcel Weiher marcel.wei...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Cc: Alan Kay alan.n...@yahoo.com Sent: Sun, July 24, 2011 5:39:26 AM Subject: Re: [fonc] Alan Kay talk at HPI in Potsdam Hi Alan, as usual, it was inspiring talking to your colleagues and hearing you speak at Potsdam. I think I finally got the Model-T image, which resonated with my fondness for Objective-C: a language that a 17 year old with no experience with compilers or runtimes can implement and that manages to boil down dynamic OO/messaging to a single special function can't be all bad :-) There was one question I had on the scaling issue that would not have fitted in the QA: while praising the design of the Internet, you spoke less well of the World Wide Web, which surprised me a bit. Can you elaborate? Thanks, Marcel On Jul 22, 2011, at 6:29 , Alan Kay wrote: To All, This wound up being a talk to several hundred students, so most of the content is about ways to think about things, with just a little about scaling and STEPS at the end. Cheers, Alan___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] HotDraw's Tool State Machine Editor
Hi Dr Kay, thank you for the pointer to Newman's work I was not aware of. Regarding the state machine, Engelbart already pointed out that it was not a good model for user control language in [1]. In the first attempt, the control language was described as a finite state machine, and the language allowed a formal textual definition of such a machine. [...] It was originally thought that such an approach was adequate for the definition of user-system control languages. But, to paraphrase John McCarthy, the model is metaphysically adequate, but epistemologically inadequate. Implementation revealed that the dialogue is a non-Markovian (nonstochastic, historically dependent) process on the part of both the machine and the user, and accurate characterization as a finite state machine results in so many states that the model is useless. A better model is a two-stack automaton with a small number of immediate-access storage registers. I didn't encounter a lot of systems like NLS/AUGMENT during my time at a french engineer school. I guess the situation is similar to US universities. I'm trying now to catch up and was wondering if there are other software systems built using the same principles and techniques (collection of domain specific languages). I, of course, know already about Franck and the STEPS project. Thank you again for the pointers. - Benoit [1] Development of a multidisplay, time-shared computer facility and computer-augmented management-system research (Final Report), http://bitsavers.org/pdf/sri/arc/Development_of_a_Multidisplay_Time-Shared_Computer_Facility_Apr68.pdf On Sat, Jul 23, 2011 at 11:39 PM, Alan Kay alan.n...@yahoo.com wrote: The idea of using a grammar to create a user interface goes back at least as far as Engelbart's AHI group. They used a distant past cousin of OMeta (called Tree Meta) to do this. Ca. 1966. One of the first systems to specify and make graphical grammars (and UIs) via user interactions was William Newman's The Reaction Handler PhD thesis about the same time. (William is the Newman of Newman and Sproull). It's worthwhile to contemplate that a state machine (recursive or not) is the opposite of modeless -- it is the epitome of modes. So this is not a great way to specify a really nice modeless interface (because you have to draw arrows outward from pretty much every state to pretty much every other state). Modeless at PARC meant you don't have to explicitly back out of your current 'mode' to initiate any other command. Cheers, Alan From: Benoît Fleury benoit.fle...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Sent: Sat, July 23, 2011 11:05:49 PM Subject: [fonc] HotDraw's Tool State Machine Editor Hi, I found HotDraw's tool state machine editor [1] very interesting as a graphical editor for a syntax-directed translator. The state machine transforms a stream of mouse events into a stream of commands on the structured drawing. Did I push the analogy too far? I was wondering if anyone knows similar examples of graphical editor for grammars? Moreover, we didn't find (yet) a good metaphor for writing programs in general purpose programming language in a graphical editor. Do you think that might change with domain specific languages? Thank you to everyone on this list for the very interesting discussions and links. - Benoit [1] http://st-www.cs.illinois.edu/users/brant/HotDraw/Conversion.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] Alan Kay talk at HPI in Potsdam
Hello Dr. Alan, Since access to fonc list archives is closed to members, would you allow me to publish your email below elsewhere for public access? It is the most rich and informative critique I've found about the web (plus the non-authoring nature of the browser you've mentioned before). Cheers, Thiago On Sunday 24 July 2011 14:24:20 Alan Kay wrote: Hi Marcel I think I've already said a bit about the Web on this list -- mostly about the complete misunderstanding of the situation the web and browser designers had. All the systems principles needed for a good design were already extant, but I don't think they were known to the designers, even though many of them were embedded in the actual computers and operating systems they used. The simplest way to see what I'm talking about is to notice the many-many things that could be done on a personal computer/workstation that couldn't be done in the web browser running on the very same personal computer/workstation. There was never any good reason for these differences. Another way to look at this is from the point of view of separation of concerns. A big question in any system is how much does 'Part A' have to know about 'Part B' (and vice versa) in order to make things happen? The web and browser designs fail on this really badly, and have forced set after set of weak conventions into larger and larger, but still weak browsers and, worse, onto zillions of web pages on the net. Basically, one of the main parts of good systems design is to try to find ways to finesse safe actions without having to know much. So -- for example -- Squeak runs everywhere because it can carry all of its own resources with it, and the OS processes/address-spaces allow it to run safely, but do not have to know anything about Squeak to run it. Similarly Squeak does not have to know much to run on every machine - just how to get events, a display buffer, and to map its file conventions onto the local ones. On a bare machine, Squeak *is* the OS, etc. So much for old ideas from the 70s! The main idea here is that a windowing 2.5 D UI can compose views from many sources into a page. The sources can be opaque because they can even do their own rendering if needed. Since the sources can run in protected address-spaces their actions can be confined, and we the mini-OS running all this do not have to know anything about them. This is how apps work on personal computers, and there is no reason why things shouldn't work this way when the address-spaces come from other parts of the net. There would then be no difference between local and global apps. Since parts of the address spaces can be externalized, indexing as rich (and richer) to what we have now still can be done. And so forth. The Native Client part of Chrome finally allows what should have been done in the first place (we are now about 20+ years after the first web proposals by Berners-Lee). However, this approach will need to be adopted by most of the already existing multiple browsers before it can really be used in a practical way in the world of personal computing -- and there are signs that there is not a lot of agreement or understanding why this would be a good thing. The sad and odd thing is that so many people in the computer field were so lacking in systems consciousness that they couldn't see this, and failed to complain mightily as the web was being set up and a really painful genii was being let out of the bottle. As Kurt Vonnegut used to say And so it goes. Cheers, Alan From: Marcel Weiher marcel.wei...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Cc: Alan Kay alan.n...@yahoo.com Sent: Sun, July 24, 2011 5:39:26 AM Subject: Re: [fonc] Alan Kay talk at HPI in Potsdam Hi Alan, as usual, it was inspiring talking to your colleagues and hearing you speak at Potsdam. I think I finally got the Model-T image, which resonated with my fondness for Objective-C: a language that a 17 year old with no experience with compilers or runtimes can implement and that manages to boil down dynamic OO/messaging to a single special function can't be all bad :-) There was one question I had on the scaling issue that would not have fitted in the QA: while praising the design of the Internet, you spoke less well of the World Wide Web, which surprised me a bit. Can you elaborate? Thanks, Marcel On Jul 22, 2011, at 6:29 , Alan Kay wrote: To All, This wound up being a talk to several hundred students, so most of the content is about ways to think about things, with just a little about scaling and STEPS at the end. Cheers, Alan ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
