| The article has a point. We tend to fix issues with state by avoiding mutability. That is like going to a doctor because it hurts when you laugh, and they just say "don't laugh". I wish there was a language that embraced mutability instead [1]. Mutability is how the computer works at the lowest levels, and how we tend to think about the world. You would use plain old data objects to store everything. Then you would have first class observers, meaning you could have callbacks react to any changes to any object. But you wouldn't use that low-level functionality often. Instead you would e.g. create a listview, and just set it to observe the array. This is like "list adapters" that are in many frameworks, but built into the language. One thing that I'd love to be able to do is to have the data as plain-old-objects, updated frequently from one thread, and the gui living on another thread that observes it occasionally in a read-only fashion (and occasionally sends mutating messages to the backend thread). You could implement that with read-write locks, but as far as I know no framework supports it directly. Maybe this language would have a special block that takes imperative, mutating code, and lifts it to implement the command pattern [2]. You then could "undo" these blocks, coalesce them, and so on. (That doesn't work with arbitrary code, but with most code that operates on business data.) (Here are some questions I asked on StackExchange, trying to find out if something like that already exists:) [1]: https://softwareengineering.stackexchange.com/questions/2298...
[2]: https://softwareengineering.stackexchange.com/questions/3515... |
Dojo-stores, observable-collections essentially, were like that. A Dojo-view was a monitor for this. A very simple, elegant model-view design.
I agree that we should embrace mutability. The JS-code most people write now has horrible performance characteristics since we do not take advantage of the benefits of mutating objects to manage state. Instead, in JS-world, we recreate and duplicate state all the time, spamming the heap. One library doing this is not too bad, but all libraries doing this is the main cause of slow web apps.