Do We Create Type Systems In Dynamic Languages?

What do you mean Java and C++ implement static typing poorly? C++ has some trade offs in order to be compatible with C. The Java static typing seems pretty good to me.

Perl 5 pays the bills :)

Actually, I don't have a problem with Perl 5/Catalyst http://www.catalystframework.org/ for a Startup, as long as you have several people quite good at it. If you know what you're doing, the main problem is finding good startupish Perl devs.

I confess that I don't understand your example. I'm not breaking encapsulation, I'm just verifying that a variable is defined (avoids 'variable not defined, can't call can' error), that it is an object with the method of interest (avoids 'no such method' error), etc.

In other words - I am doing a type check that its a valid object of the class I want with a non-null value on a field that should never be null. Happens all the time. This is more easily defined once in the class in a more reasonable object system. But Perl 5 without Moose has no such thing.

Which would seem to parallel the article. I could just assume that $object->foo will work, but that doesn't work out too well as code grows, because if I want my code to work or at least to easily be fixed, I have to check sanity everywhere possible.

I think typesystems span far deeper than most object oriented typesystems go. In fact, I think, it goes even deeper than what haskell does (and I consider Haskells typesystem to be among the most advanced typesystems we have today).

One question for the typesystem is: If I have this object, will it understand message X?

Another question is: If I send this sequence of messages to this object, will the sequence of messages exiting the object be as expected? (Or, much rather: will a certain "interesting" subset of the messages sent by the object (triggered by my messages) be a certain sequence? (In fact, sequence is too restraining. I rather need to know if the messages sent by the object will fulfill a certain predicate)

Another question is: If I conceptually send this message to that object, how do I find the implementation of the handler of this message?

(I am sure that there are more complicated questions around and I just do not know them).

Given these questions, consider what most static type systems do. They answer questions 1). (Dispatch strategies and strong typing answer question 3) ) Guess what unit tests do? They answer question 2). However, in a dynamically typed language like Python, sending a message to an object that is unable to understand this message (read: there is no implementing method), then an unexpected message will be sent by the object (read: an Exception is thrown). This violates the contract. In other words: checking the contract can answer at least question 1) already!

Thus, I think -- or rather hope -- for major improvements at typesystems, because it appears that things are far, far more complicated than just compile-time vs run-time and strong vs weak. Consider Eiffel. Eiffel does contract checking. Now think about attaching contracts to objects at runtime. This could reduce the amount of of_kind?-checks in the article. Consider roles. Consider things like pythons metaclasses. I really think a lot of problems come from a lack of unterstanding object oriented typing more than we already do. (Maybe this kind of pushed me into a good direction for a master thesis. who knows?)

I haven't tried, but I'm thinking about trying assertions for this based on the Smart::Comments module.

But maybe it's not a win and you never want to turn off (most?) assertions in dynamic languages.

(For non-Perl people, Smart::Comments are a neat way to e.g. allow runtime checks that are easy to turn off. Like C's assertions.)