>Does this object have a run() method? Does it have a color property? It doesn't matter what type it is..

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...

Asking the question 'what are the features of this thing' is a potentially very complicated question in a dynamic language. Each and every line of code could have added or removed a feature. Dynamic language make for very messy and unreliable computing.

But the choice between static and dynamic typing (or duck typing add described here) is not cost neutral.

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?

> Dynamically typed languages can be much quicker and cheaper to write...

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.)

What you're describing is structural typing, and it doesn't have to be dynamic. Look at OCaml and its object model to see an example of a statically typed system with automatic type inference, that nevertheless checks all these things at compile-time. Which is to say, you can write:

   let frob something = something#run ...

and it will enforce the fact that whatever is passed to frob, it must have a method named "run", and it must have the requisite number of arguments and their types.

The types are still there, though. They're just types like, "some object with method "run" with ...".