The one thing I really wanted to do was add a kind of stacking visualisation to the timeline to show depth of callstack. At the moment it is not clear at all how deep you are in recursion. I was thinking thin drop shadows that make it look like the timeline is a stack of paper.
I did half implement "Markers" which are coloured lines on the timeline similar to breakpoints.
I decided to shelve it until I had rewritten the whole thing to be more stable, which I think will require doing it as a fork of CPython.
Recursion visualization would be fantastic, especially in languages like Python where the max depth is quite shallow. You could also develop modules for language-specific visualizations; it would be incredible to see memory management visualized (maybe as an addressed stack?) when writing in C, or how data ownership is being passed around a program in Rust. These would be great for lowering the cognitive load for developers writing more complex programs.
What I really like about your implementation is that it's scratching the itch of abstraction code (i.e. the inherently non-visual), as opposed to something like Light Table's WebGL example (which is very impressive, but not applicable to most developers' day jobs).
Yes, you've hit the nail on the head. The same is true of some of Bret's demos like the Braid one. I was trying to bring some of that tangibility to difficult abstract problems like from code jam.
I think one of the reasons games developers are so ahead of the field in making the abstract visible is they have a "canvas" right there that they are outputting to. It's very common to see really clever and intuitive visualisations covering the screen in game development, not because those guys are visionaries but because they are just trying to understand the code and that's how they naturally express themselves.
Basically what I wanted to do was come up with a solution "one step up the ladder of abstraction" (is my BV fanboy showing?) that let's users define their own, problem specific visualisations. This is where the concept of metacode came from. If you give people access to the data (omniscience), a blank canvas (sheet), and a way to express themselves (metacode) then natural curiosity should take over.
I'm not saying I achieved all that, but that was the idea. I think there's more work to be done on the language of describing the code, the current vocabulary is based around line numbers and execution steps which are brittle when the code is changed. What you want is visualisations that persist and change as you edit the code.
I did half implement "Markers" which are coloured lines on the timeline similar to breakpoints.
I decided to shelve it until I had rewritten the whole thing to be more stable, which I think will require doing it as a fork of CPython.