Ancient Roman emperors used to frivolously take the freedom to define what time is and when it starts. The day of their incoronation was a popular choice to start year 1.
In physics, time is defined by its measurement: it is what a clock reads.
Given the Roman Empire is no longer a threat to barbarism, we can arbitrarily play with the definition of time as it fits our needs.
My goal here is to critically review the core concept of functional-reactive programming which says everyhing should somehow be a function of time.
However, when building user interfaces, time can be referred to both as continuous dimension (think smooth animations, where d=f(t)) or just as a series of events that happened (e.g.: "after the user clicked 3 times on a button").
A core concept of functional-reactive programming is that everything is a function of time.
In theory this is unchallenged, but what this implies in practice is that everything can change at any single moment, so we need to keep vigilant and recalculate the state of everything on a continuous basis, which is computationally expensive, inconvenient and drains laptop batteries very fast.
With the exception of FPS games, animations in the UI just start and finish, while the rest is actually event driven and mostly discrete. A button's state changes when hovered or clicked, irrespective of how many seconds have passed. Does the hover effect involve a transition or animation? Then it's the transition's starting moment which is event driven, the animation itself can be a function of time, and its completion, again, another simple "FIAT timestamp".
FIAT Time
Just as we have Fiat Money, we can have Fiat Time.
Time is what we say, however we measure it:
- "after the user dragged an object"
- "before the server returns data"
- "between the 2nd and 3rd clicks on the background"
- "when animation X just finished"
Nothing else matters. When there are no events happening in a UI, nothing actually changes, time is effectively frozen.
The convenience of events as a time measurement
If we define time as a sequence of events that happened in the past, we can model any further action/reaction in a consistent way, whether that happened fifteen seconds or fifteen minutes later, which for the most part doesn't actually matter.
Turns out we already have some excellent libraries that handle event streams based on what happened instead of when (think RxJS).
If we just blur the definition of time in terms of what happened instead of when, things suddenly become simpler to manage and to test as well.
Time is still relative
Thinking of time in relativistic terms? Sure, probably no exception here: event-driven time is just as relative and changes differently (and more dramatically) for every UI component that depends on it.
Does relative time pose a problem? Not quite. All mature event stream libraries provide operators like combineLatest, zip, withLatestFrom, that make it trivial to reconcile different event sequences into a new one.
So, by assertively redefining time as a sequence of events, can we force certain programming patterns like RX Observables to fall under the functional-reactive programming umbrella?
If everything is a function of past events, and time is a function of past events, then everything is still a function of time.
What are your thoughts?
