Types: When I use, when I don't.

Tomer Ben David - Mar 20 '18 - - Dev Community

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.
  2. Undefined is not a function forget about it with ELM.
  3. A misleading variable name: it was phone number but I got an email.
  4. 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.

. . . . . . . . . . . . . . . . . . . .
Terabox Video Player