Ian Bicking: the old part of his blog

Re: Python, Education, Logo

google for boxer - boxes as base for programming

Comment on Python, Education, Logo
by Niki Spahiev

Comments:

http://dewey.soe.berkeley.edu/boxer.html/

# Niki Spahiev

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.

# Ian Bicking

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