Comment by ibdknox | Hacker News Reader

Comment by ibdknox | Hacker News Reader

Parent Full thread

It's been done a few times before :) For example, check out the debugger canvas: http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-...

The problem ends up being that you're trading one form of cognitive load for another and it turns out that given our text-centric view of writing code, locality ends up having a lot of importance (which is lost in the model you're suggesting). There are lots of other issues with it at a practical level too. I've never seen an input model that works well with lots of disconnected little editors, for example. How do you navigate between them? How do you lay them out? What happens when the graph is disjoint? How do I get to some point in the flow of the program? What if I need multiple things that aren't directly related next to each other? How do you even determine relation?

After having implemented this in various forms about 4 times now, I'm fairly convinced this is one of those things that makes good intuitive sense, but bleeds to death from a whole bunch of paper cuts in practice.

The one case where this does seem successful though is in the step-wise debugging case. There's a very definite flow, locality matters a lot less, and debugging is an inherently mouse-oriented task - all the things you need for a zoom-based infinite canvas to work out.

CodeCanvas and Debugger Canvas are two projects we've definitely consulted while building this thing.

We've solved some of the practical problems you've described. The new C# compiler Roslyn makes determining relation fairly trivial, something that I'm assuming proved difficult in Clojure(script) and Javascript.

Many of the other issues are user interface/user experience problems that are better demonstrated than explained. Unfortunately, our demo isn't quite polished yet. We're showing it off at our school symposium in mid-March, so we should have something to show before then.

Would it be alright if I ran the demo by you when we finished it? Much of our inspiration for the idea came from CodeBubbles, Code Canvas and the original Light Table demo, so it's interesting to hear that you've decided against it.

One of my 4 implementations was the prototype I did at MSFT that became the debugger canvas :) Me and a few others built it after I saw the original Code Bubbles demo.

> The new C# compiler Roslyn makes determining relation fairly trivial, something that I'm assuming proved difficult in Clojure(script) and Javascript.

I had access to the language models then too, but the thing is relation is not always written directly into the code. This was the point I was making about locality. In a world with mutability, you can't really know what matters. We tend to cope with this by putting code that relates near each other (in the same file, in the same parts of a file, etc), but that relation isn't made specific in the call chain. It could be, and usually is, buried under several levels of indirection. The lack of locality really frustrated people, because the mainstream models we have for programming don't directly relate to flow and so it ended up being a square peg in a round whole kind of thing.

> so it's interesting to hear that you've decided against it

I've decided against it for the way we program now... :) Flow as a general concept is a very good one, and anything that can make that explicit would be wonderful. But we can't program with rampant mutation and callbacks and expect it to work out.

>One of my 4 implementations was the prototype I did at MSFT that became the debugger canvas :) Me and a few others built it after I saw the original Code Bubbles demo.

Haha yeah I've actually encountered that project. There are few things I've wanted open sourced as badly as Codeporium. A decompiler only gets one so far.. (You seriously come up all the place when it comes to extending the editor: http://social.msdn.microsoft.com/Forums/vstudio/en-US/e536bc... haha)

>I've decided against it for the way we program now... :) Flow as a general concept is a very good one, and anything that can make that explicit would be wonderful. But we can't program with rampant mutation and callbacks and expect it to work out.

Fair enough.

> The one case where this does seem successful though is in the step-wise debugging case. There's a very definite flow, locality matters a lot less,

I think this has more to do with our conventional debugger interface being so horrible, that anything is an improvement. When debugging, I want my code ordered temporally in terms of how it is executing. Code bubbles give us that, but a 1D editor solution might still work better if the code can be dynamically reorganized.

> and debugging is an inherently mouse-oriented task - all the things you need for a zoom-based infinite canvas to work out.

It doesn't have to be, that's just what we have to work with at this point.

Reply on news.ycombinator.com