Programming, Functions and Time

One thing that I often think about is what makes programming different than math.

Taking the overly simplified version of functional program to an extreme leads me to conclude that at a basic level, I might expect a complete equivalence between any program and a single (very long) mathematical function.

But this isn’t quite true. There is a time component in the equation. And this time component is unpredictable. This is probably the single most confounding aspect of programming, at least in my experience.

So I think that programming is like solving a mathematical equation in real time and the outcome of the equation is impacted by when and how quickly I solve the problem.

Application state and transitions are difficult to think through because I often don’t anticipate the variety of things that can happen at unexpected times.

I think that rightly many proponents of functional programming aim to maximize the number of computations that happen in a completely predictable time-independent fashion. UIKit is not written in such a paradigm and absolutely grates against such sensibilities. And rightly so!!

But animations, transitions that happen in response to user input and network responses need to happen in time and as the iOS platform is maturing, we are seeing more and more of the frameworks become less fragile with regards to time-dependence.

UIViewPropertyAnimator is a good example of this. In the past, the animation of a property was kicked off and the app didn’t have much or any opportunity to interrupt it. But now we have the ability to interrupt or even modify an animation midstream. Of course, this does come at the cost of complexity, because working out things in realtime means managing the state. I sat through the WWDC session on this. Even the basic example was a lot more complicated than just calling a simple [UIView animateWithDuration:]

I don’t have a grand conclusion. Just noodling a bit here.