This is a serious "citation needed" assertion. What language doesn't verify types? Python does. Lisp does. ("TypeError: cannot concatenate 'str' and 'int' objects" or "wrong-type-argument: stringp 42")

I think the problem that people run into with types is when storing values for future use. Imagine that you have a data structure that looks like:

   data Foo = Foo String

And then later on in your application, you have a function like:

   frobnicate :: IsString a => a -> a

Then, you write a program that looks like:

   program :: String -> String
   program = frobnicate . preprocess . Foo

This is all well and good as long as you only want your program to operate on Strings. But if you want to change the type of your string data (perhaps to a more efficient "ByteString", or something like that), then you are kind of out of luck. You pigeonholed yourself into using String when you defined Foo as "Foo String", and now you have a lot of work to do to feed that ByteString to the function that actually cares about the type, "frobnicate", which can already handle ByteStrings.

The problem here is not type checking, but rather that you built your program in terms of an abstraction that was not generic enough, namely the "Foo" type. If you were just using Python, then your program would have been:

   class Foo:
      def __init__(self, string):
          self.string = string;

   def frobnicate(whatever):
       return whatever

In this case, there would be no trouble using whatever type you wanted as the "string", because you decide what type is OK at "frobnicate" time, instead of at compile time.

The downside is that with your too-specific Haskell program, you know it's too specific before you run it (because the compiler whines at you), but with the Python program, you may only find out when your pager starts making a loud noise at 3 AM, because Python has no idea what you're trying to do.

(Personally, having worked on a huge Python app that does no type checking anywhere, I have to say I hate that technique. I prefer what I do in Perl, which is to type check on object creation, but use type classes instead of concrete types. You can still "late bind", but you also get errors when you're making a mistake rather than deferring a decision. You can do the same thing in Haskell, too, but with even better guarantees that you won't be waking up in the middle of the night to unfuck your code.)

I already said I'm not talking about correctness only modularity. Early/eager verification breaks modularity.

I would say, "bad program design breaks modularity", not early typechecking. If your types are defined so that they are as broad as possible (i.e., "what you really want"), then you will never even notice there is a type system, until you try something impossible.