15.5.14
Elm's time-travelling debugger
So what does a debugger look like for a high-level language like Elm? What is possible when you have purity, FRP, and hot-swapping? At Elm Workshop 2013, Laszlo Pandy presented the Elm Debugger. Inspired by talks like Bret Victor’s Inventing on Principle, Laszlo implemented a debugger that lets you travel backwards and forwards in time. It lets you change history. On a deeper level, it lets you visualize and interact with a program’s meaning. It lets you see how a program changes over time.Evan Czaplicki, Elm's inventor, explains why the features of Elm make this surprisingly easy.
It is possible to change a program so much that it is no longer compatible with previous versions. If we try to hot-swap with incompatible code, it will lead to runtime errors. The programmer will be left wondering if their new code introduced a bug or if it was just a case of bad hot-swapping. Perhaps they start hunting for a bug that does not exist. Perhaps they ignore a bug that does exist. This is not Interactive Programming, this is a buggy IDE.Previously: Bret Victor's Inventing on Principle.
To make hot-swapping reliable, we must know when programs are incompatible. The more precise we can be, the more reliable hot-swapping can be. There are two major categories of incompatibilies:
The ability to diagnose and respond to these issues depends on the language you are working with. We will now see how both cases can be addressed with features like static types, immutability and purity, and predictable structure.
- The API has changed. If the types of the arguments to a function change, it is no longer compatible with the rest of the program.
- It is not possible to copy the old state into the new program. Perhaps there are now many more values and it is unclear how they relate to our new program. Perhaps functions are tightly coupled with state, making it hard to change either independently.
Labels: Computing, Functional Programming, Programming Languages
