Every developer knows the pain of the inner development loop. Make code changes, rebuild, run tests, redeploy, and examine the differences. All developers do this - from frontend web developers to backend cloud infrastructure engineers. Engineers hate repetitive tasks and try to automate everything, so it's only natural that they would try to automate this loop as well.
I call it live programming, but it goes by many names: hot reloading, hot swapping, interactive programming. It's the process of automating and optimizing the build and deploy pipeline for developers to see the changes they make in code instantly. Three forces enable the live programming paradigm:
Moore's Law. We have more powerful computers that can compile code quicker.
Standardized tooling. Docker is a standard build and runtime target that enables us to automate build and deploy pipelines.
Live programming tools need three components.
- File-watcher. The value proposition of the tool is that the inner development loop no longer becomes a manual process, so there need to be events that trigger different stages. File changes are a logical entry point.
- Runtime. Not only was packaging language-specific, but runtime was as well. Static websites could get away with generic webservers, but other use cases needed language-specific servers that knew how to hot-reload classes and functions. Docker also changed this, providing a wrapper around language runtimes.
Here are some examples of live programming tools.
- Gunicorn/Flask/Django. Live programming for python web developers.
- Pluto.jl. A notebook-like tool for Julia programmers that automatically updates all affected cells when a function or variable is changed.
- Excel. The original live programming environment. As cells change, Excel recalculates dependent cells. Developers and users can see each computation at intermediate steps.