Skip to content

Instantly share code, notes, and snippets.

@JoelQ
Created January 6, 2020 21:12
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save JoelQ/50a922c3614735483c119e019fd77382 to your computer and use it in GitHub Desktop.
Save JoelQ/50a922c3614735483c119e019fd77382 to your computer and use it in GitHub Desktop.

A Number by Any Other Name

Abstract

In 1999 NASA’s Mars probe infamously crashed due to a unit of measure error. 20 years later we still write the same bug. Join me as we leverage Elm’s type system to catch these, get better errors, and improve readability. Along the way we’ll challenge some common assumptions we have around numbers.

Description

Many bugs are caused because of mis-matched units or because a bunch of number arguments got passed in the wrong order.

At the heart of these bugs is representing many different kinds of things using the same type: raw numbers. The compiler can help us here if we communicate to it what the different raw numbers mean. We need units with our numbers. This talk will look at using Elm’s custom types to model these.

As a bonus, in addition to greater type safety we also get better error messages and better readability for humans.

We’ll explore what it means to think of values as both a unit and a magnitude rather than just as a raw number. Some assumptions we have around numbers are just plain wrong.

For example, should I be able to multiply $3 * $5 ? At first glance, yes. Once we start thinking about the units though it doesn’t make sense. We’d end up with 15 dollars-squared which is not the unit we wanted. We realize that multiplying dollar amounts is a nonsensical operation in our system.

Adding units to numbers in our system helps the compiler catch bugs and it helps human coders reason more clearly about their system.

Notes

This talk is aimed at all experience levels. We’re going to use some basic arithmetic and some simple custom types. As developers we tend to play fast and loose with numbers, often with negative consequences. This talk will be a mix of practical solutions to avoid those bugs as well as examining what it means to do operations on numbers.

Last year I gave an Elm talk that was highly rated for having an approachable mix of practical “how to fix $PROBLEM” and philosophical “what leads to $PROBLEM”. This talk aims to take a similar approach to the problem of working with numbers. Not sure if this section is blind but if you want to see last year’s talk you can look me up once you have access to my bio.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment