I like strong typing and compilation errors

People tend to pick one side or the other of this issue and then argue for it. It's rare for anyone to change their mind, and even when they do, it's usually just a boolean toggle to the opposite position. Most people believe (even if they don't say it) that the opposite camp is, basically, stupider.<p>The entire subject is remarkably evidence-free. That's surprising; you'd think (on the surface, at least) that it could be studied objectively. Of course, we all have our individual experiences as programmers, but those aren't worth much as evidence, because we interpret our experiences to suit our pre-existing belief. Indeed, we don't even notice experiences that contradict it. (I've seen static typing proponents go on about how compilers catch bugs and then spend hours tracking down an InvalidCastException.)<p>In light of the above, I'm more interested in hearing what people have to say in favor of the position they <i>disagree</i> with. The debate is too tiresome otherwise, entirely predictable.<p>Although I currently favor dynamic languages, I recently started the thought experiment of asking myself, when fixing a bug, whether a good type system would have caught it. Certainly there are times that the answer is yes (though not always). The difficulty, of course, is whether the aggregate benefit would outweigh the cost.

I'm glad I actually read the article, because while I too like strong typing and compilation errors, but I don't want to be associated with programmers who do things like this:<p>&#62;<i>Today I had to modify a piece of JavaScript code. The code used return a single string, and I needed to modify it to return an array of objects. Using C#, it would have been easy, change the return type, hit the compile button, fix the errors, rinse &#38; repeat until it compiles.</i><p>The compiler does not save you from having to think, and like InclinedPlane says, compilation doesn't 'prove' correctness, only shows you that the compiler could at least sludge its way through your code.<p>The code should pass some mental unit tests of expected inputs and outputs before you even make the change.

I don't see the need for the invasive change. Given the problem that he had I would have written a new function that returned the more complex data structure, converted the old function into a wrapper around the new one, then called the new function in my new code.<p>Much simpler. Much safer. Much less chance of breaking existing code. (Decent unit tests could help verify this.) And you avoid duplication of logic.<p>If I wished to convert existing code to use the new function, I could do that at my leisure. Furthermore if someone happens to be developing code in another branch or at another site which expects the old function to be there, I don't break them.

I find it rather risky to change something and expect compilers to catch all the errors.<p>Anyway, the non-typed languages I use tell me the line of code where the error occurred. Isn't that equivalent in this case?

If you rest on the premise that merely because your program <i>compiles</i> it is also <i>correct</i> then you will face a career full of frustration and mediocrity.

Strong static typing is great. You can cut your runtime bug count by 70-80% easily if you know what you're doing, which provides an enormous increase in productivity. Also, type discipline seems to lead naturally to better architecture. You have to build your data structures and functions from the ground up, which tends to kill a lot of the sloppy thinking and nonexistent architecture that you sometimes see in the dynamically-typed world (although this can't be blamed on the languages, because a lot of users of such languages write great code).<p>Dynamic typing wins on prototypes and small projects, but for a project of more than 2000 lines, I'd be hard-pressed to see a case where dynamic typing wins.<p>Of course, I'll add the caveat that <i>good</i> dynamic typing is essential. Most people think dynamic pwns static because they're most familiar with Java and Python, but Java has shitty static typing (you have to declare types, and moreover end up needing to subvert the type system to do anything interesting) whereas ML and Haskell have awesome type systems.