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.
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 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.
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.
No comments:
Post a Comment