Yeah... no. It's backed up by data. Mathematics, even.
Types enable safe automatic refactorings. Without types, refactorings can break your code if not supervised by humans.
Perhaps the problem is that static typing is confused with how some languages implement it. It can, and has, been implemented such that it dramatically improves compilation, correctness, static analysis and documentation without making code horrendously verbose.
Mind blowing is the amount of output and obscurity of the error message you get from the type checker. It's harder to understand the error message than to debug the program if compiled "unsafely".
With time the way I approach code is also much more and abstract. You look at diagonal invariants more than code itself.
Powerfully-typed languages also work much better for structured editing.
http://docs.idris-lang.org/en/latest/tutorial/interactive.ht...
Most of the time what people hate with static languages is type annotations.
What will blow their minds is a language that is both a) type safe and b) easy to type (i.e. what gives dynamic languages their flavor).
Luckily we're getting to a point (Scala) where this is mainstream.
Scala can be quite concise but we do have to be explicit with type signatures, and that only increases as we go up the abstraction ladder.
A strict Haskell with a decent module system, or a modern SML that borrows some nice-to-haves from Haskell and Scala would be my ideal language.
Dynamic typing doesn't mean there are no types, by the way.
The opposite is true, with static typing your code is supervised by the compiler, with dynamic typing you need to rely on humans or runtime errors.
Have you got some examples for your issue? I'd say that with static typing you can apply refactoring and with with dynamic you can try and hope you applied refactoring (because everything about your variables could change at runtime).
You can refactor anything but refactoring can only be performed automatically and safely with types around. Without types, a human is required to verify that the tool didn't break the code with its refactoring, because it's just guessing at this point.
With types, there is no guessing.
I have seen plenty of bugs introduced by refactoring in static languages. Static typing cannot verify correct behavior.
I sit on the fence in the dynamic vs. static typing debate, but I think the uncertainty of a dynamic language is often an advantage because you are much more likely to pay attention to the behavior of the system and not just the types. And at the end of the day, it's the behavior we're interested in, not the types!
I've seen multiple times when bugs have been pushed to prod due to a false sense of security because "it compiled".
Or in a different way: what's the example of a transformation which is valid relative to all types, order of allocation, synchronisation and any other elements of the included language and results in a different behaviour. (excluding runtime introspection that is) And can anything in the example identify why it cannot be done automatically? (also valid outcome)
How is it false?
> the uncertainty of a dynamic language is often an advantage
How can uncertainty ever be an advantage over certainty?
> I've seen multiple times when bugs have been pushed to prod due to a false sense of security because "it compiled".
That same program would have compiled just as well with a dynamically typed language. Except with potentially more bugs that the compiler didn't catch.