Hi Anonymous Monk.

When a language doesn't have something, 99% of the people using that language see absolutely no reason for it. Consider that the set of features that a language has changes with time, and perhaps this will strike you as amusing as it strikes me.

I agree with you - type safety (strong types, prototypes, what have you) have a time and place. A lot of people think Perl doesn't have a time and place, so the gut reaction of Perlers is to assume that the language that these people use is the one that actually doesn't have a time and place. Given two school children, it is a logical imparative that one of them must stink.

It just so happens that I also saw the need for the TypeSafety, and wrote typesafety.pm. No, I'm not kidding. typesafety.pm uses the B backend to traverse the bytecode of your modules. It examines type declarations, and it makes sure that arguments are correct, method calls get the correct return values, consistent with those declarations. I forgot to check a few things (return values on the returning end as well as the receiving end), but if there is any interest (it would be the first time there is any interest in any of my modules), I'll add it.

Some excellent links were posted, and I'm adding them to TypeSafety on PerlDesignPatterns with glee, but to summerize why I think type safety is sometimes not stinky:

When you can't remember what is returning or accepting what and you'd like the language to remind you. When you're refactoring and moving things around, and you'd like to be told what you've broken. When you're checking for strange values anyway and it is cluttering your program. You're dealing with a complex design and making it more concrete will help you see the shortfalls of it - specifically, you're being too general in some places (expecting Pets where you only want Dog objects) or not general enough (a routine should be able to deal with all Pets, not just Dogs). Formalizing your types helps you realize what is a subset of what, and what subsets what routines should be prepared to deal with. It also encourages you to break out things into types and subtypes, which helps maintain order and refactorability in a large program, especially one with multiple authors, especially when those multiple authors are all working on the code at the same time.

Penny for my thoughts?
-scott