The pros and cons of static typing
- Documentation: For most code, I find it very helpful if the types of parameters are documented. Then I know what to expect as a caller and as a callee.
- I’d also consider auto-completion in editors as “better documentation”. It means you have to consult docs much less when working with an API (good doc comments help, too). For example, when I started doing more DOM programming in 2006, I did it via GWT (which is based on Java and was an attractive solution back then, for several reasons). Exploring and learning the DOM API was fun, due to auto-completion in Eclipse.
- It helps with refactoring (adding cases to enums, etc.).
- It takes time to learn.
- It is an additional layer of complexity. You are basically writing the code again, on a different level.
- It constrains your freedom of expression. Things can get complicated if you get into generics, co- and contra-variance (e.g., an Array of strings is not a subtype of an Array of objects), etc.
- It does not prevent defects. At least that’s what current research says. In my experience, you do catch a certain class of errors (e.g. missing null checks). But I may have caught them even earlier, if I had written unit tests instead of adding static types. In order to detect serious defects, you need tests.
- If you want to experience the best of what static typing has to offer, use ReasonML (or OCaml, which it is based on). For example, almost every language feature is designed so that you need the least amount of type annotations (by supporting type inference).
- ReasonML has impressively short build times. It’s considerably faster than TypeScript, which is a definite usability advantage.
- You have the option to go native. For example, Jared Forsyth has written the game Gravitron in ReasonML that runs natively on Android, iOS, web and macOS.
For more information on ReasonML, consult my book “Exploring ReasonML and functional programming” (free to read online).
- TypeScript’s type system is more lightweight than I expected it to be. It feels more like FP than like Java. For example, it works structurally and not nominally: If you create an interface, that interface “matches” all objects whose shape is described by that interface. You can introduce interfaces at any time, without having to touch existing code.
- Editor support (via Visual Studio Code, WebStorm, etc.) is outstanding.
- Many npm packages either come with static type definitions or have external ones that are dead-simple to install. Consult DefinitelyTyped for more information.
- The whole ecosystem is a constant source of innovation and experimentation (Babel, etc.).
- You have the broadest selection of compatible libraries, via npm.
- You can move as quickly as possible and keep everything as dynamic as you want.
- Have the option to explore and create code without a build step.
Static typing or not is an emotional topic. My advice is:
- Use whatever makes you happy and productive.
- Do acknowledge both strengths and weaknesses of what you are using.
Personally, I’ve started to use some kind of static typing once a project grows beyond a certain size (or if I expect it to eventually grow that big).
Lastly, note that there are many other good options out there: the static type checker Flow, the functional programming language Elm, etc.