The real reason we need strongly-typed languages
There aren't many hard-and-fast facts about software, but here's one:
The more code you have, the more bugs you have.
More formally, lines of code is a strong predictor of defects. So, any language that allows you to do the same work with less code must be a Good Thing. This is why Python is better than Java is better than C++ is better than assembly, right?
Well, almost. The standard counter argument is strongly-typed languages catch mistakes at compile time that slip to run time for dynamic languages. I don't buy this argument, because even though it will catch some mistakes, there are so many other errors to be made you still need to unit test the code. And good unit tests will catch the same errors of strongly-typed languages. Okay, so a lot of people don't write good unit tests, but until they do they're beyond our help anyway. As Bruce Eckel said, "if it's not tested, it's broken".
So why am I a proponent of strongly-typed languages for many (but not all) problem sets? Because they give us one thing dynamic languages by definition never will: unambiguous, guaranteed documentation. Building large software systems means interfacing with subsystems written by others, and they must be documented. Strongly-typed languages have an important part of that documentation built in: they precisely define the input and output types of each procedure call. An API in a dynamic language needs the same documentation anyway, so why provide the chance for error? Even for well-documented libraries, the reduced amount of code in the dynamic language is balanced by increased documentation.
In fact, I'd like to see languages with even stronger guarantees. A Nice addition to Java would be to define references that can never be null. Many times I've used an API and asked, "do I need to check for null?" The answer to my question should be part of the API itself.
Of course, specific dynamic languages may have other advantages over their strongly-typed counterparts. Also, some programs may not need the detailed level of documentation offered by strong typing. Even so, type definitions are a key part of the documentation needed for a large system.
The more code you have, the more bugs you have.
More formally, lines of code is a strong predictor of defects. So, any language that allows you to do the same work with less code must be a Good Thing. This is why Python is better than Java is better than C++ is better than assembly, right?
Well, almost. The standard counter argument is strongly-typed languages catch mistakes at compile time that slip to run time for dynamic languages. I don't buy this argument, because even though it will catch some mistakes, there are so many other errors to be made you still need to unit test the code. And good unit tests will catch the same errors of strongly-typed languages. Okay, so a lot of people don't write good unit tests, but until they do they're beyond our help anyway. As Bruce Eckel said, "if it's not tested, it's broken".
So why am I a proponent of strongly-typed languages for many (but not all) problem sets? Because they give us one thing dynamic languages by definition never will: unambiguous, guaranteed documentation. Building large software systems means interfacing with subsystems written by others, and they must be documented. Strongly-typed languages have an important part of that documentation built in: they precisely define the input and output types of each procedure call. An API in a dynamic language needs the same documentation anyway, so why provide the chance for error? Even for well-documented libraries, the reduced amount of code in the dynamic language is balanced by increased documentation.
In fact, I'd like to see languages with even stronger guarantees. A Nice addition to Java would be to define references that can never be null. Many times I've used an API and asked, "do I need to check for null?" The answer to my question should be part of the API itself.
Of course, specific dynamic languages may have other advantages over their strongly-typed counterparts. Also, some programs may not need the detailed level of documentation offered by strong typing. Even so, type definitions are a key part of the documentation needed for a large system.