OpenIDStrong Typing vs Strong Testing
In Strong Typing vs. Strong Testing, Bruce Eckel reconsiders the old idea that languages without strong typing can’t be relied on to create large programs:
This became a puzzle to me: if strong static type checking is so important, why are people able to build big, complex Python programs (with much shorter time and effort than the strong static counterparts) without the disaster that I was so sure would ensue?
His conclusion is that type checking by the compiler does not garauntee the correctness of a program in the first place; it’s just another test. Comprehensive unit testing can more than compensate for the lack of type checking in languages such as Python, especially since the huge productivity bonus provided by Python allows more tests to be written starting at an earlier stage in development.
Incidentally, Bruce recently added an RSS feed.
Bruce makes a very persuesive point, not really one that I'd given much thought to, maybe I might just get around to giving this Python malarky a go :-P
This does mean that I am going to have to rewrite the bit our software project where I diss PHP as an implementation language for not having strong typing, as I no longer to believe that to be a problem. (PHP has plenty of other "problems" so I'm not too concerned :-P)
Swannie - 4th May 2003 22:26 - #
Harry Fuecks - 5th May 2003 10:16 - #
Unit testing can be done on strongly typed languages, weakly typed languages, and dynamic typed languages. Doing unit testing on weakly typed languages is not just about checking your types, obviously. So the strongly typed languages are not automatically unit tested. Unit tests involve checking code that is not always related to types. Sure. But in a weakly typed language, when you do unit testing, you actually do spend time verifying that the type you are receiving is the correct type. Here you are reinventing strong typing, by writing code by hand which checks your types. You are also doing other testing not related to types, but you still are doing those type checks regardless. Now, why would anyone want to take extra time and write by hand, some routines that check your typing?
Obviously, no programmer in his right mind is going to want to spend extra time writing tests that some automated system could have helped him with. Most unit tests need to be written by hand, despite all the so called unit frameworks out there. Any unit testing that does anything useful has a lot of code written by hand. If you are checking a shopping cart for accuracy, you cannot expect the XYZ testing framework to solve all your shopping cart issues. You must pretend you are a customer, and write tests that are custom to your situation. Mostly by hand. So you are already taking extra time out to write these tests by hand - how are you going to have any extra time to also write tests for type checking by hand? No matter which testing framework or roll your own testing you use, it's going to take a lot of time to do unit tests - doing type tests just adds to your time taken.
In addition to testing your shopping cart for general accuracy and proper behavior, you now also have to test the shopping cart for proper types? If a string is being passed in when it should have been an integer, you may end up adding a 0 (zero) instead of 50 (fifty). But at this point you are reinventing strong typing - and taking extra time out of your daily programming to check types - does offer a good ROI?
In a strongly typed language you still do unit testing - you just test for issues in your program that don't relate to your typing. You test your shopping cart for proper behavior, but you don't spend time writing tests that check to see if the incoming variable contains 50px or 50. Or 50USD versus 50. If the incoming variable is 50px or 50USD in a PHP script, PHP considers this 50px and 50USD an integer, and converts it to 50. But it truncates the USD from your incoming variable! You must write unit tests for this, because this is a very common error that could occur in your program. In a strongly typed language, you would not pass 50USD to your shopping cart calculator since your shopping cart calculator expects an integer, not a string. But in PHP, 50USD, even though it is a string and WRONG, still gets passed into your script without any errors. And not only does 50USD get passed into your script, but PHP has the nerve to convert 50USD into 50! But yet USD50 is converted into 0 (zero). This is inconsistent behavior, and requires more unit tests in order to check your typing (reinventing strong typing).
If your incoming variable was p50, PHP considers this 0 - if your incoming variable is 50p, PHP considers this 50, not zero, and not 50p, but 50. But in a strongly typed language you will be writing unit tests not to check these silly things - you will be writing unit tests that are more important and more useful. You will be writing unit tests which save you time, not waste your time.
Therefore all languages are strongly typed. So called weakly typed languages are still strong in the end, if you write unit tests to check your code. And faster prototyping does not exist in weakly typed languages unless you do not use unit testing. So unit testing is optional - but the reality is you are going to have to write tests at some point and reinvent strong typing.
So much for the fast prototyping abilities of a weak and dynamic typed language. Your fast prototyping time is now lost, because you have to take the time out to do type checking using unit tests. And these unit tests are not automatic - they must be written by hand. Written with your bare hands. Now, how many programmers out there have the discipline and time to actually write unit tests that to type check their program? Wouldn't they stop right there and move on to a strongly typed language, since time could be saved? How many programmers find it boring to right "type check" tests for their code?
How many programmers actually write unit tests, period? So let the strong and strict compiler do some work for you - no one claims that the compiler can solve all your errors - but if you are going to reinvent type checking in some of your unit tests (not all of them, no one claimed that either) then you might as well automate it instead of writing it yourself - i.e. move to a strongly typed language.
And about boredom and motivation: one cannot tell me that writing unit tests to check your types is an interesting and fun thing to do.
Unit testing can be done on any language. So weakly typed languages don't have the advantage of unit testing, per say. Since any program written in any language can be unit tested.. weakly typed languages have no advantage in the unit test arena.
I'll have to emphasize one point again: I'm not saying a compiler does the unit testing for you. Tests need to be written around any serious program (it's common sense - anything needs to be tested - bikes, cars, programs, helmets, house structures). Whether the program is built with a strong or a weakly typed language doesn't matter - you still have to write tests. But whether you spend extra time writing unit tests for type checking - is what it boils down to. Whether you want to reinvent strong typing or not, in an inefficient manner, is what it boils down to.
L505 - 25th May 2006 03:56 - #