4 ms·

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 descri

by Permit 13y ago

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.

ibdknox 13y ago
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.
- Permit 13y ago
  >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/e536bce3-30f9-4e7f-b322-b3835a487bb0/how-to-create-an-editor-with-a-projection-buffer?forum=vsx 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.

by Permit 13y ago

ibdknox 13y ago

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.

Permit 13y ago
>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/e536bce3-30f9-4e7f-b322-b3835a487bb0/how-to-create-an-editor-with-a-projection-buffer?forum=vsx 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.