Why is shared mutable state considered bad? Isn't ...
# thinking-together
c
Why is shared mutable state considered bad? Isn't it an accurate reflection of the universe we live in? The problem with SMS seems to be that it allows for an explosion in possible execution paths that the programmer didn't anticipate. A more natural way to solve this problem might be to make the programmer more aware of what is actually happening, rather than limiting the use of SMS. I think this whole thing is a symptom of programming languages introducing parallelism after the "read-lines-one-by-one-and-track-state-in-your-head" paradigm of coding was already set in. If an IDE showed you a lockless function that mutates state, not as a clean one-by-one list of instructions, but as the bizarre tangle of spaghetti it actually is, people would avoid issues in a more natural way. Another way to think of this is two programmers sitting side by debugging the same function out loud...
Copy code
programmer 1: Ok... if x is less than 5, set y to 3
programmer 2: Ok... set y to -5, then if...
programmer 1: Hey what are you doing? I want y to be 3
programmer 2: No I just set it -5
...
Yeah, this is kind of chaotic but it's actually, in a way, very "natural" and "easy to understand". Not easy to solve, but very natural to see that it's difficult to solve. Basically I think that mutating global variables are actually the most natural way for a human to understand procedures, and supposedly "clearer" methods like FP are only popular among people with very strong mathematical ability, who have also already internalized powerful abstraction abilities that they no longer realize are unnatural, and have also already experienced the difficulty of trying to understand parallelism with only their brains. These people welcome the unnatural constraints of FP with open arms. People coming to programming from the real world, do not (in my experience) welcome the constraints of FP at all. It's very interesting to me that Dynamicland appears (from afar, I've never been there), in it's pursuit of a more natural and "humane" programming, to have basically gone completely the opposite direction to FP. As far as I can tell the entire room/operating system operates on a single massive global database.
👍 5
w
Bret Victor’s perspective when I asked about this: https://twitter.com/worrydream/status/1097521873905217536
c
Very interesting response from Bret but I don't think it quite addresses the issue head-on. It's very difficult to say without knowing the details of how Realtalk works. How do I program something that closes the door, then dead-bolts the door? How do I do that in a world where someone else wants to open the door and drive a robot through? This sort of thing requires ordering and locking across wishes, surely?
I'm essentially on his side, and obviously the physical nature of Dynamicland is a major help because the real world is, unquestionably, shared mutable state, but he doesn't really explain how the problems of SMS are solved. This is basically the area I am most interested in. I think it needs new ideas in visualization to express the inherent complexity in something like the door locking example and then make it easy to express a solution
g
one thing I find interesting about his point #3 is that the primary i/o device for DL is physical state, and the machine has been designed around it. I often feel like the problems with programming languages boil down to the gap between doing something trivial and useless ("hello world") and something useful (todo list). at least, that was my experience when I learned programming a few years ago. I think that designing DL from the inputs outwards has been a pretty unique philosophy that affected how intuitive it is for kids to start using it (very papert)
d
It's a solved problem. As long as you give up your FP straitjacket! It's not either/or.. you can have:
the real world [being], unquestionably, shared mutable state
and pure (non-Turing Complete, non-tail-recursive, fixed-point-seeking, finite-iterating) functions to transform between successive evolutions / mutations of bits of that state. I sometimes think both sides, FP-based thinkers and shared-state thinkers are blinded to the obvious.
Looking forward to the Realtalk write-up as it sounds like it may have similarities to this approach.
Give me a problem and I'll show you how to solve it this way! Not sure I understand what's the issue in the challenge above, though:
How do I program something that closes the door, then dead-bolts the door? How do I do that in a world where someone else wants to open the door and drive a robot through? This sort of thing requires ordering and locking across wishes, surely?
In the Real World, the person who wants to open the dead-bolted door can't get in.
c
I mean how do you ensure the "lock door" wish is only fulfilled when the door is closed, without coordination between wishes, couldn't the "open door" wish from user 2 be fulfilled in between user 1's "close door" and "lock door" wishes?
d
Yes. Just like in Real Life. 😁
w
In a way, space is nothing but the causal disconnection of things. Mechanical mechanisms are comprehensible in a way since you always need a shaft or a line connecting things that interact. Without those limits in a SMS system almost anything can happen. So yes isolating things helps and sometimes is enough but not always and then what? As @Chris Knott suggests, making the invisible connections visible can help reveal how knotty a system is.
🍰 1