Holographic source code | Hacker News Reader

Holographic source code

johndcook.com

29 pointsllambda13 comments

I wonder if this is something that could at least be partly offset by an IDE. Highlighting a function and instead of being able to jump to the definition, it sticks the code for that function where it is being called (initially, only as a view, offset stylistically).

That way you can expand the selections and see what is going on from an actual code standpoint without jumping from file to file, but you could jump to where the actual source is, if you want to go change it.

Many times I've dreamed of having such an IDE. I'm sure others here have too.

Anyone ever tried writing it? Just wondering if there's a reason why it doesn't exist yet.

I once wrote a parser that did this for a large and undocumented Object Pascal project. The problem is OO code enables run time binding to objects and functions, so your compile time decoder often returns ambiguous results. However, I found simply including possible code paths was still useful because they tend to be related functionality to what you are debugging.

Interesting, it could work like code folding. Bonus points for graying out dead code paths according to arguments given. Modification could very well be in place as the folding can be a partial inline buffer.

Sounds somewhat like Code Bubbles:

http://www.andrewbragdon.com/codebubbles_site.asp

It's a similar approach to the same problem. Code Bubbles make the jumping more palatable. I'm not sure you would need such a drastic change to the traditional IDE look to implement what I describe. You could (for instance) simply have the code (set off stylistically) expand in-line pushing the code below it down the screen. This would get rid of the jumping altogether.

Of course this approach raises its own issues. Can you expand a function within an expansion, how would that look, usability, and so on.

http://msdn.microsoft.com/en-us/devlabs/debuggercanvas for Visual Studio 2010 Ultimate.

> At least that’s what I’ve heard; I don’t really know how holograms work.

Followed by a number of paragraphs incorrectly comparing things in code to his incorrect model of how holograms work. Come now, I'm sure we can talk about things like code without having to compare against things we don't even know about. Or, at the very least, we can read a wikipedia article beforehand...

His understanding of holograms was incomplete, but not incorrect. His summary at the top ("information about each small area of image is scattered throughout the holograph. You can’t say this little area of the hologram corresponds to this little area of the image.") is just fine as far as it goes.

It's just a metaphor. Maybe it's a bad one, but if it is then you have to make that case, not argue against it based on a technicality.

Can you measure this aspect of code quality automatically? Perhaps it's not that much about code redundancy and how much does the execution jump around; it's more about making changes on multiple places to implement a single "thing" (like a bug fix). This info can be inferred from the source control system.

"The execution sequence of the code at run time is almost unrelated to the sequence of lines in the source code."

Looks some Node.js code I saw last week. Anonymous functions are cool, but some things deserve names.

You can think of looking at a hologram like looking through a window. You can move around and see any part of the scene through many parts of the window / hologram. Cutting a hologram in half, left-to-right, is just like looking through a window half the size. You can still see the whole scene, but your viewpoints are limited.

The other comparison I'd make is to normalized vs. denormalized databases. Normalization has been pushed for decades to reduce anomalies that are not dissimilar from those that occur in copied-and-pasted code. Yeah, wonderful, but that same normalization can pose problems when the data gets sharded across many servers and even simple queries end up requiring many connections. Similarly, centralizing logic can become a problem when that logic becomes a contention point for competing patches etc. Sometimes you really are better off with several less general versions of the same thing instead of one highly general version.

Reply on news.ycombinator.com