But he did get a runtime failure. Imagine this wasn't about adding a function, but changing an existing function that is being called from 23 different locations in a 100kloc codebase, and that it contains some tricky condition logic so that a bug might only be triggered in 5% of the calls. Without exhaustive unit tests, a type error potentially would not show up until all those call sites had been executed with the specific arguments required to trigger the bug. His point was that in a statically typed language, this would all be detected at compile time.

This error would be detected at compile time without it (as another commenter shows), and if you are not using the more dynamic features of lisp you really should declare the types.

Okay, sure, but that's just the classic argument for static type systems, i.e., soundness.

I thought he was trying to allure to something more.

The error was just bad, it could have been more explicit, and by now SBCL even issues a compile-time error for this problem. But you have a very valid point: the error was shown on the first testing of the function. And it is a very underappreciated feature of Common Lisp, that you can test almost every function by itself, you don't have to build and run an executable, you can, as the blog author did, test the single function and very quickly get to the problem.

That's great for functions you just wrote. It's not as great for functions you change in a large code base.

Use of compile-time type checking to make changing interfaces easier is a great trick. A great trick may mislead many to see it as the only one in the book. Then you get dumbfounded looks and a troublesome question arises: how can these large systems written in not-so-static languages (indeed, no thought about "systems") possibly grow and evolve? And yet, they do.

Maybe it's time to reconcile with reality: there is more than one way to operate; there is value in more than one paradigm.

Everything is of course possible, but at what cost?

In my experience, with large projects, you get to pick 2:

Dynamic typing Development velocity Reliability

I've seen multiple large projects grind to a near halt in their development speed, and I've seen some retain development speed, but unreliably crash after various changes.

UT coverage is expensive. System tests don't catch everything. Either you fear changes, and the system rots, or you work very slowly with coverage for everything.

Here's an observation from Benjamin Pierce, static typing guru:

> Complex definitions tend to be wrong when first written down. In fact, not only wrong but nonsensical. Most programming errors are not subtle!

Static type systems will tend to find those bugs. They're not subtle!

Running the code—just once—will also tend to find those bugs. They're not subtle!

Syntax can also help here. Complex or verbose syntax can make bugs that aren't actually subtle much harder to spot. A readable syntax, API, or even an EDSL can make errors more obvious by making incorrect code _look_ incorrect.

And of course naming things is a huge part of this, not just the raw syntax.