Great question. What could physical squishiness allow a computer to communicate to a programmer, or vice versa? Could the degree of softness mean something? Could interacting with a soft thing allow you to express something that you couldn't if that thing were hard? Might the softness just change the way it ~feels~ to do computation, so that the difference isn't some technical capability but rather a change of mindset or mood?

In other words, where does the softness go?

In other words: is the squishiness essential or incidental? Would its purpose survive high-resolution discretization?

Can you explain what you mean by "high resolution discretization", Konrad? Is this a reference to the character grid in textual code?

Ya the reason I asked is because i really struggle to think of ways it can be essential to the computation (except in games and physics simulations).

I like the idea of representing memory in a squishy way

Tightly packed areas of memory fighting for space and squishing and morphing together as they shrink and grow

For the squishiness to be meaningful for computation it would have to happen through collision between objects and/or the space the objects take up?

Imagine a function that balloons as it does more computation and must stop when it is squeezed out of space to grow

Another approach would be to take an existing visual programming approach and think about making parts of it soft. Like, if you have node-wire, and the wire gets wrapped around some nodes and it kinda squeezes them a bit.

The essence of digital/computing technology when interfacing to the real world is (1) projecting continuous quantities to discrete ones and (2) imposing context-free laws of change or transformation. Squishiness is about adapting to context. That's not naturally part of formal systems, it has to be imposed as a condition.

Tightly packed areas of memory fighting for space and squishing and morphing together as they shrink and grow

• B-trees are a bit squishy/sticky in how nodes get joined/split. So are all structures with amortization ? But that's a well-encapsulated property, hardly observable.
• Cuckoo hashes get harder to insert into (more pushing stuff around) as they fill up. That's observable as a slow-down (like regular hash tables) but still correct. Well, unlike regular hash tables at some point the guarantee that you only need to check N places really breaks down, but I suppose then you resize and re-hash the whole thing, so the effect is "slow down with amortized resize" similar to regular hashes.
• Bloom filters get less precise as they fill up. Now that's really observable to the user. So do other "sketch" structures. But frequently they're used behind some other fallback (e.g. cache miss=>do the network request) that reduce the observable imprecision to observable slowdown.

So in all those, squishiness might come handy to visualize algorithm internals , but doesn't map to anything desirable in the final product of computation?

Speaking of visualizations, spring-model layouts are handy for evolving graphs (e.g. gource.io) and are also promising for real-time "collaboration" between automated + human-moved layout, because mechanics are intuitive and predictable to our brain.