That's only if you don't design your language to be easily inferred. While I don't know the case for SBCL, a language like Elm has very heavy type inference that you can rely on better than most type systems.
> While I don't know the case for SBCL, a language like Elm has very heavy type inference that you can rely on better than most type systems.
Bullshit. Either it's a sound type system (perhaps with some escape hatches) - in which case why would you ever not expose it as a real static type system - or it's not and you can't rely on it.
(There is no contradiction between having good inference and having a real static type system; e.g. if you're using Hindley-Milner then you have "perfect" type inference where you could remove all the type annotations from your program and it will still be correctly typed. But it's still very useful to have a syntax for annotating expressions with their types!)
Common Lisp is strongly typed, it's just that types follow values rather than bindings. This presents some code generation challenges, but it will warn on correctness just fine.
And of course if you really want an ML style BDSM type system in Common Lisp there's Coalton[1].
> Common Lisp is strongly typed, it's just that types follow values rather than bindings.
Then they're not types. Types go on terms, i.e. expressions, not on values.
> This presents some code generation challenges, but it will warn on correctness just fine.
Warn on correctness it may, but it's simply impossible for a setup like that to reliably error on incorrectness at compile time; a Turing-complete language like Common Lisp cannot determine any nontrivial property of expressions (in a way that works in all cases) without evaluating them. If your types go with your values then you can't check your types without evaluating your values, at which point compile time is long gone.
