Notice: Undefined property: stdClass::$theme in /usr/local/src/drupal-5.1/includes/theme.inc on line 45
Visual | Don Hopkins

Visual

warning: Creating default object from empty value in /usr/local/src/drupal-5.1/modules/taxonomy/taxonomy.module on line 1364.

OLPC Visual Programming Languages for Education

Simon Forman's stuff about xerblin is fascinating, and I'm excited about where it's heading, and how we can incorporate ideas from eToys into Python! I like the idea of having visual meta-languages that are compiled into Python, which avoids the problems of editing Python text or parse trees directly, and can support simplified "kindergarten" languages as well as more advanced forms.

The drag-and-drop stack and code outliner ideas work well with PostScript, which is a stack based but lispy code=data dynamic language that easily supports smalltalk-like object oriented programming via PostScript's "dictionary stack". Python + Cairo is also a great platform for implementing that kind of stuff, with dynamic layout of hybrid text and outline graphics, which scales and zooms and supports direct manipulation of data structures!

Here's a paper about PSIBER (PostScript Interactive Bug Eradication Routines), a visual interface to the PostScript interpreter in NeWS, and some links to video demos, too. Sorry about the flashing and poor compression -- they're recorded off a hires Sun monitor whose refresh rate was different than the camera, and I mercilessly compressed them a few years ago when the Internet was slower.

The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines
http://www.donhopkins.com/drupal/node/97

PSIBER Demo: (9434433 bytes) Demo of the NeWS PSIBER Space Deck. Research performed under the direction of Mark Weiser and Ben Shneiderman. Developed and documented thanks to the support of John Gilmore and Julia Menapace. Developed and demonstrated by Don Hopkins.
http://www.donhopkins.com/home/movies/PSIBERDemo.mov

One problem with PSIBER was that it was too easy to make a mistake dragging and dropping, and accidentally totally hose the internals of the window system, since you were editing shared structures in the NeWS server, like classes and canvases and event handler threads! It needed some kind of read-only safety shield or edit mode switch. Like Emacs, its main purpose in life was to develop and debug itself (and secondarily other NeWS applications like HyperTIES and NeMACS)!

A regular hierarchal outliner like most gui toolkits support might be too limiting for a visual programming language. Objects might have several ways to "open" them, and links coming in as well as going out. Any object might be at the intersection of several trees or sequences at once (like the class hierarchy, and the window hierarchy, the set of instances of the same class, and an ordered list of search results).

PSIBER supported "peripheral views" that let you attach embedded visual editors and open objects in different ways. Good XML editors support a branch for element attributes as well as a separate branch for sub-elements and text. Check out the way 3D Studio Max has outlines with two kinds of branching at each level of the 3d object tree (one branch for animatable object properties, and another branch for attached sub-objects), and the way it crosses a vertical outline with a horizontal timeline. It would be nice to be able to view an object in one or more hierarchies or sequences at once (like 3dsmax's property/sub-object outline + timeline), and easily pivot the editor between different hierarchies and sequences and alternative views (narrowing it to just a timeline, or just a sub-object outline, or a free-form graph view).

I can't remember what he called his system, but Steve Strassmann did some cool stuff on Mac Common Lisp or Dylan with "butterfly diagrams" that branched out in different directions, left for incoming links and right for outgoing links.

The closest thing I could google about Strassmann's butterfly diagrams was his infamous "Is There Toscanini's Ice Cream in Heaven?" flowchart:
http://www.wunderland.com/WTS/Ginohn/cetera/heaven/heaven.gif
http://www.wunderland.com/WTS/Ginohn/cetera/heaven/index.html

Marc H. Brown and Robert Sedgewick at Brown University developed a cool visual interface to Pascal called Balsa (named after a tree, of course), which supported multiple synchronized views of Pascal programs (lexical structure outline, Nassi-Shneiderman flowcharts, dynamic scope views, pascal syntax graphs, algorithm animation, etc). But it was pretty restrictive and ungainly about how you could input and edit a program (you could not do anything that wasn't syntactically correct, and I don't think it supported drag-and-drop), so you couldn't just type Pascal code into a text editor and watch the code views update in real time.

Here's a paper by Brad Myers that mentions Balsa and lots of other cool stuff like Henry Lieberman's "Tinker" Lisp programming by demonstration system:

Brad Myers: Taxonomies of Visual Programming and Program Visualization
http://www.cs.cmu.edu/~bam/papers/vltax2.pdf

Marc H. Brown, Robert Sedgewick: A system for algorithm animation
http://portal.acm.org/citation.cfm?id=808596&coll=portal&dl=ACM

Henry Lieberman: Tinker: A Programming by Demonstration System for Beginning Programmers, in Watch What I Do: Programming by Demonstration, Allen Cypher, ed., MIT Press, 1993.
http://web.media.mit.edu/~lieber/Lieberary/Tinker/Tinker.html

One problem with editing programs as text while trying to maintain a visual representation, is that typing in and editing a program as text puts the program through many syntactically incorrect states, before you've closed all your parens and balanced all your blocks, and you have a horrible correspondence problem mapping between changes in the text to changes in the structure. So it's hard to have your cake and eat it too. Even Emacs Electric-C Mode can get pretty annoying when it tries to close your parens and reindent your program for you while you're typing, if you're not trained to expect it. Of course it's much easier to attempt with languages like Lisp and Python that have simple clean syntax, rather than languages like Perl and C++ with complex byzantine syntax.

-Don

PS: Some weird videos:

Here's an incomprehensible video I recorded late at night, of the freaky "PseudoScientific Visualizer" stuff: Pseudo Scientific Visualizer Demo: (21431618 bytes) Demo of the PseudoScientific Visualizer and NeWS PSIBER Space Deck. Research performed under the direction of Mark Weiser and Ben Shneiderman. Developed and documented thanks to the support of John Gilmore and Julia Menapace. Developed and demonstrated by Don Hopkins.
http://www.donhopkins.com/home/movies/PseudoScientific.mov

HyperTIES Demo: (3562242 bytes) University of Maryland Human Computer Interaction Lab HyperTIES Demo. Research performed under the direction of Ben Shneiderman. HyperTIES hypermedia browser developed by Ben Shneiderman, Bill Weiland, Catherine Plaisant and Don Hopkins. Demonstrated by Don Hopkins.
http://www.donhopkins.com/home/movies/HyperTIESDemo.mov

NeMACS Demo: (3511315 bytes) Demo of UniPress NeMACS running in the NeWS Window System. Emacs development performed under the direction of Mike Gallaher. NeWS user interface developed and demonstrated by Don Hopkins.
http://www.donhopkins.com/home/movies/NeMACSDemo.mov

HyperLook SimCity Demo: (49816346 bytes) Demonstration of SimCity running under the HyperLook user interface development system, based on NeWS PostScript. Includes a demonstration of editing HyperLook graphics and user interfaces, the HyperLook Cellular Automata Machine, and the HyperLook Happy Tool. Also shows The NeWS Toolkit applications PizzaTool and RasterRap. HyperLook developed by Arthur van Hoff and Don Hopkins at the Turing Institute. SimCity ported to Unix and HyperLook by Don Hopkins. HyperLook Cellular Automata Machine, Happy Tool, The NeWS Toolkit, PizzaTool and Raster Rap developed by Don Hopkins. Demonstration, transcript and close captioning by Don Hopkins. Camera and interview by Abbe Don. Taped at the San Francisco Exploratorium.
http://www.donhopkins.com/home/movies/HyperLookDemo.mov

Even more weird videos: http://www.donhopkins.com/home/movies/

Discussion with Alan Kay about Visual Programming

From: Don Hopkins
Subject: Visual Programming

The following two papers that I highly recommend cover a lot of interesting visual programming and simulation systems, which are well worth knowing about.

Kurt Schmucker (inventor of the C++ Barf Bag ;-) at Apple wrote "A Taxonomy of Simulation Software":

http://www.donhopkins.com/home/taxonomy.pdf

Tim Smith at Anglia Polytechnic University in Essex wrote "A review of simulated and micro-world environments":

Source: http://www.donhopkins.com/home/etui/etui.html

-Don

From: Alan Kay

Don --

Thanks very much for these references. I was not aware of either of them and both are very useful for helping think about some of the educational environment needs for the OLPC XO.

When teaching science, we have the important conflict between empirical and model-based approach of modern science and the belief-based dogma of religion. This is particularly critical because there are too many important results in science for each and every one to be learned through personal experiment, and many require tools that are beyond most individuals and schools. So, most people including scientists contact science via reading and hearing about results rather than verifying the experiments themselves. Much worse, most children are taught science as a kind of hearsay catechism of "this is true and must be believed".

Scientists escape to a large extent from simple belief by having done enough real experimentation, modeling building using mathematics that suggests new experiments, etc., to realize that science is more like map-making for real navigators than bible-making: IOW, the maps need to be as accurate as possible with annotations for errors and kinds of measurements, done by competent map-makers rather than story tellers, and they are always subject to improvement and rediscovery: they never completely represent the territory they are trying to map, etc.

Many of us who having been learning how to help children become scientists (that is to be able to think and act as scientists some of the time) have gathered evidence which shows that helping children actually do real science at the earliest possible ages is the best known way to help them move from simple beliefs in dogma to the more skeptical, empirically derived models of science.

We also know from the last century of careful observation of children that they think in ways that are different from adults, and as Piaget pointed out, it is best to think of children as thinking beings in their own right rather than as "defective adults who have to be fixed by education". And, further, children themselves are not homogenous in their approaches to life and learning: they have different styles, reasons for why they want to do things, what kinds of play they prefer, and so forth. The adults in their culture are both explicitly and implicitly trying to get the children to be part of the culture, and the children are wired by nature to try to learn whatever this is. In our culture, this is quite confusing, since the adult culture is an admixture of many different approaches to the world and how it works and can be manipulated. Real science is in the back seat or not even in the cultural vehicle as far as most children and adults (including most teachers) and most of the surrounding media are concerned.

My main concern over the years is how to help children and adults do the initial "real science" that can form the modern scientific stance towards knowledge that allows them to deal with the majority of science knowledge presented as claims they will encounter over the years.

So, I'm very interested in how the children can be motivated and helped to observe nature in ways that give rise to the formation of guesses that can be modeled and compared against the observations and lead to further observations. This requires finding out: what motivates different kinds of children, what kinds of observations can be done and in what form, how children can do real modeling and mapping, etc. All this has to be done above thresholds for what "real" means for science and its modeling. These thresholds can be approached by analogies to what it means for children to do "real music", "real art", "real writing and reading", "real sports", etc.

Seymour Papert's background was in real mathematics and science, and he was able to combine these with important insights of Piaget to realize that children could learn certain kinds of powerful math quite readily, whereas other forms of mathematics would be quite difficult. A central realization was that (a) the differential geometry of vectors (Gauss was one of the parents of this perspective) fit very readily into how children thought about themselves in the world, and that (b) the computer could show this world graphically and also easily do the laborious integration of the differential equations to give children the deep hit of fundamental powerful ideas of vector calculus in forms they could recognize and use for their own ends. I still regard these insights by Seymour as among the top few of all time regarding what computers are really good for.

My contribution to this was small, and amounted to adding in the ideas (a) that multiple independent objects (an idea derived from the early world of simulation) which children could program in the manner of LOGO would amount to a world of real children's mathematics that could model many kinds of ideas, including those of science (and of course all previous computer structures and old and new media), and (b) that the entire environment including the math/programming languages the children used were properly part of the user interface and had to be carefully designed.

There is abundant evidence that helping children move from human built-in heuristics and the commonsense of their local culture to the "uncommonsense" and heuristic thinking of science, math, etc., is best done at the earliest possible ages. This presents many difficulties ranging from understanding how young children think to the very real problem that "the younger the children, the more adept need to be their mentors (and the opposite is more often the case)".

If "children first!" is the rallying cry, then it makes sense to try to invent computer environments that use the very best ideas (and these are very hard to come up with). This is why the various groups that got interested in this romantic quest via early contact with Seymour have always been colleagues and never rivals. The hard to come by ideas for projects, representations, user interfaces, experiments, etc., have been freely traded back and forth. The notions of "thresholds below which is not worth going" have been jointly refined, etc. One of the parasitic difficulties is that computer environments, once made (with lots of effort and dedication) tend to form tribal bonds that are rather religious in nature. The amount of effort required plus the attendant religion makes it extremely difficult to take new insights and ideas and make brand new better environments for the children. The strong tendency is to use and reuse and incrementally expand the old environments.

So, for young and youngish children (say from 4 to 12) we still have a whole world of design problems. For one thing, this is not an homogenous group. Cognitively and kinesthetically it is at least two groups (and three groupings is an even better fit). So, we really think of three specially designed and constructed environments here, where each should have graceful ramps into the next one.

The current thresholds exclude many designs, but more than one kind of design could serve. If several designs could be found that serve, then we have a chance to see if the thresholds can be raised. This is why we encourage others to try their own comprehensive environments for children. Most of the historical progress in this area has come from a number of groups using each other's ideas to make better attempts (this is a lot like the way any science is supposed to work). One of the difficulties today is that many of the attempts over the last 15 or so years have been done with too low a sense of threshold and thus start to clog and confuse the real issues.

I think one of the trickiest issues in this kind of design is an analogy to the learning of science itself, and that is "how much should the learners/users have to do by themselves vs. how much should the curriculum/system do for them?" Most computer users have been mostly exposed to "productivity tools" in which as many things as possible have been done for them. The kinds of educational environments we are talking about here are at their best when the learner does the important parts by themselves, and any black or translucent boxes serve only on the side and not at the center of the learning. What is the center and what is the side will shift as the learning progresses, and this has to be accommodated.

OTOH, the extreme build it from scratch approach is not the best way for most minds, especially young ones. The best way seems to be to pick the areas that need to be from scratch and do the best job possible to make all difficulties be important ones whose overcoming is the whole point of the educational process (this is in direct analogy to how sports and music are taught -- the desire is to facilitate a real change for the better, and this can be honestly difficult for the learner).

The detailed parts of the design have to do with (a) what kinds of math and science the children can do and learn, and then (b) by good solutions to the user interface and expressive elements in the computer environment. These co-evolve because certain things the children can do and learn only have a real payoff for them if they have a computer. For example, many areas of physical dynamics (e.g Galilean Gravity) can be explored and represented in a kind of differential model they can understand without using a computer at all. But for all but about 5%-8% of the kids just finding a good model is not enough of a payoff. However, if the model can be set into motion (in mathematical terms: the integration of the differential model) then many "pieces of art" of great interest to about 90% of the children can be easily made. These include various kinds of falling games (like Lunar Lander, shoot the monkey, etc.).

As the children get more sophisticated, the black and gray boxes that scaffold what they are doing can be popped open and understand and modified. For example, "forward" (which moves an object in the direction of its "heading") is a black box initially, and very useful in that form. But there is a point when the children will be greatly aided by understanding that forward is just a vector addition and is a method made from a more fundamental idea. The underlying language for the system itself has to reveal itself as the same species as what the children have been learning. The analogy to how English is carefully used for different ages and the expanding range of ideas and expression is quite apt.

One of the simplest rules of thumb for any kind of design that requires learning is George Miller's "7 plus or minus 2", which refers to an estimate of how many things can be given attention at one time by our limited human minds. Perspective, simplification, abstraction and duration can all be traded off in designs that try to help learners make progress without overwhelming them. In programming language design in a UI, especially for beginners, this is especially crucial because it is easy to go far beyond 9 new elements. Many users will interpret this as "I am stupid and can't do this" rather than the more correct "The UI and language designers are stupid and they can't do this".

It's hard to point to any programming language for beginners that has a really great form. One thing that has consistently worked is "close to natural language but clearly not natural language". That is, it really helps if the gist-view of a program is a kind of metaphor for what it does, even if one has to think harder about the detailed meaning. For children, Hypercard was OK in many respects for the gist-view, but was too like English for both deep understanding and for programming (many children had a hard time getting past the idea that Hypercard couldn't understand and do any reasonable English sentence). This was debated endlessly in Logo circles, and Logo wound up going from a much more English-like syntax to one much more like Lisp (this was a big mistake in my view). Finding the balance between these is critical, because it governs how much brain is left to the learner to think about content rather than form. And for most learners, it is the initial experiences that make the difference for whether they want to dive in or try to avoid future encounters.

In one respect, young children are easier to design for in that there are fewer standards for math and science in the early grades (this is being eroded, especially wrt math). If we take functional relationships as an example, it has been shown that children readily understand them but have considerable difficulty with variables, and much more difficulty with parameters. The standard math syntax for functions with parameters requires some extra trained chunks to associated dummy names with actual parameters. Some computer languages allow conventions for prefixing the actual parameters with the dummy names. This is good. For younger children, it's likely that making these into complete assignment statements is an even better idea. An object oriented language can use instance variables for a long time before introducing the idea of passing parameters in a method, etc. Having really good trace and single-step visualizations is critical.

The importance of gisting argues against forms that have more than one meaning. For example, many languages (going all the way back to the 50s) have decided that "=" should have a double (or triple) meaning, and that it is up to the programmers to simply deal with it. This is almost certainly a bad idea for children K-8 (and beyond). In the case of "=", even in a functional language, the difference is huge (between a functional relationship and a definition). A suitable "logical language" that used unification would be less ambiguous but introduces quite a bit of abstraction (likely too early).

But, as the child gets closer to high school and the outside world, the QWERTY phenomenon starts to get more important. Many of the global standards are willy nilly and poor, but need to be pragmatically learned at some point. For example, it is relatively easy to get 10-11 year old children to do the real science and math to make a good simulation model of the 2nd order differential relationship. This is best done (so far) by using two accumulator addition (used to be called a DDA and goes back before Babbage). The trade-offs between this simple and deep way to think incrementally about what is going on and the standard algebraic way of thinking about "what's going on for all time all at once" are interesting and important.

Our view is that one should get the 5th graders to do this in the most powerful way for them (incremental addition). And then later (maybe in 8th grade) revisit this and see how the incremental approach can be turned into an algebraic perspective. Both ways of looking at this are important and powerful in their own ways. It is likely that educators are quite justified in making up useful non-standard representations for powerful ideas for any topic that would be helped by this for children below the age of 12. There are many other important reasons for introducing more powerful forms for dealing with ideas in early childhood, etc.

So it seems to me that there is a lot of room for new and different ideas for children's environments for learning powerful ideas. They have to be above threshold and in the spirit of real science and mathematics. Two cautionary examples are Interactive Physics and SimCity.

The first assumes that Newton was absolutely right and is a direct embodiment of Newtonian Dynamics and Cosmology. The users are restricted to paramerizing the internal dynamic models and cannot see them, question them, or change them. (For example, it is really important to be able to try an inverse cube law for gravity, etc.). This is most assuredly not in the spirit of science! It amounts to a dynamic bible. In order for this to be useful in real education, there has to be a lead up that derives the relationships in an empirical and mathematical form, and only then will the premises of IP be useful.

SimCity is similar but more pernicious. It is a black box of "soft somewhat arbitrary knowledge" that the children can't look at, question or change. For example, SC gets the players to discover that the way to counter rising crime is to put in more police stations. Most anthropologists, sociologists, psychologists, and economists would disagree violently. Alternate assumptions can't be tried, etc.

Both of these packages have won many "educational awards" from the pop culture, but in many ways they are anti-real-education because they miss what modern knowledge and thinking and epistemology are all about. This is why being "above threshold" and really understanding what this means is the deep key to making modern curricula and computer environments that will really help children lift themselves.

Best wishes, Alan

Discussion with Alan Kay about Robot Odyssey

One of Alan Kay's favorite games is Robot Odyssey! I wrote to him:

From: Don Hopkins
Subject: Robot Odyssey

One thing I've always wanted to do is a re-make of Robot Odyssey, with the full power of a real programming language underneath it, and lots of cool toys for the robots to play with! That was such a powerful concept for a game!

-Don

From: Alan Kay
Subject: Robot Odyssey

I actually argued with him [Will Wright] and Maxis for not making SimCity very educational. E.g. the kids can't open the hood to see the assumptions made by SimCity (crime can be countered by more police stations) and try other assumptions (raise standard of living to counter crime) etc. I've never thought of it as a particularly good design for educational purposes.

However, I have exactly the opposite opinion of Robot Odyssey, which I thought was a brilliant concept when the TLC people brought it to me at Atari in the early 80s. (Rocky's Boots is pretty much my all time favorite for a great game that really teaches and also has a terrific intro to itself done in itself, etc. Warren Robinette is a very special designer.).

The big problem with Robot Odyssey (as I tried to explain to them) was that the circuits-programming didn't scale to the game. They really needed to move to something like an object-oriented event-driven Logo with symbolic scripting to allow the kids to really get into the wonderful possibilities for strategies and tactics. (BTW, Etoys is kind of an OO event-driven Logo (not an accident), and the next version of it has as a goal to be able to do Robot Odyssey in a reasonable way. This got delayed because of funding problems but we now have funding and are really going to do it this year. Want to help design and build it?)

SimCity, Robot Odyssey, and Visual Programming

From: Don Hopkins
Subject: Education?

Of course it might just be more powerful and efficient to re-implement something like Klik-and-Play from scratch in Python, as a plug-in visual scripting component, which can be used to script a HyperCard-like gui environment, and games built on top of it like SimCity and Robot Odyssey.

From: Antoine van Gelder
Subject: Education?

Anyone know the current status of being able to turn an AST tree emitted by the Python compiler module back into code after it has been modified ?

From: Andrew Clunis
Subject: Education?

I've been looking into this for Develop activity, but it seems that path has never been explored. Best approach seems to be to write a pretty-printer to walk the tree.

From: Guido van Rossum
Subject: Education?

I'm curious about the focus on ASTs that seems apparent in this subthread (though I may easily be misreading between the lines :-). I've always been more inclined to edit the text and re-parse from there, as it puts the author in control of formatting, comments etc., and this is how most "real-world" environments work. (Not that that necessarily makes it better, but neither is the opposite true.) Is someone willing to write up a brief comparison between the two approaches?

OLPC Visual Programming Language Discussion with Guido van Rossum and Alan Kay

This is a discussion from the OLPC Sugar mailing list, about implementing visual programming languages like eToys in Python.

From: Guido van Rossum
Subject: Etoys and integration

Isn't the mere presence of eToys on the XO a complete anathema to the sugar philosophy?

From: MBurns

I think the quote is referencing something else (though I may misunderstand).

The eToys environment is a self-contained world of development. One that exists within the Sugar world of development. Programs, projects, source code and objects written in that eToys world do not exist outside in the Sugar world. You can write a sugar Activity or an eToys bundle, and, as we have seen in the gaming realm, they can often accomplish the same end goal.

Now this may or may not be an issue to people(OLPC devs, students, teacers), they may or may not care, but it is an interesting 'world inside a world' for this transparent learning machine we are developing.

From: Alan Kay

Guido knows that I've been advocating that the Python folks should do Etoys or a very Etoys like environment in Python (and that the rest of the OLPC be given an objectification and media and scripting integration that is Etoys like).

However, there are simply zillions of things left to be done everywhere for OLPC so the first round of SW on the XO will be more of a gathering of "suggestive" features and abilities (of which Etoys is just one). That seems fine to me.

Viewpoints Research (our little non-profit) doesn't have any "ego or identity" staked around whether the children's authoring environment is Python based or Squeak based. I have said many times that, if the general integrative base of XO is to be Python, then the Etoys-like authoring should be based in Python also.

However, I will personally fight to the death to make sure that there is a children's authoring environment that allows even young children to do simulation style programming with very rich media objects.

For now, that is Etoys. It could be a suitable object-oriented Logo with media objects (this is essentially what Etoys is). It could be some better design (let's do one). The base could be Javascript (if implemented on top of an integrated environment of sufficient power), Python (ditto), Ruby (ditto), etc. Whatever it is, it has to be above high thresholds, not a hack or a gesture.

Besides the programming the children use to learn important ideas in math and science, they also need to be able to see how their own computer world is structured by being able to "pop the hood" on practically everything they use. Perhaps it is OK for high school children to see the current code (but I don't think so). I think there needs to be a wrapping on the entire set of facilities that uses the same conventions that 9 year olds do their own programming in. Again, if it is to be Python, then it needs to be crafted a bit for younger children. E.g. Etoys allows easy unlimited parallel tasking, and this is very important for children's programming. Etc.

There are many good things that can be done here. We live in a computing world in which there is a tremendous amount of identification between many programmers and the tools they use -- so strong that it resembles religious fervor. From my view, ALL of the system have such flaws that we are better off being critical of all of them and try to use the best ideas from everywhere.

If "Children First!" is really the goal here, then we must spend most of our energies trying to make the childrens' environments more conducive to creative learning of powerful ideas.

Cheers,

Alan

From: Guido van Rossum

Thanks Alan. I'm quite satisfied with this response and I agree with the priorities!

Alan Kay on Programming Languages

Alan Kay wrote:

It's hard to point to any programming language for beginners that has a really great form. One thing that has consistently worked is "close to natural language but clearly not natural language". That is, it really helps if the gist-view of a program is a kind of metaphor for what it does, even if one has to think harder about the detailed meaning. For children, Hypercard was OK in many respects for the gist-view, but was too like English for both deep understanding and for programming (many children had a hard time getting past the idea that Hypercard couldn't understand and do any reasonable English sentence). This was debated endlessly in Logo circles, and Logo wound up going from a much more English-like syntax to one much more like Lisp (this was a big mistake in my view). Finding the balance between these is critical, because it governs how much brain is left to the learner to think about content rather than form. And for most learners, it is the initial experiences that make the difference for whether they want to dive in or try to avoid future encounters.

Applying XML to Describing User Interface Layouts and Behavior and Constraints.

This is a message I sent to Paul Haberli a several years ago, brainstorming some ideas for an XML based scripting language. More recently, after discovering OpenLaszlo, I ran across this email, and it made me realize why I was so happy to find Laszlo, which embodies many of these ideas!

From: Hopkins, Don [mailto:Hopkins, Don]
Sent: Sunday, November 08, 1998 3:06 AM
To: paul@isdn-balla.corp.sgi.com
Cc: dhopkins@maxis.com
Subject: RE: http://reality.sgi.com/grafica/motion/

I think something cool to do, would be to apply XML to describing user interface layouts and behavior and constraints.

It would have to describe the interfaces and connections between the components, as well as the graphical layout and properties.

It should have a general purpose message passing model that is independant of any scripting language, and you could also embed scripts in the xml in different language like is currently done with html.

But you should be able to do a lot without even resorting to scripts, just hooking components together.

And then if course I want to design a visual programming language in XML.

The Shape of PSIBER Space - October 1989

The Shape of PSIBER Space:
PostScript Interactive Bug Eradication Routines

Written by Don Hopkins, October 1989.
University of Maryland
Human-Computer Interaction Lab
Computer Science Department
College Park, Maryland 20742

[Source code]

Abstract

The PSIBER Space Deck is an interactive visual user interface to a graphical programming environment, the NeWS window system. It lets you display, manipulate, and navigate the data structures, programs, and processes living in the virtual memory space of NeWS. It is useful as a debugging tool, and as a hands on way to learn about programming in PostScript and NeWS.

Introduction

Cyberspace. A consensual hallucination experienced daily by billions of legitimate operators, in every nation, by children being taught mathematical concepts ... A graphic representation of data abstracted from the banks of every computer in the human system. Unthinkable complexity. Lines of light ranged in the nonspace of the mind, clusters and constellations of data. Like city lights, receding ....

Visual Programming Interface Ideas - March 1988

Notes on visual programming interface design, written by Don Hopkins on March 10, 1988.

Use buttons, menus, etc to indicate nouns and to activate verbs.

When you indicate a noun, (send it an "indicate" message) it's pushed onto the noun stack.

When you activate a verb, (send it an "activate" message) it tries to collect its arguments, if any, from the stack.

If it can get all of its arguments, then it is enabled, (sent an "enable message") and can be applied to them.

Otherwise, it blocks until all the right arguments are there, possibly prompting for them to be pushed onto the stack or indicated somehow.

Syndicate content