Hi, Kevin.

>From what I've seen, when you get into development projects with more than 1-2 developers, odds go up that strong-typing will be preferred. (I use strong typing even when I'm flying solo).

Well, for me type safety goes certainly beyond protecting from our team buddies. We all love adding levels of indirection, and so in many cases is really difficult to ensure what type you'll receive. But it also adds a lot to readability, making semantics more obvious. What of the followings signatures are easier to figure out?

// .NET 1.1 version
public ArrayList Find(ArrayList queryTerms);

// .NET 2.0 generic version
public List<Products> Find(Dictionary<string, int> queryTerms);

>At the very very beginning, I really didn't like generics that much. But I'm glad I gave it a shot. Knowing generics gives someone a leg up on learning aspects of the .NET 3.0 Framework. Carl Franklin has a great description of generics - when you have multiple blocks of code that only differ by type, they're a good candidate for generics. Almost every time I see a good and effective use of generics, it really comes back to that rule.

My personal take is that it all comes down to types been specifications and the type checker the final test. Whenever you are leaving lots of things to unsafe casting, you are getting more distant of a true verification. In certain ways, the type checker is your handy and intelligent tester.

And having spent many years doing code reviews, my experience is that typing and bad casting issues are one of the major problems in software developments, after complete lack of automated testing.

Anyway, I really like what the people at the CLR team is doing with IronPython as a test bed. They have a dynamic inference mechanism that still give you a lot of safety while saving you a lot of declarations. I guess something very good will arise from there.

Regards,