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.'"

Comments

More discussion

[(a*2) (ron)]

Check out the recent discussions on lambda the ultimate (a programming languages weblog).

Guns don't kill people

[KDan]

"Strong or Weak Typing doesn't make good programs. Good programmers make good programs."

Daniel

Strong Typing is a Must

[the eric conspiracy]

I think that this argument is exactly backwards. Strong typing allows mechanical type checking via compilers and incremental type checkers during the development process. Strong typing takes a lot of the load off a human developer, and puts it on mechanical systems that can be made much more reliable than humans. The important thing is to take maximum advantage of strong typing - use an IDE that does incremental compilation, etc.

On the other hand, since it is not possible to mechanically check weak typed code, weak typing places much more load on the programmer to make sure the types are correct than a strongly typed system. The result is many more bugs, and bugs caught much later in the development process when they are more expensive to correct.

Re:Strong Typing is a Must

[Jerf]

Sorry, but that's spoken like someone parroting the party line, not someone with experience in both.

Strong typing allows mechanical type checking via compilers and incremental type checkers during the development process.

OK, but A: it only allows type checking and B: it enforces type checking.

A: Type consistency is not a guarentee of correctness. It's not even close to a guarentee of correctness. It's not even more then loosely related to guarentee of correctness. Type 'errors' are only one class of error, and they are detectable in both paradigms, just at different times. Don't skip the focus on "unit-test based testing"; the point of unit-based testing is that it tests for any kind of error you can program a test case for, including type errors, wrong-output for input, environment interaction, and all the other kinds of non-type errors that happen in real life. Unit-test based programming says why pay so much for such a weak guarentee of correctness when you can spend that time writing unit tests and test for useful properties?

Note that XP calls for unit testing in all languages, not just dynamic ones. You need to be writing them anyhow; why not lean on them and keep your program flexible and tested correct, rather then "proven type correct"?

B: It enforces type consistency. How many times have you wanted to jump out of the type cage? When programming in a dynamically (not really 'weakly') typed language, it encourages an "interface based" style. If you implement an object that has all the necessary methods, and it'll work right, why shouldn't you be able to use it just because it's not the right "type"? Many, many things in Python present a file-like interface, or a string-like interface, or a sequence-like interface, without having to inherit from the official implementations which may be very wrong for their purposes. And many other parts of the language do that too.

And guess what? Even in large programs, the world does not come to an end. See unit-testing, although even without that it's still usually OK.

Because the interface style pervades the whole language, you get to easily write programs that can handle certain types of "type" violations without blowing themselves to smithereens like you might expect if you've never tried it before.

On the other hand, since it is not possible to mechanically check weak typed code, weak typing places much more load on the programmer to make sure the types are correct than a strongly typed system.

Two more things:

One, my experience and the experience of a lot of others says the opposite. You spend an unbelievable amount of time jumping through compiler hoops in a static typed language, and sometimes the smallest change cascades down your entire static hierarchy. You spend a lot of time worrying about things that really aren't importent in the grand scheme of things. Half the time if you're trying to write with any sort of flexible pattern like Iterator or something you end up with a superclass called "Iterable" or "Object" (sound familiar?) or some equivalent, which isn't that far from dynamic typing anyhow.

The other thing is again, "mechanically checking" code isn't possible for anything but type-correctness. No other goodness properties can be checked that way; in fact Rice's theorem proves no non-trivial property of programs can be proven mechanically. (This implies type correctness is not an interesting property ;-) )

If type safety could give me something above and beyond type safety, I might be interested. But all it does is "prevent" a class of problems that don't exactly plague most coders anyhow. It's an incredibly steep price to pay for something that doesn't do much for you.

I've experienced both sides of this. Sure, in theory type checking is great, but in practice, the dangers of type errors are incredibly exaggerated. It's just not a problem. It's too late to convince me with theory that has completely failed to play out the way the the type-safety advocates said it would.

-1 Flamebait

[clem.dickey]

So what other imperfect things should we do away with? Roads with median strips? Safety locks on guns? Metal detectors?

I would argue that strict typing reduces one class of bugs so that I can concentrate on other less tractable classes. Who gave Guido the idea that strong-typing programmers are satisifed with clean compiles. I will be satisfied with clean compiles when the compiler can detect *all* bugs. Until then we (some of us, at least) need to work on improving languages and language tools toward that goal.

Re:-1 Flamebait

[DannyBoy]

I completely agree with you. Any software developer who doesn't have their head up their ass knows that a clean compile only means that you've made it past the simplest bugs. The good ones have unit and regression tests, the others just run a few testcases by hand. Who ships as soon as it cleanly compiles???

The main thing that scares me about languages with run-time time checking is that the types can change at run time. If you have unit tests where a variable is a integral/scalar value, and then somehow at runtime it has a string value (cause someone called your function incorrectly), you're screwed because you didn't test that. And if your response is that you should have had a unit test for that, then you'd have to have a unit test for every type (incl user defined) types in the language. This isn't really a problem if it is a small program or you are scripting something, because you can have more control over the inputs, but in a large system, especially with a large development team, compile time type checking has an incredible value!!!

dan

That's a wild-assed statement...

[dozer]

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.

Some helpful distinctions

[Phouk]

Here are some totally unscientific definitions, use at your own risk:

Static typing: Both variables and objects have types. Type checking happens both at compile time and run time.

Dynamic typing: Variables don't have types, but objects do. Type checking happens at run time.

Strong typing: Strict and effective type checks; a string is a string and not a number. Often confused with static typing.

Weak typing: Absent or ineffective type checks. E.g.: everything is a string, or everything is a pointer. Thus, a string could be used as a number or the other way round. Often confused with dynamic typing.

Python, for example, has strong but dynamic typing.

BTW, if you haven't seriously tried a dynamically typed language yet, maybe you should - they are simply much more fun, IMHO.

Re:Some helpful distinctions

[AJWM]

Think of it this way: the variable is just a (named) bucket that can hold stuff, objects are the stuff that sometimes goes in the buckets (and sometimes is just pointed to by something in a bucket, etc.)

If you put a Foo object in bucket 'bar', it will still be a Foo object when you take it out, so (in a strongly typed language) you'd better be expecting a Foo. But when you're done with the Foo, you can put a Baz object in that bucket 'bar'.

The bucket doesn't have a type, the object in the bucket does.

Subjective

[Tablizer]

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.

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; // suspicious line

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.)

Here's my vote for static typing!

[Tom7]

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.

(Does anyone else find it a little scary that Guido confuses "strong" and "static" typing?)

There's not much substance in this article to actually refute, but I would like to share my experience on this. I have had a lot of experience with static and dynamic, strong and weakly-typed languages, though not much with Python.

I'm a fan of statically-typed functional languages, especially SML and O'Caml. I agree that static typing catches many bugs; ones that would not be caught at compile-time in a dynamic language. However, in my experience, spending time getting the types right is not a distraction but actually a guide in the design of the program. Static typing encourages . Even if I considered all of that time (which amounts to very little once you become good at the languages) a burden, I think static typing would still be worth it. The reason is that compile-time errors are much, much easier to track down and fix than ones that occur only dynamically (or only once you've shipped your program!).

By the way, "strong" typing does not mean writing down a lot of types. (ML and Haskell have type-inference systems where you end up writing less than you would in C or Java, and maybe even less than in Python!) By the time you become an expert in a language like ML, you are hardly encountering type errors (except when you make a typo or actual mistake), and hardly writing down anything having to do with types -- the best of both worlds!