Statically checked types are little more than very broad pre/post conditions on your code. Both CL and Clojure offer such conditionals and both can do it at compile-time if necessary.
Both this assertion and the one that types are "a set of compiler-enforced contracts between pieces of code" are very wrong ways of thinking about types, and the reason why most statically typed languages are so poorly designed and get such a bad reputation.
Static typing in a programming language is a mechanism for making certain types of non-terminating computations impossible to express in that programming language. The understanding "non-terminating" here includes errors as well (the idea of bottom ⊥ that you'll find in some earlier texts on programming languages semantics, such as Allen's Anatomy of Lisp). Non-terminating computations are equivalent to paradoxes in formal logic (see Curry-Howard correspondence), and the first type system was developed to deal with Curry's paradox (http://en.wikipedia.org/wiki/Curry%27s_paradox) in the first programming language (lambda calculus). Some type systems prevent more types of non-terminating computations, others less. But saying that run-time type assertions are equivalent to a typed programming language, or that types are like contracts or other things just leads to confusion.
No. They're a set of compiler-enforced contracts between pieces of code. Maybe more importantly, they enable a kind of constant, aggressive refactoring that's just way too dangerous in dynamic code.
Maybe at large scale, I have spent my career working with 200k - 500k loc systems in java, c#, and ruby, and in my experience, the thing that makes refactoring possible or a nightmare is well written test suites, not compilers. Compilers definitely catch a certain class of problem, but tests catch many more.
It holds even more so at small scale because I can pretty confidently move a method up an inheritance chain or rename a class and count on the compiler catching everything. In a bigger codebase I have to be more careful about breaking somebody's excessively dynamic code that might be pointing to those things in a roundabout way.
As an experiment last year I started teaching myself machine learning by implementing the common algorithms in Clojure and Scala simultaneously. I expected Clojure to win out and worked a lot harder in the beginning but after a while I was forced to concede that my Scala code was cleaner, faster, and less buggy, partly because I felt comfortable changing things because I knew the compiler would help me.
Pre/post conditions at compile-time in Clojure? Nope. How could you know the value returned by a function at compile time? Or the value of the inputs?
You could only know the types of the input if the compiler was smart enough and define constraints on the types but as far as I know it's not possible in Clojure.
I don't get it.