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.
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.
> 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.
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.
[+] [-] michaels0620|14 years ago|reply
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.
[+] [-] lt|14 years ago|reply
http://www.andrewbragdon.com/codebubbles_site.asp
[+] [-] lloeki|14 years ago|reply
[+] [-] mattmanser|14 years ago|reply
Anyone ever tried writing it? Just wondering if there's a reason why it doesn't exist yet.
[+] [-] daeken|14 years ago|reply
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...
[+] [-] ajross|14 years ago|reply
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.
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] ntoshev|14 years ago|reply
[+] [-] rbanffy|14 years ago|reply
Looks some Node.js code I saw last week. Anonymous functions are cool, but some things deserve names.
[+] [-] sp332|14 years ago|reply
[+] [-] CPlatypus|14 years ago|reply