Dynamic types: where is the discussion?

Questions & Help General Questions
13

This happened at work. There was code like this,

function foo() {
    return someThing === someValue
}

function bar() {
    if (foo) {
        // do something
    }
}

This had been in the code base for a long time. They switched to typescript, which caught the error. When they fixed it, several things broke. Other parts of the code had worked around the fact that bar was broken and those failed when bar worked correctly.

It’s hard to argue against using types when stuff like this is extremely common in JS code bases. Every JS code base I’ve converted to typescript had plenty of subtle bugs like this laying around.

The things I’ll run into with languages like lisp or clojure that aren’t as bad as js is the form of data in maps changing. When some feature is added, the contents of a map will no longer look the same. Finding all the places in the code where that map is used and are now broken is tedious compared to having a strongly typed language and the compiler telling you everywhere that’s broken.

The number of bugs studies are flawed because of things like my first example. Dynamic typing caused the code to be broken, but it had been hacked around and still worked. So the number of bugs is still the same, but the code is worse because of the dynamic types.

Whether to use dynamic or static typing is really a personal preference, but you’ll be hard pressed to find arguments against static typing that hold up to large scale projects with a wide range of developers working on them.

Ask yourself this: if dynamic is better, why do type hints and spec exist for clojure?

2 Likes