How do Elm programmers write code?

As Elm developers, we often hear things like…

• “First, define your types right; then, the rest of your program will follow”
• “Use your compiler as an assistant” (with thanks to Evan Czaplicki)
• “Make impossible states impossible” (with thanks to Richard Feldman, and, earlier, Yaron Minsky)

…but what does that look like in practice?

• How do we actually construct types “right” in the first place?
• What aspects of the compiler do we really use as an assistant?

I’m fascinated by these kinds of questions! If you are too, you might be interested in participating in an IRB-approved research study I’m running!

Participation entails installing an editor plugin I made that:

1. Locally logs all changes you make to a programming project of your choice.
2. Occasionally asks you to redact sensitive information and for permission to upload the data to our server.

We will publicly release these logs for researchers to analyze, which we hope will help authors of tools for languages like Elm align their tools to programmers’ needs and existing behaviors.

If you write Elm code and are interested in participating in this study, please click the button below to go to our (non-binding) sign-up survey:

It’s worth mentioning that we will not publicly associate your identity with the data we publish. However, someone could associate you with these logs if you leave personal information unredacted or host the code elsewhere that has your identity associated with it, like GitHub.

For more information, please feel free to take a look at our informed consent form!

About the authors

My name is Justin Lubin. I’m a computer science PhD student at UC Berkeley working with my advisor, Professor Sarah E. Chasins. For the past year and a half, I’ve been studying how programmers write code in statically-typed functional languages like Elm. I’ve published a paper on this topic (with a Twitter thread and video, too!), and, with this study, I’d like to significantly expand some of the analyses I did for that paper. This will only be possible with the help of programmers like you, so let’s make the future of statically-typed functional programming even better—together!