Re: in praise of type checking
Robert Klemme wrote:
Roedy Green wrote:
Robert Klemme wrote, quoted or indirectly quoted someone who said :
I'm surprised you mention the compiler and syntax checker. In my
Eclipse changing the return type of a method is a refactoring which wil=
l
easily change all affected methods in code which is part of the project=
..
Lew's caveats apply of course.
I changed the return type. That meant the caller now had to deal with
3 possible values instead of two. There is a no way a refactor can
handle that. It is called Change Signature in IntelliJ. It is great
for swapping parms, or changing a type, or adding a new parm. When you
add a new parm, you still have to visit all the invocations to touch
up if the default value does not apply.
Oh, yes! Of course you are right. Shouldn't have posted that late.
Sorry for the noise.
I find interesting that the debate static vs. dynamic typing comes up
every once in a while. The static typers have the intuition on their
side that with more expressiveness in languages and stricter enforcement=
of contracts less errors will happen. The dynamic typers usually refer=
errors being caught with tests - which you have to write anyway - even
for programs in statically typed languages. And then the higher
productivity of dynamic languages may actually pay off.
Tests find bugs after they happen. The compiler finds bugs before they hap=
pen.
Tests are optional. A programmer can choose (unwisely) not to write tests;=
they can't choose to avoid the compiler. Tests can be incomplete; everyth=
ing gets compiled. You have to write tests; you already have a compiler.
In practice, the tests "which you have to write anyway" are often not writt=
en. You've worked on projects where the tests are insufficient, yes?
As for "the higher productivity of dynamic languages", the facts have not b=
een presented into evidence for that. The question involves fully defining=
"productivity", which must include maintenance costs else you have not int=
ernalized the costs that strongly-typed languages aim to avoid.
Case in point - in one Language War of PHP vs. Java for Web applications, a=
PHP fanboy mentioned that they allowed exception crashes, complete with st=
ack traces, to appear in the browser when the application fubared. Well, n=
o wonder they were more "productive". If I could bring myself to inflict c=
rashes on the user, I'd be far more "productive", too, even in Java.
I am *not* arguing against dynamically-typed languages, nor in favor of Jav=
a. I am pointing out that any such comparison must account for the consequ=
ences and costs of each approach. Next time you have to refactor a million=
-plus-line software system involving dozens of programmers, think about how=
type safety and other compile-time checks can or should help, or not, vs. =
tests and other run-time techniques. Look at the state of tests on that pr=
oject, and how much they cover or fail to cover.
Unfortunately your conclusion flies in the face of published research. (I =
don't have references handy, sorry.) By all accounts, bugs found (and thus=
prevented!) at compile time are far, far cheaper than bugs found (and thus=
not prevented!) in testing, which in turn are far, far cheaper than bugs f=
ound in production (surely no one can argue that those were prevented!). T=
his is only about bugs; the cost of maintenance, enhancement and refactorin=
g apply as well. You have to internalize all the costs to fairly compare t=
he approaches.
--
Lew