5 ms·

I'm of the opinion that the way we interact with code is flawed. This author touched on it when discussing text dumps. I agree with the author that little time

by Permit 13y ago

I'm of the opinion that the way we interact with code is flawed. This author touched on it when discussing text dumps. I agree with the author that little time is spent modifying large modules of code (something NoFlow[1] is trying their hand at). However, I think these text dumps we work with should be organized differently. As it stands, we interact with code on a file-by-file basis. But any programmer knows that the execution path of a given program is rarely going to be contained within one file, and it's not going to execute from the top of the file to the bottom. Execution jumps from file to file, and programmers spend much of their time maintaining a mental model of these jumps. I think this is the wrong way to program. I think execution path should be more easily accessible to a programmer, and they shouldn't have to navigate through function calls one "Go To Definition" at a time. This topic has become fourth year design project for myself and a few peers and we're trying to play with different representations of code on a function-by-function basis. Here's a rough prototype we hacked together a few months ago: http://www.youtube.com/watch?v=Bm38U40HL4E http://www.youtube.com/watch?v=Bm38U40HL4E We've since integrated it into Visual Studio so as to retain Intellisense, syntax highlighting and existing plugin functionality. We're using Roslyn to gain insights into semantic information about the code. [1] http://www.kickstarter.com/projects/noflo/noflo-development-environment http://www.kickstarter.com/projects/noflo/noflo-development-...

ibdknox 13y ago
For this specific aspect of the problem, you'll probably find some inspiration in code bubbles, debugger canvas, and Light Table. I implemented a prototype of the former in VS before I left MSFT, it later became the basis for the debugger canvas, and then Light Table happened. [1]: http://www.andrewbragdon.com/codebubbles_site.asp http://www.andrewbragdon.com/codebubbles_site.asp [2]: http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-4adf-bfef-83bd428a0acb http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-... [3]: http://www.chris-granger.com/2012/04/12/light-table---a-new-ide-concept/ http://www.chris-granger.com/2012/04/12/light-table---a-new-...
- Permit 13y ago
  Was that Codeporium? I believe Noah Richards and Chris Granger worked on something similar according this this comment: https://news.ycombinator.com/item?id=3848543 https://news.ycombinator.com/item?id=3848543 I actually saw the Codeporium .dlls kicking around inside the DebuggerCanvas package. Most of the Visual Studio interfaces lack a lot of formal MSDN documentation, which has forced me to do some novel research haha. Edit: Oh, you are Chris Granger haha. I'd also like to thank you for the Visual Studio 2010 editor tutorials, while I have the chance. Light Table looks fantastic, and I hope it inspires a change within other IDEs as well.
- hackula1 13y ago
  I remember seeing code bubbles when you released it and thinking it looked much more promising than the flow-based approaches to abstracting away code files that we usually see. NoFlow and the like tend to ignore the fact that: 1) The approach has been tried countless times before and failed. 2) Programmers don't need code abstracted away. Text is great for telling a machine what to do. The real pain point is in linking pieces of relevant text, something that OOP does pretty successfully, but still leaves some room for improvement. 3) Nobody has 25 feet of screen space to see an entire program on, and scrolling around over giant flows is a huge PITA. 4) Attempts to solve the screen real estate issues through collapsable nesting of flow paths usually lead the same incomprehensible rat's nests of logic that regular old code does. 5) Business people don't want to code, despite their fantasies of kicking all the expensive programmers to the curb. Computers usually do exactly what you tell them to, and talented programmers are different than your typical business people in that they have a knack for taking high level requirements and turning them into highly complex, low level implementations. Someone who has no interest in this sort of work will ever be any good at it IMHO. 6) Building flows requires 99% of the implementation to already be complete. Stringing together prebuilt modules with if/thens is not that difficult or unreadable in textual code anyway.
  - Glench 13y ago
    Regarding (3), I think if you need 25 feet of screen real estate in a graphical environment, then your code is probably not organized well, regardless of whether it's textual or graphical. Regarding (1), I think we need to understand why it's been tried and why it's failed. Knowing that it's been tried before and failed should be enough to make you skeptical, but it shouldn't be enough to outright reject something unless it's a copying an old idea wholesale. That said, I think NoFlo specifically has very few new or interesting ideas.
cam_l 13y ago
ianap but loved the visualisation space imagined / implemented for excel calculation paths in this recent submission.. i wonder whether a similar idea (ie. for viz.. not replacing an editor) would have mileage here, or would it just be so complex as to be indecipherable? https://news.ycombinator.com/item?id=6585889 https://news.ycombinator.com/item?id=6585889
- Permit 13y ago
  That's very similar to the effect we're trying to achieve. I was happy to see it was received well by the HN community. I think the same approach would work well in an IDE.
gnaritas 13y ago
I hate to say it, but that looks like my Smalltalk browser. Smalltalk has various built in code browsers that allow you different views of the code, your plugin behaves like one of them, the chasing browser.
ollysb 13y ago
I would love to be able to unfold method calls in my editor, something like(best I could do in ASCII) > hello_world() -------------------- def hello_world puts "hello world!" end and so on. Basically the code bubbles concept but inline. Maybe it'll be possible to get LT to do something like this in the future...

by Permit 13y ago

ibdknox 13y ago

For this specific aspect of the problem, you'll probably find some inspiration in code bubbles, debugger canvas, and Light Table. I implemented a prototype of the former in VS before I left MSFT, it later became the basis for the debugger canvas, and then Light Table happened. [1]: http://www.andrewbragdon.com/codebubbles_site.asp http://www.andrewbragdon.com/codebubbles_site.asp [2]: http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-4adf-bfef-83bd428a0acb http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-... [3]: http://www.chris-granger.com/2012/04/12/light-table---a-new-ide-concept/ http://www.chris-granger.com/2012/04/12/light-table---a-new-...

Permit 13y ago
Was that Codeporium? I believe Noah Richards and Chris Granger worked on something similar according this this comment: https://news.ycombinator.com/item?id=3848543 https://news.ycombinator.com/item?id=3848543 I actually saw the Codeporium .dlls kicking around inside the DebuggerCanvas package. Most of the Visual Studio interfaces lack a lot of formal MSDN documentation, which has forced me to do some novel research haha. Edit: Oh, you are Chris Granger haha. I'd also like to thank you for the Visual Studio 2010 editor tutorials, while I have the chance. Light Table looks fantastic, and I hope it inspires a change within other IDEs as well.
hackula1 13y ago
I remember seeing code bubbles when you released it and thinking it looked much more promising than the flow-based approaches to abstracting away code files that we usually see. NoFlow and the like tend to ignore the fact that: 1) The approach has been tried countless times before and failed. 2) Programmers don't need code abstracted away. Text is great for telling a machine what to do. The real pain point is in linking pieces of relevant text, something that OOP does pretty successfully, but still leaves some room for improvement. 3) Nobody has 25 feet of screen space to see an entire program on, and scrolling around over giant flows is a huge PITA. 4) Attempts to solve the screen real estate issues through collapsable nesting of flow paths usually lead the same incomprehensible rat's nests of logic that regular old code does. 5) Business people don't want to code, despite their fantasies of kicking all the expensive programmers to the curb. Computers usually do exactly what you tell them to, and talented programmers are different than your typical business people in that they have a knack for taking high level requirements and turning them into highly complex, low level implementations. Someone who has no interest in this sort of work will ever be any good at it IMHO. 6) Building flows requires 99% of the implementation to already be complete. Stringing together prebuilt modules with if/thens is not that difficult or unreadable in textual code anyway.
- Glench 13y ago
  Regarding (3), I think if you need 25 feet of screen real estate in a graphical environment, then your code is probably not organized well, regardless of whether it's textual or graphical. Regarding (1), I think we need to understand why it's been tried and why it's failed. Knowing that it's been tried before and failed should be enough to make you skeptical, but it shouldn't be enough to outright reject something unless it's a copying an old idea wholesale. That said, I think NoFlo specifically has very few new or interesting ideas.

cam_l 13y ago

ianap but loved the visualisation space imagined / implemented for excel calculation paths in this recent submission.. i wonder whether a similar idea (ie. for viz.. not replacing an editor) would have mileage here, or would it just be so complex as to be indecipherable? https://news.ycombinator.com/item?id=6585889 https://news.ycombinator.com/item?id=6585889

Permit 13y ago
That's very similar to the effect we're trying to achieve. I was happy to see it was received well by the HN community. I think the same approach would work well in an IDE.

gnaritas 13y ago

I hate to say it, but that looks like my Smalltalk browser. Smalltalk has various built in code browsers that allow you different views of the code, your plugin behaves like one of them, the chasing browser.

ollysb 13y ago

I would love to be able to unfold method calls in my editor, something like(best I could do in ASCII) > hello_world() -------------------- def hello_world puts "hello world!" end and so on. Basically the code bubbles concept but inline. Maybe it'll be possible to get LT to do something like this in the future...