PurelyFunctional.tv Newsletter 443: Simulating and visualizing time
Issue 443 - September 21, 2021 · Archives · Subscribe
Design Idea 💡
Simulating and visualizing time
Last week, I said that we need richer interfaces for our human programming system. We should free ourselves from the burdens of writing thousands of small adapters for the many contexts of our lives. This week, I'd like to talk about time. We need ways to visualize the past and future of our computation.
This particular idea feels small. I was almost not going to write about it. But I decided there's no idea too tiny to bring up. It's just one piece of a much larger puzzle.
When we plan an event, we develop a schedule. That schedule is a map of what will happen in the future. By manipulating the schedule, you are indirectly changing the future. That's the magic of planning.
When people follow a schedule, they know what to do, when. They can read, for example, that they need to start the closing ceremony at 3 pm on Friday. We need to do that in our program: schedule something to happen in the future. But a lot can happen between now and 3 pm on Friday. Maybe we have to push the closing ceremony into the future because we're running late. Or we have to cancel it altogether. Any changes to the plan have to reflect in the scheduling of tasks.
Changing a schedule is surprisingly hard in most computer systems. Some queues and timeouts handle scheduling events to play later, but it is hard to change them after scheduling. It seems like most systems use a lot of domain-specific knowledge to hack something together. But we need a general-purpose, easy-to-understand way to schedule and re-schedule. At worst, it should cancel everything scheduled for that plan and re-schedule everything according to the updated plan.
But there's a step further we can take: Because the schedule is essentially a program, we can simulate time passing and see the result of running our plan splayed out over time. As we change the plan, the visualized future should change.
And why limit it to the future? Let's take an example email action. I often get orders from Amazon delivered to an Amazon Locker. Amazon emails me the code I need to open the door that contains my item. But I don't want an email. I want a text. So I have an action that runs every time Amazon emails me a code. It parses out the code and texts it to me.
But you know what? That was harder to set up than it needed to be. I had to wait for a new email to test it end-to-end. It would have been nice to replay past emails through the program to see what it would parse and text without getting a new email and without sending texts. I want to see the alternate past that would have happened had the program been different---all in real-time.
Time is fun because it's all imaginary. The future exists only in our minds. And so do alternative histories. Our computers should simulate and visualize time to assist our imaginations.
Pandemic update 😷
I know a lot of people are going through tougher times than I am. If you, for any reason, can't afford my courses, and you think the courses will help you, please hit reply and I will set you up. It's a small gesture I can make, but it might help.
I don't want to shame you or anybody that we should be using this time to work on our skills. The number one priority is your health and safety. I know I haven't been able to work very much, let alone learn some new skill. But if learning Clojure is important to you, and you can't afford it, just hit reply and I'll set you up. Keeping busy can keep us sane.
Stay healthy. Wash your hands. Wear a mask. Get vaccinated if you can. Take care of loved ones.
Clojure Challenge 🤔
Last issue's challenge
- Dijkstra's Algorithm - Submissions
No challenge this week
Rock on!
Eric Normand
