Wow, if that is so, then I am completely sold on static typing. I do not get how dynamic typing gets into the picture.

Having a type system that can catch some errors at compile time but not all is better than having a type system that doesn't catch any.

Having a static type system doesn't mean that you can't use dynamic typing as much as you want (e.g. in Scala you can make all variables of type `Any` and use type refinements whenever you want to call a method).

You seem to be under the impression that I'm a proponent of using dynamic typing to the exclusion of static typing. That's not the case (I'm an ObjC fan). I just hadn't seen a situation before where the argument for one vs the other in a particular situation hinged on something so fundamental rather than on a design artifact.

EDIT: Removed comment about scala because I was confusing it with clojure. My bad.

That's the thing. There is no argument for one vs the other.

There is a statement of the following fact: "It is hard to express heterogeneous array type in most statically typed programming languages and verify operations at compile time." Well, duh. AFAIK this would require dependent types* (not something that you get for granted in mainstream languages).

But can we check types in runtime? Yes. Does it mean that it can only be done in a dynamic language? No. It can be easily done in any language that has integers and arrays. Even x86 assembly is enough.

* Scala's type system should be enough, if we use shapeless.HList's for column and row types and then a ton of implicits to resolve the resulting type and check that everything is sound.