My post Dynamic Typing More Superior ( a more appropriate title would be Dynamic typing reduces code complexity?) elicited quite a few responses, mostly from readers who don't share my view. Some of the comments are quite insightful and interesting, and I would like to respond to them here.
Jeremy Weiskotten pointed out:
However, the issue just doesn't come up that often in the real world. You don't find yourself wondering, "Is this argument a String or something else?" Even when improving existing code that you've never seen before, it's usually not much of a problem as long as variables and methods were named well.I agree with him on the inadequacy of my example. In fact, the parameter types in my example method are confusing at best, or outright wrong at worst. But I believe that everyone gets my point so I won't correct it.
In fact, in your example, typing the argument as an array of string doesn't help much. What does it mean for a currency to be a string? Is it a standard abbreviation like "USD" for US Dollars, or is it spelled out "US Dollars", or is it simply "dollars"? Are they currency amounts (in which case I'd expect the type to be numeric)? There are many potential levels of ambiguity that you'd need documentation/tests/trial-and-error to resolve.
But Jeremy asserted that the typing issue is not so much of a concern, as long as variables and methods are named well. I didn't share this experience. In my projects with JScript, I often found myself scratching my head over the methods of objects that I defined, probably because my projects entailed the definition of more complicated objects beyond the most primitive ones such as integer, or string or double. Even if my method names or variable names are clear, there is a big possibility that I could get the methods of the objects wrong.
So I need to keep a handy reference to any objects I used, and to type in the object's name and its property carefully or else I need to wait until the runtime to find the problem.
Imagine if someone else were to take over my code. How much trouble he would have to suffer.
Mikkel Garcia argued that because static typing checks for types at runtime, so some developers actually took false comforts in it and didn't do unit test.
As others have mentioned, coming from a C++/Java background into Ruby or Python - it can be difficult to understand the merits of a dynamicly typed language.It is certainly sad to see developers not doing unit tests, no matter for what reasons. The fact that the developers felt that typing checking was enough to verify the program correctness is doubly more appalling. They need to be properly educated ( or reeducated) so that they could start doing unit tests for their code.
(In my experience) Many teams I've encountered in the Java world only have the barest of unit tests, or sometimes no unit tests at all. One of the reasons I've attributed to this is that the compiler tells the developers if there is something terribly out of place. That warm fuzzy feeling of compiler acceptance is mistaken for program correctness.
In an interpretted dynamic language, there is no fuzzy feeling - leading to more developers seeking to test program correctness (instead of compiler acceptance).
But to say that typing checking is bad because of this is not convincing. Suppose that some drivers mistakenly believe that the safety belts can protect them from harm in accidents, and so they drive recklessly and get themselves killed, can we therefore blame that the safety belts are responsible for their death? Of course not.
Type checking is like safety belts; it's designed to catch type errors ( and real typing errors). If anyone believes that he can write code without unit tests just because the code is checked for type correctness, then that's his problem.
