That's an interesting way to describe it. I've talked a lot about immutability at conferences, but I've never thought about it in those terms. Thanks.
Basically, if you use persistent data structures and a unified application state, you can keep a list of all previous application states and you can browse it or ship it for debugging, it's not that expensive.
[0] in debug mode, you get a list of all events having occurred in your application and can instantly move back to that state, and you can import/export that state history: http://elm-lang.org/blog/the-perfect-bug-report
Library: https://github.com/arximboldi/lager
Ncurses example (full text-editor): https://github.com/arximboldi/ewig
SDL example: https://twitter.com/sinusoidalen/status/939539173584916480
Immutable data: https://github.com/arximboldi/immer
(There was a talk about Lager at MeetingCpp this year, still waiting for it to be published online...)
I'm guessing you mean good in the sense of well-implemented (performant), but I think good in terms of interface is also very important
For instance in my experience & opinion Immutable.JS is not very fun to use regardless of its implementation, because the interface does not feel natural for the language (not that the designers can really be faulted, the user-accessible part of the language simply limits what they can do). I think a similar library for Python would have similar issues (due to Python being very statements-oriented which is antithetical to persistent data structures).
It also has the ability to really take any object and attach states to it at whim, including immutability.
I think that’s a better trade off than JS
> Python however does provide some immutable constructs as part of it’s core language (Tuples)
That doesn't really help when you're looking for persistent datastructures.
> It also has the ability to really take any object and attach states to it at whim, including immutability.
No, and if it did that would not be an advantage in this context.
At work, we are pondering on a new way to split our game levels editing code, and persistent data structures came to me as one idea, in order to handle UNDO in generic way, and they by diff, or other means visualize the changes. I've read Okasaki's book long time ago, but seeing this implemented in a imperative language is really helpful.
Also pretty much enjoyed the post-modern talk too :) - hehehe
Thank you!
Editing code for game levels seems to me like a quite good use-case for this. "Editing" software with rich hierarchical documents is the itch I originally wanted to scratch with this work, even though there are many other use-cases too. Feel free to send me an email if you move further with that idea or if you want to discuss any of these topics with me :-)
I actually have a half-started emacs-like editor built using Qt that is based on ewig. Not anywhere near usable yet, but my plan is to make a fast editor with fast highlighting and such, and have everything accessible to be scripted in guile. I doubt it will actually materialise, but if I ever get a proof of concept it will be on github.
I love immer! It is friggin excellent.