It appears Guido is off at a workshop about math education with the Shuttleworth foundation. There's a summary of the first day. All via this post which talks about Rur-Ple.
Anyway, a couple days ago someone emailed me about PyLogo, and I hadn't really done anything with that for some time, so I dusted it off and cleaned it up some. Arg, I have to update that page, but now the trunk is in subversion. I even monkeypatched doctest to doctest Logo. Wasn't too hard really.
I think this would be astonishingly slow to execute. But the idea is intriguing. You could use some of the native abilities of browsers to edit markup, to edit the code itself. The code is intrinsically structured. It's not structured with glyphs, it has an underlying structure. Representing variables as elements themselves provides a concrete nature to the variable -- you can see it as a real thing. I think this is very much similar to some of what was under Hypercard. And of course it's on the web, which is the most relevent medium of our time, even for kids.
In the discussion is also the question of relevance. Why should a child learn these concepts of abstraction? (Not just programming, though I think programming is one of the most accessible ways of learning many higher abstractions.) This actually isn't that hard. Kids don't need a lot of justification, they don't need to make money with the skill, they don't even need to be very good at what they do. They can be a surprisingly sympathetic audience, especially when you are making something. This is why programming is great, and traditional algebra sucks.
The harder part is actually figuring out why this would be relevant to the teachers. Logo has always had this curse. Students do well with it, but they can't really do well without the influence of the teacher. And very few teachers get it, or get what is going on and what is being taught. It's not relevant to them.
This is much harder to consider, especially in third world countries where there is more pressure to emphasize practical skills, and less value placed on abstract skills. For most people, math beyond arithmetic really isn't that practical.
I don't really know. Turtle graphics aren't bad -- there are many much more abstract and useless things in programming. It's important to remember that this is not about teaching programming. It's about teaching math, or abstraction, or debugging. Debugging is a good one -- not well articulated as a skill, but surprisingly portable across domains. It's kind of like the scientific method applied to the work of the craftsman.
But what is relevant? There's a problem of connectivity. So it is presumed that the program runs in isolation, in a world tied to the laptop, run in isolation.
I think that's the opposite of what should be done. The relevance of a program is not that it can be as isolated and disconnect as the student is. Instead the program can be connected even when the student is not. The program can be a representative. A program is relevant because it can be shared. It is relevant because it can persist in the online environment even though the child cannot.
Relevance is something like a story, an agent, a responder... things that are autonomous in some fashion. Chat bots would be great fun. But still, it is very hard to find this relevant. As much as I believe in the underlying importance of those skills, that importance is built up in my own values, and many of those values are predicated on my own privilege and the ability to consider abstract motivations. I don't think my values are inappropriate for the third world; quite the contrary, I see pragmatism as an oppression. But communicating that is very, very hard.
Anyway, hard stuff but important stuff. I hope their workshop is successful.
google for boxer - boxes as base for programming
Yes, Boxer is definitely an inspiration for the idea of JS-in-the-DOM. I've long wanted something like Boxer for Python -- i.e., an alternate syntax and editor that used Boxers relatively conservative visual programming metaphors. But actually implementing such an interface was always well beyond me -- I don't have much GUI experience at all, and actually doing text flow and whatnot in that visual context seems complex. The DOM offers a relatively accessible way to do that. It may also have other tremendous flaws I don't know of... but the best way to figure that out would be to try, I guess.
Another good example to look at is Alice (http://www.alice.org).
Other terms to Google for are "structure editor" (though this'll tend to throw up graphically-based visual programming editors as well) and "syntax directed editor" (which'll throw up a range of approaches, from those that do simple pretty printing to those that heavily assist and control input).
As with Lisp code, you're basically representing the AST, only as intelligent GUI objects rather than a dumb character buffer. The advantage, of course, is that since your objects are smart, they can check for validity immediately upon input and provide interactive advice and assistance. It's rather like the difference between DOS and Windows environments: both essentially do the same thing - the difference is in how the manipulation and feedback interactions behave. With Windows you've much more transparency and much more active constraint, since all the options are laid out on screen in front of you (menus, icons, etc.) instead of having to learn and remember them all in your head, and you've instant feedback on whether input is valid or not - a command-line typo will go unnoticed till you try to execute it later on, whereas the GUI will never allow you to make the [equivalent] error to begin with.
I imagine the hard bits are implementing the View objects, since that'll involve some fairly intensive GUI programming involving sophisticated text presentation, and - crucially - coming up with a user input system that is efficient and intuitive to use. i.e. If writing a 'smart' program feels more clumsy or onerous than typing a bunch of characters into a dumb buffer, then except for absolute beginners most folk aren't going to be keen about using it regardless of what its other virtues may be. Drag-n-drop is too exhausting for anything more than the simplest of programs, so you'll ideally want some way to drive it from the keyboard that's fast and efficient while also not being more complex than Emacs to learn and use - no small challenge, I suspect! :p
I must admit I've never thought of using DOM for the input/display engine, but with lots of clever DHTML forms-n-tables programming, hey, it might just work, at least for a basic level; good luck if you decide to have a go.# has
Ugh--it's frustrating that everyone doesn't enable comments. I like the idea of the wikipedia-like content mixed with an interactive component. A good example of something like this is http://tryruby.hobix.com/. That guy can write his butt off, which keeps you interested in the tutorial. It's very interactive, and you feel a sense of freedom having the pseudo-repl there--he even anticipates some goofy answers and responds to them.# Innocent Bystander
Yes, from my web-centric point of view the tryruby model is very interesting. I find the idea of HTML literals quite interesting as well; e.g., instead of just repr(obj), an object can have a rich HTML representation. If you combine that with a clean callback technique and higher-level HTML widgets, you could even make an Ajax application interactively composable -- and throw in some automatic persistance to boot, and you have a persistent image/IDE. This is Yet Another Idea that I want to pursue, of course ;) A scratchpad of objects could address some of the issues of combining a linear narrative (like a tutorial) with the freedom of an interactive prompt.
And, as I think about it, that would totally be Hypercard. Tasty.
Do you think the StarLogo/NetLogo flavors have greater potential to enable "relevant" opportunities?
StarLogo and NetLogo are great for doing things that are really fun, and educational, and emergent, but I don't think they are good for relevance. They are little self-contained worlds, and what makes them neat -- the massive concurrency -- also makes them less approachable when trying to connect them to the larger world which is where relevance is derived.
Though there is a possibility that there is a relevance and potential underneath those that more experienced programmers have a hard time appreciating because we take a reductive view of programming. It's not impossible to imagine another generation of programmers who views the programming process radically different from how we view it.
I wonder whether writing web apps, esp SocialSoftware, might provide some relevance, because it's a platform for sharing/expression. (Of course, then the question becomes whether you just use someone else's platform. So maybe what we need are ways to expose kids to the opportunities for small steps of customization, based perhaps on your small loosely-couple libraries:) )