There has been a lot of work done in programming languages for kids. Kelleher and Pausch (2005) is a great compilation of EUP projects, and it includes many kid oriented ones. I don't know if I like their hierarchy. It puts Curlybot and LegoSheets in the same category, "Create programs using interface actions," but I think there is a huge difference in approach: LegoSheets does programming through a rule editor, which has some sort of visual programming language. Users of curlybot aren't using it to write code, they are using it to perform actions in the world. Curlybot could be turned into a front end for a more complex, hidden program (and this might be what the authors intended to do) but it could just as easily be left as is and combined with other active objects. I think this approach is fundamentally different than visual programming languages of all kinds. In this situation, physical actions are not a metaphor for lines of code, they are the code.
This is a really basic difference. In one case, we are providing a front-end to a traditional programming language. In the other case, we are providing a completely different run-time environment. With Curlybot and Electronic Blocks, the runtime environment is the physical world. There is no symbolic object anywhere that represents the relationship between a light and a light sensor... those things are actually in the world.
I think the obvious benefits of this are comprehensibility. Curlybot and Electronic Blocks are both relatively easy to understand and get up to speed with. But the physical world has limitations (physics). One of the reasons for using the computer is that things can be done blazingly fast, and walls are not concrete, but mere suggestions. The Tortis Slot Machine project (Perlman, 1976) realized this and provided both physical and virtual versions.
However, I think A) we need to find that line, becuase I don't think Curlybot and Electronic Blocks represent the most powerful physical programming environment you could create. And B) there's no reason you couldn't have a virtual physical programming environment. Now, to be clear: this is still fundamentally different than the language metaphors. With a virtual physical programming environment, the run-time would still be the virtual world, rather than a Java stack. So there would still be a certain kind of limitations. However, the limitations would be different than both the physical and the traditional runtimes.
Actually, but they put Electronic Blocks in a different category, so maybe I judged too quickly. I am going to read the whole 55 page paper in detail now.
OK, re-reading now, and it seems like part of the problem is that the authors divide the EUP world into projects that are trying to teach programming concepts so that users can later move on to "real" programming languages, and projects that try to actually make real programming easier. This means projects like Alice, which contain the ability to edit arbitrary code are put right alongside projects like Curlybot, which bear little resemblence to any kind of language at all.
p.5 they talk about the need to have general-purpose languages that can support "arbitrary" programming tasks, but then talk about domain-specific languages... it's weird to me that they put these in the same category as tools to prevent syntax errors.
p.9 Play (Tanimoto and Runyan 1986) reminds me a little of Electronic Blocks, just because of the three component command thing. Code is an character, action, and additional info triplet, where Electronic Blocks are sensor, logic, action triplets.
As of p.16 I am sort of understanding why the put curlybot in the same category with Roamer.... Roamer seems to be physical-in, physical-out as well. However, the mechanisms are all internal, and accessed via buttons. So the actual code is not really visible. I think this is where the authors and I have a different view of things. I imagine the motion of curlybot to be an atomic piece of a larger program. They see the motion of curlybot to be the result of an internal program.
Reading about Playground on p.18, I end up at this page on larry yaeger's site where he talks about event-oriented programming and how it is more pull than push. I think I should talk to larry again. I think maybe this notion of having programs use a virtual reality world as their runtime is not unrelated to my questions last year about increasing complexity and intrinsic fitness functions. Maybe the code needs to be "in the world" and BusyBodies is a way to do it.
p.23 Talking about ToonTalk... I'm not sure if ToonTalk is really a physical language. It might just be a nice visualization; a metaphor. At some point, I should look closer.
p.39 Boxer shares some goals with Modality.
p.40 The Incredible Machine may represent a similar kinds of programming to Lemmings.
Execution Visualization: Pict