What Dynamic Typing Is For

Summary

What Dynamic Typing Is For October 12, 2025 Unplanned Obsolescence is a blog is about writing maintainable, long-lasting software. It also frequently touts—or is, at the very least, not inherently hostile to—writing software in dynamically-typed programming languages. These two positions are somewhat at odds. Dynamically-typed languages encode less information. That’s a problem for the person reading the code and trying to figure out what it does. This is a simplified version of an authentication middleware that I include in most of my web services: it checks an HTTP request to see if it corresponds to a logged-in user’s session. function authenticate(req) { const cookieToken = req.cookies['token'] const user = req.db.get_user_by_token(cookieToken) if (user) { return user } else { throw new AuthorizationError() } } Pretty straightforward stuff. The function gets a token cookie from the HTTP request, checks the database to see if that token corresponds to a user, and then returns the user if it does. Line 2 fetches the cookie from the request, line 3 gets the user from the database, and the rest either returns the user or throw an error. There are, however, some problems with this. What happens if there’s no token cookie included in the HTTP request? Will it return undefined or an empty string? Will req.cookies even exist if there’s no cookies at all? There’s no way to know without looking at the implementation (or, less reliably, the documentation). That doesn’t mean there isn’t an answer! A request with no "token" cookie will return undefined. That results in a get_user_by_token(undefined) call, which returns undefined (the function checks for that). undefined is a falsy value in JavaScript, so the conditional evaluates to false and throws an AuthorizationError. The code works and it’s very readable, but you have to do a fair amount of digging to ensure that it works reliably. That’s a cost that gets paid in the future, anytime the “missing token” code path needs t...