There's another post on the second day of the Shuttleworth Summit (that I also blogged on yesterday).

Some initial reactions:

• It's interesting how much Python is coming up in the notes; not that it's surprising given the people there. But that Alan Kay seems so open to Python is a bit surprising.
• The more I think about Hypercard, the browser, and programming in general, the more the idea interests me.

I noticed this:

Momentum seems to be building for a stronger graphics engine, either 2D or 3D, with Python bindings, that'll run interactively from within a browser. The Squeak folks may be willing to contribute to this effort. Guido feels we'll need to recruit new talent for this, as the Python community is currently pretty maxed out on projects. Should such an engine be developed, turtle stuff would be incorporated therein.

I'm a bit surprised -- Python graphics doesn't seem to be in bad shape, what with Pygame, VPython, and other projects.

As a plugin, perhaps there's nothing in Python to use. I don't get the plugin thing. Plugins seem totally irrelevant now. Maybe Logo written in ActionScript (the Flash Javascript-a-like), or Flash as an output medium... but introducing another plugin seems pointless. It's just putting a normal GUI app inside a browser window, which is like the worst of all worlds.

Mozilla + XPCOM + Python + Canvas/SVG... that seems like a usable combination. But not for the ability to distribute -- unless you also offered a server-side programming alternative where graphics were pushed out to the browser, instead of generated in-process to the browser.

Honestly, I just don't think fancy graphics are important. Graphics of some sort? Sure, but I don't think the graphics have to be top of the line. Other issues are far more important, and the graphics technique should be chosen based on those other issues. Things like how the development environment feels.

• There should be transparent version control; everytime you run the program, a checkin transparently happens first. Give a movie of the development, or when something fails show exactly what was changed since the last time the program worked.
• Avoiding "save" would be nice too. I think saving is dumb in general. It's used as a really really stupid form of version control (revert-to-thing-I-haven't-saved-over). Maybe avoid files.
• Great debugging tools. Visualization tools. See the program execute in a concrete manner. Error messages that are meaningful, contextual, and guiding.
• Insulate the child from the underlying system, at least to start. You want them to be able to open it up, but only when they are ready to (but: let them choose when they are ready for themselves.)
• Internationalize the language itself. Logo does this all the time (eased by its highly limited number of special syntactic forms), but it's otherwise pretty unusual. Though it becomes really hard to open the hood. Well damn... I guess they should all just learn English. Really.
• Make programming approachable for students with different skills. "Real" programmers are self-selected for certain abilities to abstract. I suspect that the ability for us to look at source and just intuitively understand its basic lexical structure is one of those selections. More hints and tools for people who don't get that. More explicit visual representations (like in Boxer). A narrative form would be nice, but I can't think of what it would look like.
• Make sure students can share everything they do, at least with each other. Really encourage shared libraries among students. There's huge learning potential in that, and given the right tools I'm confident that shared libraries will emerge in classrooms. Once the classroom dissolves in the beginning of another year, start with a blank slate for the next class, but also let every student take that class's code with them.

Graphics? Eh. Have you seen the pictures kids draw? That ain't high art (you must appreciate that link in the absurdity of its sentiment, otherwise it might seem mean). And yet art or not, it makes kids happy to draw. It's the process, not the product, and if adults and teachers can figure that out, the kids will be totally comfortable working that way. That's what kids do.