Types: When I use, when I don't.
Tags: programming, functional, java, languages
Published: 2018-03-20 19:51:26

---
title: Types: When I use, when I don't.
published: true
description: For large apps I use types.
tags: programming, functional, java, languages
---

## Introduction

**Below is my personal perspective** :)

If I write a one-page program, I don't mind having no types, zero types, **-1 types, and I'm happy with it**.

If I write a bigger app, handled by multiple team programmers, which is expected to be maintained, I consider types to be a must! I'm still happy with it!

## When I like types

Today modern languages have `type inference`, so the typed code looks very much concise as non-typed code, `Scala, Haskell, OCaml, Kotlin, ELM`, concise typed code pretty much is both pretty and rules!

## When I don't like types

We still need **to compile it, it takes time**, but I'm willing to pay this price, the maintenance time and **code understanding time**, is also time. Time is time, a second is a second, I would rather pay seconds or even minutes of compile time for hours of unusual bugs and code readability time.

> Type Inference + Types => Concise readable code!

But still sometimes you find yourself waiting for the compiler, I tend to grab a coffee :) but this is like **the less enjoyable type time**.

## Performance penalty for type inference

You pay the price at compile time.  As mentioned earlier, **I prefer to pay someone to compile than to pay someone to read and not understand the code.**

> Programs that are hard to understand are also compiling slower.

So if you write readable code it will compile faster ;)

## Parametric polymorphism

> Parametric Polymorphism: Same subtype [A] for the container which we defined.

`Array[A]` So you can have a single implementation that does something with the array and uses it for the different type - `polymorphism`.

## Subtype Polymorphism

You inherit in order to have multiple implementations.  But you end up with one big giant object (the class hierarchy) for me that is like a global ball of mud-code.

> Subtype Polymorphism - a big ball of mud-code, there are multiple types when you traverse the array.

## Simple Type System

Like in `java` **we still go so much benefit of tooling**, what our functions are doing, how the program is constructed.

> Simple type systems give us great tooling!

> Simple type systems give us great documentation checked by the compiler!

You need to explain to the compiler what you mean with those non-type inference languages.

## Rich Type System

(like scala, ocaml, haskell).

> Rich Type Systems allows us to have the clean simpler code!

This sounds unnatural but takes for example `generics` to express a single code which can be used polymorphically over types, code reuse.  I return Int, Double don't care I return `A` but I do return `A`.

## Rich Type Systems Catch Bugs

> Lie: If it compiles it works!

I don't treat this as a truth.  But many bugs just vanish:

1. Null Pointer Exception, I don't remember having one since using Scala.
1. Undefined is not a function forget about it with ELM.
1. A misleading variable name: it was phone number but I got an email.
1. Forget to change a name of a caller after a mini refactor.

## Summary

My summary is very simple, for code which would require maintenance by new developers and is not a single page project, I use typed languages, for simple scripts and short code snippets, no types.