If you look at objects from the behavioural point of view (and here we could say that each object is *written in its own language, for which the object is that language’s Interpreter*) the answer is “we don’t know how to build that yet, or even what that is”. quora 
**Edit**: To expand on some of the problems of modelling behaviour in type systems: think about what makes the type checker consider two types “equivalent”.
Most type systems use a concept of “name”. If two types have the same name, then they must be equivalent. Names don’t work for any situation where we care about Behaviour, and they really don’t work across languages, processes, or computers. They’re also very much not modular.
The other simplification that type systems use is “Structure”. If two types have roughly the same structure (i.e.: `A = B` if A and B have the field “counter” of type “Int”). This works if you see objects as plain records of data, and it’s even modular, and sort-of works across machines and languages (ground types are a bit of a problem), but it doesn’t work **if you see objects as behaviour**. A problem with these two approaches is that, if you have something like:
interface Counter { next(): Int; }
Then all of these are “correct” according to this type, but they’re most likely not what we want to consider a counter *at all*:
counter1 = { next() { return 1 } }; counter2 = { next() { return randomInt(1, 100) } } counter3 = { value: 1, next() { return this.value / 2 } }
And they’re only correct because the type “Counter” does not capture anything about the *behaviour* of the object that we want. It only tells us what functions it must implement, and what data we can expect to input to this function and get out of it. And that’s *completely useless* for a view of objects as behaviour.
Of course, as soon as you start asking “does this object *do* the things I’m interested into?” you start getting into some places in mathematics that we don’t have answers for either (⇒ Extensionality). –– Quildreen Motta