&gt; <i>Few things change more frequently while evolving&#x2F;hacking together software than the data structures and types.</i><p>I tend to agree; it is often correct. (Though sometimes we have solid data structures and types and are able to evolve things without changing them.)<p>Anyway, therefore it follows that if we calcify and ossify data structures and types, we kill the progress, not to mention fun.<p>&gt; <i>Changing a type in one place while forgetting to in N other places is an extremely common defect introduction method that is easily caught with static type systems.</i><p>This is blown out of reasonable proportion by static type advocates.  In a dynamic system, type is <i>de facto</i> a few bits of <i>value</i> in an object.  So the above situation is just another value that is wrong.<p>Static programs also have run-time values that can be wrong. A static program that is supposed to calculate 42 might calculate 43, which has the correct type.<p>To discover the cause, someone will have to sit down and think about the code.<p>Code which has never been exercised by a test case (coverage) should still be regarded as garbage, in spite of passing type checking. It is not known to be <i>correct</i>. Type checked is not the same thing as correct.<p>The graph of &quot;type-value&quot; in typical code is rather trivial. Take any moderately complex algorithm, and ignore what its operations are doing; just consider their input and output types. The resulting graph&#x2F;tree is a lot simpler than what is going on with the values. Type problems are trivial.  That is why it&#x27;s even possible to move them to compile time and have static languages. Think about it: something that runs for hours or days in order to produce a result (and is not even known to terminate) can be entirely type-checked in a millisecond.<p>We do not know a whole lot about code just because it has type checked. It may <i>feel</i> like you do, but that&#x27;s just a feeling. The name of the function might be `sort`, but it could actually fail to sort items, in spite of type checking. Or it could sort them in descending order when the expected order is ascending: some test was reversed and the reverse test type checks because the operator is commutative.<p>You still have to either <i>prove</i> your code if possible and feasible, else test it exhaustively if possible, or else test it imperfectly.