3 ms·
Heh, check out time-travel debugging and be amazed at how simple a much more powerful “undo” can be made when purity is involved (in FP langs, e.g. Elm or Haske
by Tehnix 9y ago
Heh, check out time-travel debugging and be amazed at how simple a much more powerful “undo” can be made when purity is involved (in FP langs, e.g. Elm or Haskell).
Seriously though, design wise there was not much you said that was specific to OO. Take for example:
- all actions are a data type
- the history is a list of actions (in LIFO style for the purpose of simplicity here)
- undo pops the list and puts undo in another list
- redo replays the undo list onto the history list
A bit more outlined, but nothing OO there, it was in fact entirely functional.
- dfguo 9y agoThis is a way simpler approach vs the OO way described above. The OO way requires undo/redo to precisely cancel each other, which is extremely difficult to get right.
- maxxxxx 9y agoIsn't the real difficulty of undo the implementation of the undo method for each action? T The action list seems easy.
- yen223 9y agoStore a list of actions, and represent your state as a sum of said actions. That way, no matter what the action is, "undoing" an action is literally just popping it off the list. actions = [append("The"), append(" quick"), append(" brown"), append(" fox")] state = reduce(actions, some_combiner) // This might give you a string "The quick brown fox" If you pop the last element `append(" fox")` of the actions and rebuild the state, you can easily see that the new state "The quick brown" is simply the old state without the last action, i.e. an "undo". If rebuilding the state is expensive, it is not hard to devise caches around state management under this model.
- maxxxxx 9y agoMakes sense. But i don't see how this is related to OO vs FP then. Putting all your actions into a list is easy. Replaying is easy. The main problem is caching the state which can become tricky no matter OO or FP.
- yen223 9y agoYou're right in that nothing about this is specific to OO or FP. However, under this model, you really don't want your actions in the actions list to change after the fact. That means those actions in the list really shouldn't be modeled as "objects" with object-like mutable internal state and all. In fact, you'd probably need them to be as lightweight as possible, which means no sticking methods on them. With those constraints in mind, OO-style code brings nothing to the table.
- maxxxxx 9y agoI think this unfortunately goes into the same direction a lot of political discussions tend to go. Two rigid philosophies and one has to win. In the real world either one can work if applied correctly. And both can learn from each other. FP brings a lot of interesting concepts to the table that are useful. But I doubt that people that screw up OOP will screw up less with FP In the end competent and disciplined (in my view the number one attribute of a good dev) people will produce good software with any paradigm. Clueless people will cause problems no matter what the tool is.
- Tehnix 9y agoMy arguments was actually just that it had nothing to do with OO at all :) Caching becomes a lot easier though in a pure functional programming lang though, and in a lazy one happens automatically for a lot of things.
- pjmlp 9y agoAlready present in Smalltalk, Lisp and Mesa/Cedar development environments at Xerox PARC, no need for FP advocating for it.
- Tehnix 9y agoI guess immutability is the actual thing that makes it easy, and arguably Lisp is also an FP lang. m Main point though was the ease of doing it in a pure language, almost trivial.