Slashdot Mirror
Guido van Rossum On Strong vs. Weak Typing
Bill Venners writes "In this interview, Java creator James Gosling says, 'There's a folk theorem out there that systems with very loose typing are very easy to build prototypes with. That may be true. But the leap from a prototype built that way to a real industrial strength system is pretty vast.' In this interview, Python creator Guido van Rossum responds with 'That attitude sounds like the classic thing I've always heard from strong-typing proponents. The one thing that troubles me is that all the focus is on the strong typing, as if once your program is type correct, it has no bugs left. Strong typing catches many bugs, but it also makes you focus too much on getting the types right and not enough on getting the rest of the program correct.'"
Guido: "Strong typing catches many bugs, but it also makes you focus too much on getting the types right and not enough on getting the rest of the program correct."
Really? Really??? This blanket statement certainly doesn't describe anybody I've worked with. I wonder what information he bases it on...
In a production environment, I've found that writing strongly typed programs always saves time in the long run. It doesn't take much more time and, if you occasionally make a silly mistake (like using == instead of eq in Perl), it can save you hours of aggrivation and headache.
For quick one-offs, of course, losely-typed is always the way to go.
As somebody who has seen many forum-fights over this issue, I think it is probably subjective. There are complex tradeoffs, and the final score is probably greatly influenced by personal factors. What trips up person A may not trip up person B nearly as much.
// suspicious line
I personally like "dynamic" typing. It is easier to read, and it is easier to spot errors that may be missed if there is a lot of formal typing clutter IMO.
However, I think it might be possible to get closer to the best of both worlds by having a "lint"-like utility that points out suspicious usage. For example, it might flag this usage:
x = "foo";
doSomething(x);
y = x + 3;
If you really want it to do that, then you could tell the utility to ignore that particular line to not distract future inspections. (Assume the above language uses a different operator for string concatenation.)
Table-ized A.I.
Indeed, static type checking cannot prove your program correct, but it can prove your program incorrect, without even running a test. If your type system is sufficiently powerful to express your intention, the type checker helps. If it is too weak, it will get in your way. The latter happens all the type in C, where the fix usually involves void and it happens in Java where the fix is spelt object and a type cast.
Where the type system is expressive enough, I never found a need to cast. Neither in Haskell, which has a polymorphic type system, nor in C++, where the template mechanism creates a sort of meta-language with weak typing used to generate a strongly typed program.
When programming in a dynamically (not really 'weakly') typed language, it encourages an "interface based" style.
As does the use of templated classes and functions in C and as does Haskell through its type classes.
in fact Rice's theorem proves no non-trivial property of programs can be proven mechanically.
Indeed. You shouldn't bother writing unit tests, after all they are a doomed attempt at mechanically proving a program correct. Even worse, the attempt of formally specifying what in correct is already doomed.
So both tools, tests and typing, are imperfect. Choose what helps the most or combine them. I see great value in a clear error message telling me the bar was not supposed to go into a container of foo, as opposed to an error telling me a bar was missing some method I meant to invoke on a foo. The alternative is to write a test case, that checks if something that goes into my container really is a foo. Which is actually the same as worrying about typing and declaring the type.