The Artima Developer Community
Sponsored Link

Strong versus Weak Typing
A Conversation with Guido van Rossum, Part V
by Bill Venners with Frank Sommers
February 10, 2003

<<  Page 2 of 4  >>

Advertisement

It's Runtime, Not Weak, Typing

Guido van Rossum: One of the things I like about Python is that everything happens at runtime. Python's compile-time complexity is almost nonexistent compared to that complexity of languages like C++ or even Java, which is much simpler than C++ at compile time. Although, doesn't Sun plan to add generics to Java?

Bill Venners: Yes.

Guido van Rossum: Well, they have to, because it is a strongly typed language, and you can't do certain things with strong typing otherwise.

Weak typing is not really a fair description of what's going on in Python. It's really runtime typing because every object is labeled with a type.

Bill Venners: Every object in Python does have a type.

Guido van Rossum: Every object does have a type. It is a string, an integer, a floating point number, a dictionary, or whatever.

Bill Venners: But method parameters and return values don't have types.

Guido van Rossum: Those variables don't have types. Runtime typing works differently, because you can easily make a mistake where you pass the wrong argument to a method, and you will only find out when that method is actually called. On the other hand, when you find out, you find out in a very good way. The interpreted language tells you exactly this is the type here, that's the type there, and this is where it happened. If you make a mistake against the type system in C or C++, and it only happens at runtime, you're in much worse shape. So you can't simply say strongly typed languages are better than runtime typed languages or vice versa, because you have a whole tradeoff of different parts.

Bill Venners: Let me try to restate what you said. Basically, as a strong typer, I may believe it is always better to detect errors sooner rather than later. You agree, but you also say I must weigh the cost of the mechanism used to detect those errors sooner. One cost of the strong typing in Java is that I have to finger type all my variables' types. Another cost is I may have three or four iterations of compiling, because I've screwed up something that may not really matter to my program's proper execution. You're saying in a strongly typed language I'm wrestling with things that take up my time.

Gosling said, "Anything that tells you about a mistake earlier not only makes things more reliable because you find the bugs, but the time you don't spend hunting bugs is time you can spend doing something else." You're saying, if you don't have to actually do all the extra work to make the strong typing compiler happy...

Guido van Rossum: You still have time to do something else. In Python, because your program is shorter, you can actually test it much sooner than when you're writing a large Java or C program.

You can also easily write a small piece of code in Python and see that it works. You can do very fine-grained unit testing. Bottom-up program development works really well. You can easily start with only a vague idea of what you want, start to implement it, and see how well it works so far. You can then change many things around. If you have a strongly typed language, changing things around becomes much more painful.

In a strongly typed language, when you change to a different data structure, you will likely have to change the argument and return types of many methods that just pass these things on. You may also have to change the number of arguments, because suddenly you pass the information as two or three parts instead of one. In Python, if you change the type of something, most likely pieces of code that only pass that something around and don't use it directly don't have to change at all.

<<  Page 2 of 4  >>


Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us