Putting Down Elm

The more focused on a task I am, the more difficult it is to be pulled away from it. I try to break tasks in to smaller pieces to minimize the impact of this forceful ejection. Unfortunately, fear of disruption does not usually lead to a natural subdivision of tasks.

I don’t have this fear with Elm.

As Adam Waselnuk puts it:

As you program in Elm, you follow a delicious breadcrumb trail of extremely readable compiler error messages until the program compiles and everything works.

In my experience so far, I’ve found this to be true. Those breadcrumbs will still be there when I return later. The error messages from the Elm compiler become a sort of continuation that I can use to pick up right where I left off, even days or weeks later. Fixing errors as the compiler presents them to you provides many natural stopping points.

I thought Elm was a pure, functional language, but this is one hell of a side effect.