As a followup to that, I'm posting a nice quote from Dave Thomas (of Pragmatic Programmer fame) in response to James Britt (also a nice guy) regarding strong typing. Although Dave is talking about Ruby here, I think it applies to Perl and Python as well.
On May 17, 2004, at 22:52, James Britt wrote:
> One (possible, and not mine) argument against duck typing is that you
> are essentially required to write assorted unit tests beyond checking
> for operationally correct behavior; the compilation step for a
> staticly typed language offers these (albeit compulsory) "unit tests"
> for free.
No one requires you to do this. Instead, you do this if you feel uncomfortable with your code. After a while, you stop feeling uncomfortable, and realize that all this type discussion is simply a red herring, and get back to writing proper code and the tests to test it. A few months after that, you're surprised when you realize that you haven't had a single type-related error.
This is simple a question of experience. When you first start out, you feel exposed because Ruby doesn't let you add type annotations to variables (I know I did). Knowing that it worked OK in Smalltalk, I made the conscious decision not to fight this, but instead to see how it worked just doing it the Ruby way. It was hard at first, and I kept fighting some inner demon who wanted me to add "kind_of?" calls everywhere. But after a while, I realized that my code was no less accurate than it was in Java, and that I didn't really need the type information. Once I overcame that fear, I suddenly realized that I could also get a lot of benefit from the flexibility: the realization that type != class, but rather that type equals capabilities was a revelation, and it has fundamentally changed the way I code.
Type is not Class (Score:1)
If only there were some way the compiler could check that for you.
static typing (Score:1)
points:
I find that I *do* make type errors when I use libraries
written by other people.
Also, static type information helps the compiler produce
programs that require less RAM and run faster.
Also also, the existence of undef in Perl (or null in Java)
complicates things greatly. The ocaml option type is much
less error prone, in my opinion.
Also also also, if you're interested in nice OO typing,
ocaml's object system subtypes according to method
signature