Before you read this post in it’s entirety, you need to head over to Justice Grays blog and see his post on his Grandmother and the difference between strong-typing and weak-typing.  Instead of placing an unsanctioned guest blog post in the comments section of Justice’s blog, I decided to write it up here.

I do believe that the one thing Justice didn’t explicitly state in his post was that in being strongly typed I would fail immediately. D’Arcy, on the other hand, will fail at only when he tries to use his Saved By The Bell DVD as a martial aid. The difference here is that I’m failing fast (one of my favourite agile principles) while D’Arcy will fail slowly (people from Winnipeg are a little slower by the nature of the narrow provincial family tree).

Justice is right when he states that unit testing in weak type languages is more important because of this D’Arcy’s tardiness. My problem with that is that you’ve now taken the type verification away from the compiler (which will run exactly the same every time) and placed it on unit test. True that the unit tests will run the same every time (assuming that you don’t build test dependence into your test suite), but it raises the question of how good are your tests.  More to the point it raises the question of how good is the coverage in your tests.  Since a weak-typed language won’t fail until the guilty line of code is executed, code coverage becomes much more important than any other metric that you look at.  Because we can generate weak-type based errors, it now becomes prudent for us to include tests in our test suite specifically for these scenarios.  So now we’ve modified our list of testing variations to include state based, process based and type based which also implies that that I will have to spend time on writing more tests and that I will have to maintain more tests. 

When I’m writing code I work with one large underlying principle.  Give the client what they want.  I also work to provide the client with what they want in a timely fashion.  My clients don’t want unexpected failures at run time.  If I can avoid some of those failures by employing a strong-typing and compile time checking, I will have immediately eliminated a whole classification of defects that the client can report.  If I don’t have to worry about weak-typing errors, I also won’t have to write and maintain a whole classification of tests.  This will improve my ability to provide value to the clients in a timely fashion.

The short version of this posts is that I’m not a fan of weak-typed languages because they add overhead to the development process in the form of potentially increasing the number of reported defects and, as you attempt to limit the reported defects, an increase in the amount of time spent writing and maintaining unit tests.  For some people this may not be a primary concern in their development and that is fine.  For my clients and I defects and time (which is money in development-land) are always a primary concern.