Thinking in types

Types can cause a lot of pain. They tend to inflexibly demand a way of programming which isn’t always effective and can seriously slow down your work. There’s also a big ergonomics problem. Type systems are notorious for verbosity and truly awful error messages.

Yet, people who are familiar with them don’t often have the same feeling. On one hand, familiarity helps soften a lot of that pain. The bad error messages don’t seem so bad once you’re used to them. But there’s something else, too.

Types influence the way you think about programs, and that influence is actually what makes them valuable.

The way to become comfortable with types is to embrace that influence. It can change how you think about and communicate about programs you read and write. Types aren’t a silver bullet—there are problems today where it’s not clear whether they help—but they’re a really good tool to own.

Type theory on Simplicial

Practical type theory is a big topic, so there are a lot of ways to dig in and learn more. No amount of reading will replace just getting your hands dirty and practicing solving problems using a modern typed language. That said, you can learn more about how to think about types below.

  • What even is a type? lays simple foundation for understanding types as they relate to languages in one diagram.
  • Learning to love the type checker shares one quick trick for making your interactions with type checking—which often begin as horribly painful—much smoother.
  • The shapes of data discusses a foundational language of types, the algebraic data types. These end up being the same shape as the algebra you learned in high school.

Since you usually first learn about types in the context of a single language, it’s easy to get ideas in your head that are specific to how that language chose to implement these ideas. It’s helpful to understand when there are subtle distinctions worth paying attention to and the following posts identify and clarify a few of those.

  • Classes and types are different clarifies a common sticking point in thinking about types that arises due to a design hack used in some common OO languages. Classes are not types and they really don’t even behave all that similarly.
  • Unions and sums are different compares two common ways of implementing “choices” in type systems. Much of the time these two behave identically, but the subtle difference between them becomes important when you begin to write generic code.