In my experience, simplicity is the best defense against all kinds of errors. The simpler the code is, the better I understand it. The more I understand it, the easier it is to discover and fix errors. Duck typing allows me to make the code simpler.

I agree that the benefits of strong typing is CF are less that what you'd get in a compiled language, but I think the "just a different runtime error" argument falsely implies that all runtime errors are the same–they're not. The relevant question is: when does the error get caught?

If you specify a CFC type for a CFARGUMENT tag, then you're going to catch the error as soon as you try to pass a CFC as a function parameter that doesn't match the required type–probably during development. If you use duck typing then there may be a path in your code that you miss during testing that isn't caught until the application is put into production. In some environments, fixing post-production bugs isn't a big deal; in others it's a major disaster.

In the end it turns out that if someones session times out WHILE they are checking out AND if they have not previously ordered from you before (which is where your initial testing fails as you didn't blow away your cookies before testing), it runs code to pull up their default data (and this is the only time this particular path is fully exercised – your general model call works fine), but your controller in this one case forgets to pass the appropriate property back from the method call and doesn't fully initialize your cart so they get a "cannot check out" error.

Now imagine hundreds of thousands of lines of code, large teams of programmers and daily builds with new features. Good news: you don't have to waste time with a compiler. Bad news: you have just been appointed head of QA and it is your ass if these bugs aren't fixed by 3pm!!!

A compiler is not a silver bullet. There are all kinds of problems that a compiler won't catch, but it will catch SOME of these problems so it does provide a real benefit for larger projects and teams. The question then is whether it is worth the cost of that benefit and your milage will vary. For my use case – no way!

I agree, no one can write perfect code. I put errors up on the production site all the time …. er, um… I mean… my co-workers put errors up on the live sites all the time….

But, these are usually minor, non-mission critial errors. I feel that things where type-checking is involved are errors that are BIG and should be caught with even the least amount of testing.

And, even if something important does slip through, I think it's a rare case where the "corruption" of data would be so huge that we couldn't fix it and debug. Of course that changes from project to project (I have never built anything for a bank with money issues and 4 jillion transactions a second).

So, not to ramble, I am sure there are "edge" cases where any issue on the live server can result in massive amounts of data corruption, BUT, I feel that in 99.9% of the cases, that's just not going to happen.

This reminds me of something my digital logic professor talked about once in engineering… He said that's the difference between "Computer Scientists" and "Computer Engineers": CS's are concerned with theory – what about that one case or the complexity of a problem when it appraoaches N and such nonsesnse. Then you have the CE's who don't care so much about theory, they care about numbers: sure a problem has exponential complexity, but I know that this system will never go above "X" and therefore, I don't care about the theory, I know it will always be fast.

Here endeth the rambling.

The compiler isn't a silver bullet. It's like a seatbelt in a car. It doesn't help if someone shoots you, but in a fender bender it may just save your life.

Also, Sean, you don't just "go to production". With ongoing maintenance and frequent builds, unless you have 100% coverage in your automated unit tests (I'm assuming everyone is using automated unit tests as part of their build process) the compiler just catches one more class of errors in advance. That isn't a bad thing.

Now, whether a compiler is worth what it costs in terms of additional complexity required just to support explicit typing – that's a whole other matter.

Also to clarify, this is a discussion (for me) between true explicit typing (e.g. Java) and true dynamic typing (e.g. CF). In my opinion the benefits of strong typing in CF are a little more modest because there is no compiler – just a different runtime error.

Doesn't that imply that you're able to write "perfect" unit tests; that is, that your unit tests provide 100% code coverage? If you can't write perfect code in the first place (no one can), what makes you think you can write perfect unit tests? That's why I'd rather rely on the compiler to automatically catch as many errors as it can before I run my unit tests.

It is not that you can't have interfaces in a dynamically typed language, but you rely on documentation or programming conventions rather than having language features to enforce the contract.