Been thinking about this framing of how programing languages are these higher dimensional entities that we interact with though a textual projection that has limited dimensions to interact with. Visual programming languages are means to interact with with programming languages with more dimensions. Jumps (and other control flow like loops and branches that try to hide jumps) are one example of where this projection happens since text is sequential and allows us to link non-sequntial code into sequences. “Dimensions” is being used very loosley here, im not sure how to define it, but its not necessarily physical dimensions. For example, maybe i would consider function stacks its own dimension that is textually hard to understand (https://twitter.com/ShriramKMurthi/status/1545039706148278272?s=20&t=CeAb-qrq-XtE7nfXoxWsGA). It’s interesting to think about what dimensions we are adding to visual programming languages and how they change our understanding of the software we write! (For more https://twitter.com/chrisshank23/status/1544946015903502337?s=20&t=Ps17TClKA_8AryeeU58uOA)

Would be nice to see some ideas or (even pen and paper) sketches for visual ways to represent other dimensions (for this definition of dimension 🙂).

@Jack Rusher This kind of reminds me of this post: https://futureofcoding.slack.com/archives/C5U3SEW6A/p1656953175256199 It’s basically a 2D notebook / Bret Victor’s “show the data”

Oh, oh! This is my cup of tea. I have a sort of general project of taking a bunch of entities then using their features lay them out in high dimensional spaces with various projections to partially or entirely fold up the extra dimensions so that you can see interesting things. With programs, I like to start with an execution trace, a really long ribbon interpreter of steps, then fold it into trees and such. One standard view is to have up map to earlier, down map to later, left map to up the stack, and right map to down the stack. Then you try to squash it in various ways to make it fit. For example, pick a focal point and then shrink things or push them into the distance as you move away from that part of the call tree. One view I really like is to start with a reference graph of the state of the program at a specific time (or all times layered on top of each other, that works too, or grouping by class). Picture each object as a box of fields with reference threads tying boxes together. With this view alone, you can usually identify primitives (the empty string, numbers 0, 1, etc.) because there will be a lot of threads pointing to them. Anyway, that's just the start. Then at each field I like to stack updates to the value there. So a field is fat if it gets changed a lot. Then if you focus in on the a field, you can see all the times the field was updated or just referenced. Lately, I've been interested in charting out affinities between cards in Legends of Runeterra, the idea being that if you take the right cross-section, you end up seeing playable decks of cards. The trick here is getting a feel for when you want features to be the same vs different. For example, the easiest, if you have one Lurk card, you'll want a bunch, that's just how the Lurk mechanic works. In contrast, you want cards of different costs. You can derive as desirable property from the notion that you draw one card per turn, that you have a limited number you can play, and that you want to be able to play the most. This helps model the value of cards that help you draw cards: a card that lets you draw cards means that you can have more low cost cards without running out. So diagramming some of these relationships is the goal.

@wtaysom screenshots/video? 🙂

I wish. I can talk, and if I could show, you’d all be the first to see.

Isn't this to some extent what the mandlebrot set is all about? The visualization that arises from iterating through any complex number, where each complex number is a unique dimension.