I mapped out a huge list of prior art for visualised LINES of memory in coding environments. I've annotated the LINEs in each example. Please check it out and let me know if it prompts any ideas/thoughts! And if you know anything I could add, please send em over! https://www.todepond.com/wikiblogarden/see-it/prior-art/

i gotchyou

I don't get this, like 90% of what @Lu Wilson does 😄 But I gather that's at least partly the point? ♥️

What is a LINE?

a visualised LINE of memory

Sorry, this is probably obvious but I don't know what a line of memory is

found a few more possibly valid lines 👀

Ok this might be a bit of a stretch (what IS a LINE??) but there's some overlap with how tables work (the free form ones that you can draw on a paper or a spreadsheet). Tables are basically a bunch of interleaving lines thrown together on a surface.

@Rafi Khan sure thing :) data is stored in our computers. it's stored in "memory" so that it can be retrieved, and edited, and moved, and manipulated, etc. that memory is often stored in an arrangement of a "line". for example, in an array, or a stack, or a heap, a register, RAM, list, etc... sometimes we might want to "visualise" this line of memory, so that a person can "see it". maybe to understand it better, maybe to debug a problem, maybe to learn. so... how do we visualise it? what's the best way? I've been collecting up this list of visualised LINEs to learn about what's already been done. @Kartik Agaram this explanation might help you too!

Yeah I think so? I've been thinking of 1D ranges as just a degenerate case of 2D tables and it all works out the same way (wrt visual LINES). I'm curious about what other kinds of 1D visualisations you're thinking. The examples you've collected seem to cover a wide variety already.

yeah i find it interesting how there doesn't seem to be a universally agreed way of representing it visually. i don't think it's because of domain-specific differences. to me, it suggests that it hasn't been figured out yet

In some of the examples I'm squinting and it seems like the lines would apply to any representation, not just drawing out memory (that's how I made the jump to tables). I'm guessing since memory is sequential physically, drawing a line to talk about it would come naturally: "follow the line from left to right, that's how the memory is laid out."

could you expand on what you mean by "apply to any representation"?

So if you want to visualise a list of Names, putting them in a LINE makes sense because you can follow it from top to bottom. If there is some sequence applied to it (let's say alphabetical), the sequencing is inferred by which name comes up first in the LINE. On top of this, you can put a "label" at the start (at the green rectangle) to give the line a name. This is not representing physical memory, it's some abstract list of names.

This is not representing physical memory

i would challenge that :) it's a 'representation', not a photo, so it doesn't need to be accurate. I'm not interested in accurately depicting memory - i want to visualise it in a helpful way, even if that involves lies

i want to visualise it in a helpful way, even if that involves lies

Haha I see. That is an interesting problem.

> wdym? I think I might've misunderstood what you mean by memory. > when we're coding, we often try to imagine what the memory in our program is doing. "ok so the array looks like this... then it changes to this.... oh wait i can see the bug" "ok so these three variables are in the local heap with these values... and i read from this one and... oh wait I can see I'm reading from the wrong one" "ok so the buffer for the image looks like this... and I'm getting the coordinates from the index like this... and... oh wait i can see an off-by-one error" it's helpful to visualise the memory in our program. maybe we visualise it in our head, or on a drawing, or maybe our tooling visualises it for us. in all of these cases, the visualised representation is a highly abstracted view of that memory, because its purpose is to be helpful to a person - to help us reason about our program. if they were accurate portrayals of the memory in our program/computer, then they wouldn't be helpful at all. they would be completely obfuscated with strange symbols and numbers, with lots of boilerplate not intended for humans. the compiler's (or runtime's) optimisations would further disguise the behaviour of the program, and all-in-all, it would be a confusing mess. the "true-est" representation would be seeing the binary bits in pure ones and zeros (maybe), and that's clearly not helpful. so I'm not interested in visualising an accurate depiction - i want to visualise a helpful representation hope that explanation helps!

That makes sense, thanks! I guess what I'm coming at is lines and tables seem like a solid starting point 😛

Ok, this is a lot less Dadaist than I first thought. I'd like to suggest a new acronym: IANAL. Is Always Not A LINE. We have plenty of examples, now need some IANAL counter examples. I think that Dali painting is a counter example, for example. Thoughts everyone?

bit of a naughty sounding acronym perhaps @Kartik Agaram 😆 maybe A-LINE (using alpha privative) or N-LINE for Never a LINE?

The joke is it stands for I Am Not A Lawyer 🙂

oh! learnt something new!