Caterpillar

If Caterpillar's interactivity can be more effective if the application is built with an Event Sourcing architecture, and the Caterpillar language and/or standard library have features to support that, then Event Sourcing might become a kind of default architecture for Caterpillar programs. Like the actor model is to Erlang, or the Elm Architecture is to Elm.

To an extent, that's not bad. Event sourcing is great, and I've often wished for more applications to use it. If your data is important, then you absolutely should have a way to inspect and undo all changes to it. My calendar app certainly doesn't work that way, and I've suffered from that often.

But I worry that such a focus would create a perception of Caterpillar as a specialized language, when it's intended to be general-purpose. Maybe it's fine to say "Caterpillar applications are Event Sourcing applications, and it's better that way". Or maybe that paints Caterpillar into a corner that I don't want it to be in. I don't know.