Comment by Permit | Hacker News Reader

Comment by Permit | Hacker News Reader

I think there is a balance to be struck between visualizing various aspects of a program (control flow, data flow etc.) and retaining the control available to developers writing their programs as text stored in files. It does seem strange in some ways that we're still dumping text into files in 2014. A given function might interact with classes and functions defined in 10 different files, and we can only view two or three files at a time.

It seems like programmers compensate by creating a mental model of their program as they try to memorize how it will execute. (The comic This is why you shouldn't interrupt a programmer comes to mind: http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-...)

I'm actually working on a plugin for Visual Studio roughly modeled off of Code Bubbles to see if it's practical to solve this problem. (http://codeconnect.io) I think text is the best way to express exactly what you want out of a program, but the way we're interacting with that text can be improved.

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.

I would really like to chat with you about code connect and get your thoughts. My email address is in the post.

Reply on news.ycombinator.com