On type safety
Posted on October 13, 2006
True type safety is an illusion. Without type safety, however, are your programs destined to a buggy doom? Not really. Type safety is definitely good for eliminating a basic class of bugs, but the problem is that program errors are often more subtle than confusing an integer for a string. Type safety is like a broad contract; it can guarantee general conditions (that a field is a string, or an object is of a particular transaction type), but not specific uses. Unfortunately, correct programs often require more specific constraintsfor example, it is not enough that a customer ID is typed as an integer; it must be an integer in a particular range that validates against internal checksums that go beyond what can be expressed with mere types. In other words, static types can never replace full-fledged testing, but too many programmers act like it does. Compiling is not testing; testing is testing. Bugs happen in both statically typed and dynamically typed programs, and the best defense is unit testing or some other more-rigorous testing approach. Because it is not compiled and has no static types, ABCDEF might seem to be more dangerous to develop in; but in some sense, it can actually be safer to program in: Because developers have no illusions that type checking is a serious defense against bugs, they will not confuse compilation with correctness.
How would I know if in unit test I test the same type I have in a program?
If type safety is definitely good for eliminating a basic class of bugs, why remove it entirelly?
It is true that correct programs require more specific constraints that default data types provide, why then custom type specifically designed to enforce thouse constrains would not be sufficient?
ABCDEF might seem to be more dangerous to develop in. Is it or is it not?
Does it mean that in unit-tests I have to check if every computation puts result in valid co-domain?
Filed Under Uncategorized |
Leave a Comment
If you would like to make a comment, please fill out the form below.
Last year I thought dynamic languages that only did type checking at run time were a great idea.
Now however, after seeing the kind of problems people have been running into with Haskell’s types I think type inference is definetely the way to go.
I hate having to declare types all the time.
I think you are right. Type inference is defenetly helpfull. And I like that I can explicitly assign the type in some cases.
I really hate it when Java forces me to write a fsckload of code just to get a string converted to an int and handle all the stupid exceptions it raises if it doesn’t like the string.
There must be a better language! Something like:
Haskell without monad nonsense
+ Java VM and libraries
+ Erlang threads
+ some C
+.Net for Windows integration
+ build in multi-tasking support
+ GUI stuff
+ support for components and versioning.
I also like how methods are called in Ruby and Smalltalk, instead of calling a methods you sent a message to an object. You actually invert who is in control.
Object can decode method name and act accordingly (ex: object db does not have find_by_name method but it can perform db.find_by_name())
Unfortunately Ruby does not have interfaces or some other techniques to define formal class contract, so it looks very much like magic or side-effect.
On the other hand Java now is very stable platform and we probably will not see any language innovations any time soon. Just better libraries and faster run-time.
It takes a lot of code to express something in Java, I don’t think that this is a really big problem, when you work on a project it’s possible to construct abstraction layers and hide ugly lower-level code.
I still like the way Java forces me to consider possible bugs. Good IDE like IntelliJ IDEA also helps a lot. Unchecked exceptions in my .net programs pop-up regularly and surprise me.
I think that checking error code of the function in not a very good solution, because you always forget to do that (at least I did when I programmed in C/C++)