The Unreasonable Effectiveness of Dynamic Typing for Practical Programs
&gt; You can declare structs as static in C and provide public helper functions that internally create data types, apply other static functions to them, and the produce results from them.<p>You can do that, with training and careful effort. But it was a design flaw that you have to do it manually, and that it isn&#x27;t mandatory and trivial for even beginners to do. At the time C was &quot;designed,&quot; this wasn&#x27;t necessarily known to be important. We have no excuse today. But languages which do this wrong by default are still popular.<p>&gt; In Haskell, it&#x27;s very common to avoid exporting value constructors for data types, and to instead provide helper functions that allow for the implementations to remain hidden from anyone using the module.<p>In general, if calls require knowledge of type information at the call site, and the type needs to change for any reason (which becomes more likely as type annotation reaches further into program semantics) then all the call sites will need to be updated, or there will be an error.
In any published library, this means backward compatibility is completely broken and everyone else&#x27;s code needs to change.<p>This is a misdesign in C and in a number of &quot;statically typed&quot; languages which crib from it.<p>&gt; you&#x27;ll see a huge block of assert statements right at the top of a function definition,<p>I almost never see this. The only time I see it is when a dogmatic true believer in the ideology of static typing writes Python. People can do stupid things in any language.<p>&gt; this isn&#x27;t a problem and even is a huge benefit because it doesn&#x27;t require the huge, human-error-laden block of asserts to achieve it.<p>Humans are still required to provide type information, which means they can still make errors. Even better, correcting these errors often affects the interface at call sites, which means the fix has to break backward compatibility.<p>&gt; so you burnt maybe 30 hours of computational effort just to be told that upon hitting a certain point in the code, here&#x27;s a TypeError.<p>You were not reasoning correctly about your code. Proper testing should have been your safety net, but you weren&#x27;t testing properly. If you are even vaguely trained and you are even vaguely trying, writing code which emits TypeError in production takes some doing.<p>The number of shops which never have problems in production is vanishingly small in ANY language.<p>It sounds to me like you got started in Python, and are identifying beginner&#x27;s mistakes with the language itself.