|
|
Re: Is Static Typing a Form of Bad Coupling?
|
Posted: Apr 13, 2006 2:01 AM
|
|
Bill Venners:
Looks like I'm going to be learning Haskell soon time permitting, because the local Silicon Valley Patterns group is going to have a track on it. So after that I may be better able to understand the issues.
I wouldnt say that by learning Haskell, you will want to use it professionally, but its certainly changing the way I think about programming, which is a good thing.
Someone else mentioned that typing is a kind of a contract, and one that can be checked by the compiler. In dynamic languages, those contracts are checked using unit tests, and for my python programs I tend to find that I liberally sprinkle assert statements all over the place checking the types of method arguments. Optional typing, in my mind, moves some of the load of type checking from runtime asserts to compile time checks. A worthy goal, but why not simply move to implicit typing.
A type can be inferred from context, as in the example you provide. The language defines the rules for type inference, and then that allows me to express a fully statically typed program with less verbosity.
Right, and the types can also be partially inferred, for example, the type of "foo(x,y) { return x + y; }" is the set of all types of x and y for which a "+" operation is defined. The type needs to be fully resolved before execution, but you get the idea.
One of the more powerfull aspects of a dynamic language is being able to say "print x+y" and just have it work, for many possible values of x and y. At runtime, the right "add" method is discovered and executed, based on what the runtime types of x and y are. I can do this in C# today, sort of, by calling MethodInfo.Invoke and having the system find the best matching method to invoke, based on the parameters.
I love programming in Python, but having recently worked on some huge projects in curly brace langauges, I wouldnt consider doing one using Python. I still use python to put together smaller pieces of code, (although Im forcing myself to use Haskell, as a way of learning it).
Strong typing (explicit or implicit) has saved me enough time that I perfer to keep using it. In fact, in some ways, I would like to see stronger typing enter the languages I use, for example, non-nullable references (al-la Nice).
Id also like to see Eifell-style pre and post-condition contracts enter the language, as I feel that this gives many of the benefits of unit testing, while making the tests part of the source code itself rather than separate entities. You would still need unit tests, but the focus would be on testing the interoperation between classes rather than the classes themmselves. I heard a rumor that C# 3.0 may well get pre- and post-condition contracts via Spec#, and that the approach has been highly successful in indentifying bugs and even race conditions.
|
|
Previous Topic
