In a dynamic language it's entirely likely you still have those types, but they're just not defined anywhere. You the developer have to validate them in your head.
Only it very much matters...
And to track it you have an ad-hoc, incomplete, custom, buggy, implementation of type checking in your head -- as opposed to in the program, and statically checked.
>Maybe it's a new kind of type that you could not have imagined when you first wrote the code, but if it supports the necessary method, it's going to work and you don't need to change or recompile your code to account for it.
You obviously need to change your code to have objects of that "new kind of type" (even if they are dynamic and untyped). Where would the new objects come from without changing the code in some place, the ether?
Supporting the necessary method is a very poor check for "it's going to work".
A "bomb" and a "lock" object might both have an "activate" method. You wouldn't want to call the former when you meant the latter.
You're still doing the same checks, only know you do only half of them, in your head, and whatever goes...
Dynamically typed languages can be much quicker and cheaper to write, making for more rapid business product cycles. The lack of type safety can largely be made up by adding to the already necessary unit tests.
Isn't that how the YouTube startup out-manoeuvred Google's much larger dev team working with static types?
Code isn't just written, though. It's read, modified, and maintained. Sure, you can write it faster. But are you building that program for this week, or for the next two decades?
(Yes, I know, you can be in a situation where writing it faster now is life-or-death for the company. Most of us won't spend most of our careers in that situation, though.)
let frob something = something#run ...
The types are still there, though. They're just types like, "some object with method "run" with ...".