Hacker News new | past | comments | ask | show | jobs | submit login

If you could make all events reversible (exactly), then why would you need to rewind to state 1 and play back to the requested time for every frame?

Also, sweet game! I actually just introduced it to my gf last week.




Someone has implemented a PL based on this circa 1982:

https://78462f86-a-feb80ac8-s-sites.googlegroups.com/a/tetsu...

It is not very practical, however. Many operations that you'd want to do are not time reversible without saving things.


That's interesting. So, is a time-reversible language Turing complete? How would one write a trap-door function in a time-reversible language?



You could do that, but then you aren't storing events any more, you're storing world state again. (That is what it means to make events reversible .. or at least that is the straightforward way I would think to do it.)


It reminded me of Martin Fowler's "Event Sourcing" paper from the enterprise world http://martinfowler.com/eaaDev/EventSourcing.html

So as a bluntly simple example, assume the entire world's state is just the number 100. Instead of storing 105 as the new state, you store {:increment, 5}, and somewhere, the reversible counterpart to increment is defined {:decrement, 5}. You're correct that a full global state would have to be stored at SOME point, but could you simply hold the initial state, and the current state, and work from either of those?

Or just do what the mp4 video algorithm does and store so-called "keyframes" every N frames which store the entire state, but all intermediary frames are just diff frames.

Many web apps end up needing a global event feed/stream that various processes hook into via publish/subscribe. In theory, these events are reversible. Of course, in practice, individual types of events may find difficulty, especially if they have side effects that are outside the control of the app developer




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: