David Leppik
2 min readNov 9, 2018

--

I’ve been using Scala and TypeScript for a while now, as replacements for Java and JavaScript. I wouldn’t use a language without static types. To me, they provide two essential roles.

First, static types let the compiler provide a proof of correctness about certain properties of my code. Especially with Scala/Haskell style FP, I can write a long series of transformations and if the type is correct at the end, there’s not much room for bugs. These shouldn’t replace unit tests, but for what they can do, a type check is stronger proof than a potentially buggy or incomplete unit test.

Second, and more important, static types open up the code to static analysis by an IDE. This provides automatic API documentation, fast refactoring, and automatic bug detection (e.g. proof that a block of code will never be executed.) Indeed, it’s IDE support that the designers of TypeScript touted as its killer feature, including a demo of renaming a property and having the change cascade though a large code base.

Especially with newer, more declarative APIs, bugs become less about logic and more about plugging stuff in correctly – which is exactly where static typing helps.

Languages like Haskell and Scala are built around strong type systems. TypeScript is more limited because it’s a superset of JavaScript so it defaults to being unhelpful.

I can’t tell you how many times in JavaScript I’ve been bitten by a date-as-a-string when I expected a date-as-a-Date-object. Sure, you could write a unit test to catch that (usually), but for me, the type is the test.

--

--

Responses (2)