Caterpillar

Event Sourcing is a software architecture in which every change to application state is encoded as a value, an event. These events are executed deterministically, so you can use them to reconstruct any past state. And if you add the required information to these events, you can also undo them, rewinding to an earlier state.

Over the last few days, I've been talking about how to step backwards through a Caterpillar program. If Event Sourcing is to play a role in supporting this, then the language runtime and debugger need to understand events. Where they are stored, how to apply them to application state, how to undo them. All of this implies a pretty close relationship between the Caterpillar runtime and an application.

The runtime would act more like a framework than a typical language runtime, which certainly wouldn't be a good fit for all use cases. But thanks to the platform concept, it could be optional. Maybe I can come up with an approach that allows applications to easily opt into event sourcing functionality when they want to improve their interactivity, without weighing down applications that don't need it.