Hacker News Reader

Comment by breck | Hacker News Reader

My big bet (10% confident it's correct and will be world changing), is that having languages that rely on spatial position of tokens in a 2D or 3D grid will be a big leap forward and make 3D visualizations quite natural.

I think 3-D visualizations of 1-D languages (all our current programming languages are 1-D) will not be so helpful, as you will be looking at transformations, not the actual code as it exists.

If anyone is intrigued and wants to write a function that takes as input a parsed Tree Notation program (https://jtree.treenotation.org/designer/) and outputs a a https://www.mecabricks.com/ file, get in touch! I could even fund something like that, if needed. Such a function would then be able to generate a LEGO version of any program written in a Tree Language. From there, I think there could be interesting discoveries to be made related to future version control systems and collaborative editing algos (I think you could beat CRDT/OT/et al).

View on HN

I have also been thinking about building something like this.

I believe there should be a presentation layer separate from the code. Give people tools to build an empty building (or city) via floorplans; allow them create pleasing spaces in VR. Then the actual code machinery (literally represented as machines) is built inside the various rooms.

My hope is that organizational/bikeshed concerns are funneled into the architectural/interior decoration layer, whereas engineering is housed in those 3D spaces relatively undisturbed. The needs of the code would exert influence on the architecture as new spaces would be required for new functions, or rooms would be rearranged to better reflect dependencies and coupling.

> I think 3-D visualizations of 1-D languages (all our current programming languages are 1-D) will not be so helpful, as you will be looking at transformations, not the actual code as it exists.

This is the part that I disagree with. The source code is linear, sure, but the structure that ties the different components in a codebase together is high-dimensional. For example, the symbol usage graph is really useful to visualize in 3D, as is the general package structure.

And most of these visualizations we see don't even touch on runtime analysis like I was working on! There, seeing different types of data arranged either by where the data is coming from in the source code or where the data is coming from at runtime (analogous to lexical vs. dynamic scoping) is a visualization that benefits from 3D.

Yes, I'd agree with you. My wording was poor. I should have said something like "will be helpful, but far more complex to build and use, as they will have to rely on abstract transformations, rather than the natural shape of the code".

I could still be wrong, and really need to get those experiments going again! Thanks for pushing back on that and causing me to think harder.

P.S. I also think runtime analysis is an even more complex problem, and applaud you for attacking it!

100% agreed. The translation from source code to 3D visualization was ultimately based on choices we made, not on the inherent structure that already was put in place by the developer. The output was still valuable, but when the developer has a say in the output, that's when so much more power would be unlocked!

Reply on news.ycombinator.com