Most of the times, they don't. Static typing helps with catching certain types of errors long before the compiled code arrives in production but it's just one tiny factor that contributes to overall software quality. Lack of expressiveness or lack of developer happiness can be much more detrimental to software quality than lack of static typing.
> Lack of expressiveness or lack of developer happiness can be much more detrimental to software quality than lack of static typing.
Except 5 years later, when the happy developers have gone on to express themselves elsewhere, and left behind them a mess. Now, you can make a mess in any language, but a mess in a dynamic language is considerably harder to refactor.
I also dispute the claim that a strong type system is a "tiny factor" in code quality. Being able to express invariants with types makes code much robust, and self-documenting.
However, I've also read studies that show the opposite, but the lack of rigurosity and the possible confounds that show up for both sides seems to render this as an open question.
> However, I've also read studies that show the opposite, but the lack of rigurosity and the possible confounds that show up for both sides seems to render this as an open question.
This doesn't look particularly convincing, indeed (though studies about programming languages rarely are).
A language having static or dynamic typing is only a part of the puzzle. Having tools that let you understand a codebase better through static typing is more important. With a statically typed language you have the compiler as a baseline, but it enables IDEs to do far more powerful things.
Hopefully they had tests. And unless they've mathematically proved the code always does what it expects (I've only seen that in avionics systems).
Also depends on application of course. Large concurrent and distributed applications benefit a bit less from static typing in traditional languages. Or rather, they are so hard, that type error are not as much of a significance. How concurrency, communication and failure is handled is more critical.
But say a game or a large desktop application with millions of lines of code, could get a larger benefit from static type checking, no doubt.
Now for a bit of personal experience. I have programmed in Java, C#, Python, Erlang, C++. I have found that when working with large or unknown code bases C# for example is great. Just having the IDE and generics support in C# during compile time is awesome. But if I program something from scratch, I can make a lot faster progress in Python. I often put more work into both unit tests and integration tests because I just have more time available.
Also failures during run-time, even in Python, in my systems a very rarely type errors (those are caught pretty early one). But they are often logic or concurrency errors.
> Static typing helps with catching certain types of errors long before the compiled code arrives in production but it's just one tiny factor that contributes to overall software quality.
If you use them right, expressing the constraints of your system in the type system, you can improve huge areas of quality. It doesn't give you much for free, but it does give you a tool that lets you check your own correctness properties more efficiently and maintainably than any alternative.
> Lack of expressiveness or lack of developer happiness can be much more detrimental to software quality than lack of static typing.
Agreed - but good static typing makes a language more expressive, not less.
Exactly. Not to mention that in any large scale system your functional and integration tests are the most useful for producing high quality software than simply having static types.
No-one is arguing that you should just have static types and nothing else. The argument is that static types and testing are better than just testing. After all, static types are a kind of test that the compiler verifies for you, leaving you free to focus on the rest of the tests. I'd say in any large scale system, dynamic typing is a risk (though there are ways of mitigating this risk, of course).
I second this. I'm currently creating a new dynamic website, which will see around 10k users a day.
We could have done it in a week with rails scaffolding capabilities and the vast gem environment, but we are doing everything manually in Scala, because type safety and performance. It's so frustrating that I'm looking forward to quit very soon.
The fact that Rails has scaffolding and whatever Scala framework your team uses doesn't has little to do with type safety (there are plenty of web frameworks in dynamic languages without scaffolding as well).
There are several languages which require a comparable amount of typing to a dynamic program, while adding considerable type safety.
The Play! Framework http://www.playframework.com has been pretty sweet for us so far and we use Java with it and that plays second fiddle to Scala users who really enjoy the full benefit of the framework.
I'd enjoy getting paid to go slow and learn Scala.
I really despise the "let's finish this in one week" that is typically going on for me. I'd rather learn best practices, even if they're in a language, and have some experience building long-lasting services.
Feels like the difference in working at a mobile home shop vs a custom log home company.
