A couple of things over the last couple of days have focused my mind on the question of IDEs.

The first is moving to Eric4 from Eric3. The change isn't really all that much, in fact, in the pieces I use there is no particular advantage to the new version (other than that it builds cleanly on Gentoo). All I use in Eric is the project-tree (to quickly find and open files in our multiple-hundred-files projects) and the source-code view (tabbed), and that was pretty much "done" in Eric3 (I have disabled most of the v4 enhancements for the source-code editing). For everything else I use command-line tools, partly because I work on remote servers often, partly because of the wonders of command-line history.

Unfortunately, Eric4 has turned out to be noticeably slower than Eric3. Not slow enough to be unusable, but slow enough to be just a bit frustrating, particularly in the project-view pane. The change there just seems to be the difference between Qt3 and Qt4 AFAICT, something that likely isn't going to go away. As with most such things, it's just enough to create an itch... and itches are where open source software starts.

The second thing was spelunking through the code of the "Turtle Graphics" activity for the laptop. It is one of those pad/sink wiring-diagram coding environments that lets you drag together primitives to create simple code constructs.

As I was playing with it I kept thinking "wheres the code", that is, where is the textual code that I'm building? Why can't the kids see the "real" operations that they are generating, so that they would have a bridge to start coding. So, I popped off the top and took a look at the code.

Turns out that this is not pyologo, it's a more constrained turtle-graphics-specific project. It runs nicely on my workstation, though the drag-versus-click handling is too sensitive to hand-movement to use with a tablet. It doesn't appear to be building Python (or Logo) code under the hood, it builds a "byte code" of sorts (list of strings/floats) that is interpreted to do the drawing.

Which made me want to sit down and hack (and still does). I really want to make the activity generate a Python file and then run that Python file, that is, as the user drew the diagram, we would write the equivalent Python code and let them see what they could have written to get the same effect as their drawing. They could explore the GUI, use it whenever they wanted, but the code underneath would be visible, calling out to them...

I would also love to be able to take any random Python file and render it for a child as a diagram like that, something they can pull apart and put back together. Then they could drill into the Python file they've generated, looking at the functions they've called (e.g. turtle.forward()) to understand the code and maybe change it.

I'd love to be able to let them drag-and-drop database schemas, properties, delegation, classes, methods, signals, RPC communication and the like and at any moment pop over to a code-based representation of what they've drawn. I'd love them to be able to draw a box around a group of code primitives and automatically factor it into a function with pads that forward to the internal pads.

My dreams for the last few days have been filled with ghostly text floating behind a drag-and-drop canvas and ghostly diagrams floating behind text editors. Sleepless mornings have been filled with diagrammatic syntax error handling, unpacking operations to drill down or up call stacks, integrated source-code-control operations, and all of it leading into a (sometimes 3D, sometimes SVG, sometimes a traditional UI) editor that lets you design and hook up graphics to make the world a better place.

The result of all that is exactly the kind of IDE I don't use myself, a truly "integrated" environment. And if I don't use such a thing myself (and I never have, or at least, I've never used those integrated/simplified features), how do I think that's what kids need. Which makes my mind start kicking over how to make the whole thing decoupled, but still useful as an educational environment and without imposing the "glue it together" overhead on the child.

None of that is conducive to getting a good night's sleep.