That is indeed an argument against static typing and in favour of dynamic typing, although the demerits can be mitigated through some extent through a combinati

That is indeed an argument against static typing and in favour of dynamic typing, although the demerits can be mitigated through some extent through a combination of organisation and tooling. For example, if our customer IDs used to simply be increasing integers but then we decide to change to a UUID variant it would be a pain if I had something like: (declaim (ftype (function (integer) (option customer)) get-customer-by-id)) And then had a bunch of functions calling out to that which all require integers and I had to change all the declarations from integer to UUID. However, I could save myself some future headaches by doing something like: (deftype customer-id nil 'integer) And using the customer-id type everywhere. Of course, this is a very trivial example and a real problem would be harder to manage. That said, with optional type checking like SBCL has it is entirely possible to fly by the seat of your pants until things start to take shape. Not that it matters too much if you go with the tried and true method of tossing out the first two prototypes, but that's another discussion.