Incremental Type Driven Development with Elm

This is an interesting presentation comparing test driven development to what Dillon calls “type driven development”. The idea is to get feedback from compiler errors instead of failed tests. This is a simple example of how types and a good compiler makes software development a lot more enjoyable. Two statements come up over and over in the presentation:

  1. make a wish, and then use the Elm compiler to help make that wish come true
  2. make the change easy, and then make the easy change

After practicing this for a few days, I realized this “make a wish” is backward from how I typically code. Typically if I needed a new function, I would write that function first, and then fill the places it is used. However, this method works much better – code up the use of that function first which helps you define what the function should do and look like, then implement the function. It is a minor detail, but is a smoother flow – at least in Elm, and I suspect other languages like Rust.

Here is a podcast that discusses this topic:

Again, the idea that you start at the end and work backwards is an interesting approach and not intuitive. In a frontend app, the UI code is the first thing you change, and then work backwards until you get to the data structures. It is more natural to work forward, but if you change the data structure first, then everything breaks and you have a bunch of refactoring to put everything back together instead of making incremental changes where each change compiles.