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.

Re:Strong Typing is a Must

[MaggieL]

Type consistency is not a guarentee of correctness. It's not even close to a guarentee of correctness.

Type consistancy may not be a guarantee of correctness, but type inconsistancy is a guarantee of trouble. :-)

Re:Strong Typing is a Must

[jbester1]

Ever tried an ML derivative?
They are statically typed, yet typed-inferred so you save quite a lot of time and any change cascades itself down. Saves a whole lot of time, especially nice since the type system is flexible enough to do symbolic computing.

Re:Strong Typing is a Must

[shaper]

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?

Maybe it's just me, but I've found that much (most?) non-trivial systems that I write are not easily unit-testable. They are usually part of or dependent on large libraries and infrastructure. Most of that infrastructure I did not write nor do I have access to its source. Much of it is often poorly documented, so that one does not have any clear spec upon which to build tests.

Instead, I tend to rely on the tools to do as much as possible for me, type checking being just one tool in one phase. I expect and plan for unexpected behavior and design for graceful error handling and degradation at every level of code. I know that the developer that wrote that library is at least as lazy as me, probably even more, so I cannot depend on documentation and correct behavior and I definitely do not have the time to write test cases for every interface in every external library that I use.

Maybe its my early background in military systems. I just got used to disciplined development and I don't really have to think too much about type correctness. I just tend to be careful about it out of habit.

And finally there is the one iron-clad fundamental rule of software development: a defect found earlier is much easier to fix. I prefer to catch as many errors as I can by compile time. Everything after that starts getting much more expensive really fast.

Re: Strong Typing is a Must

[Black Parrot]

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

OK, I have experience in Ada, BASIC, C, and C++, and I spend far less time debugging stupid errors in the strongly typed language: Ada.

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

Were we talking about "strong" typing or "static" typing?

> 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

But that's a rather weak reason for not doing whatever checking we can do.

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

Strong typing is nothing more than saying what you mean and meaning what you say. I don't know where the heck the purported steep price comes from, since in my experience the strong type definitions in my programs provide me with a set of abstractions to work with. If I declare some colors, they're always colors, not just facades for numbers. And thus I immediately and consistently think of them as colors rather than as obfuscated numbers.

You should learn to think of strong typing as a mechanism for providing additional constraints on the behavior of your programs. It baffles me that people think that is a bad thing. I find that using a strongly typed language moves bug discovery forward in the development process and makes me think more clearly about the higher-level algorithms I'm coding.

Re:Strong Typing is a Must

[L3WKW4RM]

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.

Sorry, but what you describe above is the java Interface, a way of guaranteeing that an object will meet a particular group of method signatures (but doesn't require any of the work like creating parent-class implementations). This is something that Python lacks in a big way. For instance, all the almost-like-all-file objects you mention don't have the same group of file-like methods. An interface promises you that all the methods you expect will be there.

And I really don't understand the argument against strong typing anyway, are you too fucking lazy to use an extra keyword for an argument and return type? You don't like having auto-generated documentation that you can actually use without examining the code to fill in the details?

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 [stanford.edu] proves no non-trivial property of programs can be proven mechanically. (This implies type correctness is not an interesting property ;-) )

I'm sorry, but this is just wrong. I'm writing code in a weakly-typed language with the most advanced IDE possible. If I'm writing inside a function or method definition, that IDE cannot provide me any intelligent auto-completion or method checking of ANY of the arguments passed in. That IDE can provide me no help when using that funtion or method because it doesn't know what it returns. This might not mean much on a small API that you wrote yourself, but working with someone else's code on a large project means that you've got to have access to all source, all the time to serve as your own documentation.

Re:Strong Typing is a Must

[battjt]

I started in ObjC when all Objects were void* (now I think there is normally more checking). I loved it.

Then I did 6 years of Java and C++.

A year ago I started working with my original coworker on a large project in Java. He is still using a not very strongly typed programming style (lots of casting and parameters of type Object). It is extremely hard to understand what is going on. There are sections of code that have strong static typing and they are much easier to understand, because the type is obvious. I don't need to go digging through the code to find out if I have a list of switches, switchFamilies, or references to archivedSwitches; the type can tell me right there what I'm dealing with.

After almost 10 years of corporate IT programming experience at 6 different companies, I find that strong typing is appropriate for large jobs with higher turn over and dynamic typing may be more powerful for jobs with a few guru programmers that need job security.

Joe

Re:Strong Typing is a Must

[cow-orker]

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.

-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

Re:-1 Flamebait

[g1zmo]

Who ships as soon as it cleanly compiles???

My boss.

Strong Typing is too noisey

[rudy_wayne]

Whenever I type strongly my wife complains about the noise and asks that I type more quietly.

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.

Unit testing has practical limitations

[yerricde]

You don't run unit tests at run time! You run them before you ship.

No practical unit test provides 100 percent coverage of all special cases that can conceivably occur in a sufficiently complex system.

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.

Re:Some helpful distinctions

[e-Motion]

Weak Dynamic typing: Perl5 (no, really, test it, it's scary - worst of both worlds!)

That's why the first thing every Perl programmer should type (ok, after the hash-bang line) is "use strict; use warnings;". (Or s/use warnings;/something else that enables warnings/). The Perl interpreter will happily process your mistakes without blinking if you don't take precautionary measures. For example:

# use strict;
# use warnings;

$foo = "bar";
$foo += 3;
print $foo, "\n";

If uncommented, the "use strict;" line will cause the interpreter to complain about $foo not being associated with a package (guards against typos). The "use warnings" line will cause the interpreter to print a warning message when it executes $foo += 3 ("Argument "bar" isn't numeric in addition (+) at..."). With both commented out, the interpreter happily executes the code and prints (on my system) "3". I agree that this behavior is horrendous. So remember kids, "use strict" and enable warnings!

Re:Strong Typing Is For Weak Minds

[Bastian]

I know I spent hours chasing bugs that wouldn't have been possible in Java.

Wise man says, "If you shoot yourself in the foot, it's easier to solve the problem by being careful not to aim the gun at your foot than it is to make guns that don't point down."

Strong Typing

[jasonditz]

For strong typing I recommend an old IBM-PS2 clicky keyboard. Those who are more inclined toward weak typing can stick with the Microsoft Natural keyboard.

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

the majority are not good programmers...

[LinuxXPHybrid]

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

That's probably true, but my wild guess is that the majority of so called programmers are not good programmers. Knowing that, what tool (programming language) should be provided to programmers to write a better (not necessarily good) programs? I think that's the question to be asked.

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!

Some not-helpful distinctions

[sulli]

here are some totally unscientific definitions, do not use:

Strong typing: Original IBM PC keyboard, requires effort, but very satisfying for coding, data entry, letter writing, or any other purpose requiring text. Your hands will get tired.

Dynamic typing: The old Apple adjustable keyboard or the IBM Butterfly laptop. Breaks easily, but may fit your hands better.

Weak typing: The Atari 400 membrane keyboard. Often too wimpy to handle adult hands.

Static typing: Keyboard has loose wiring and gives you an electric shock. Ouch!