Static Types and Shovels(carefully.understood.systems)

Static types and shovels

I have a simple theory about why static typing became much less popular in the
2000s to early 2010s and started to get more popular again around the mid to
late 2010s. It isn't because programming is a fashion led industry, but
because the quality of the static type systems that were widely available
improved.

Here's an analogy: say you want to dig a hole, would you rather use a shovel
or your hands? If the shovel is any good then obviously you'd use the shovel.
But what if the only shovel available to you was made of paper? You'd just be
flailing uselessly at the ground with it. You'd be better off digging
barehanded.

With a dynamic type system, you have to do all of the thinking about the
states and contents of the variables and fields in your program yourself, with
your own brain. The computer doesn't help you at all, nor does it hinder you.
It's analogous to digging with your hands.

On the other hand, if you're given a poor static type system like the ones
that were popular in the 90s and early 00s, such as the ones in early Java or
C++98, it's analogous to a paper shovel. These static type systems fail to
even help you with simple things like distinguishing nullable from
non-nullable pointers. They don't have sum types, only product types.
Meanwhile they require you to spend a lot of effort manually writing out type
names all over the place.
BufferedReader bufferedReader = new BufferedReader(new
FileReader(filename));
is a small disaster.

If you contrast this to a modern type system like the one in say TypeScript,
Haskell, MyPy, Swift or Rust, you'll always get:

Some way of distinguishing nullable from non-nullable types. Haskell has
Maybe t. TypeScript has T | null. Swift has
T?. Rust has Optional. The type system
can easily tell you where all the null checks need to be and if you missed
one. In practice you almost never see null pointer errors at runtime.

At least one of sum types or union types, which let you follow the

"Make invalid states unrepresentable"

practice. This means you can have objects representing state machines, they
have multiple fields, and each field exists when and only when the system is
in a relevant state.

Some kind of type inference. We don't need to write
let x: number = 5; when the compiler can just work out that
let x = 5; is definitely a number.

Another thing which made static type systems more useful is that IDE features
like method name completion have become more widespread. In the 90s
Intellisense was a killer feature in Visual Studio, whereas in the 2020s
similar features are available in just about every IDE and editor. So
information you put into a static type system yields extra productivity
benefits, entirely aside from its usefulness for checking programs for errors.

In conclusion:

A good dynamic type system is better than a bad static type system.
But now we have much better static type systems than we used to.

© Copyright 2026 Richard
Barrell