Sponsored Link •
Bruce Eckel talks with Bill Venners about why he prefers Python's latent type checking and techie control of language evolution.
Bruce Eckel wrote the best-selling books Thinking in C++ and Thinking in Java, but for the past several years he's preferred to think in Python. Two years ago, Eckel gave a keynote address at the 9th International Python Conference entitled "Why I love Python." He presented ten reasons he loves programming in Python in "top ten list" style, starting with ten and ending with one.
In this interview, which is being published in installments, I ask Bruce Eckel about each of these ten points.
Bill Venners: In your "Why I Love Python" keynote, you gave ten reasons you love Python. Number five was: "It doesn't make assumptions about how we discover errors." You also said, "Lack of static type checking in C was certainly heaps of trouble." If lack of static type checking was heaps of trouble then in C, why isn't it heaps of trouble now in Python?
Bruce Eckel: In pre-ANSI C, before you actually even had argument lists, you would say, "Here's my function. And by the way, here are the arguments." But the thing is, there was no checking at all, ever.
Bill Venners: There was no checking in C at runtime either.
Bruce Eckel: No. There was no checking, because C began as a high level assembly language. When they moved to ANSI C, they decided they would have arguments with types. So you got checking in ANSI C, but only at compile time. You didn't get runtime checking. This compile-time checking was hugely better from what it was before. C++, which forced the hand of ANSI C, improved the checking even more. So as programmers we could easily think in the direction of, "Ah hah, static type checking saves our bacon. That is a really super good thing to have."
With time and experience, however—partly with Java and even more so with Python—I began to realize that when type checking occurs doesn't matter so much as that the type checking occurs at all. I think generally you can say that early type checking is better than late type checking. But late type checking is better than no type checking at all. And sometimes, late type checking is better than early type checking. It's a balance.
Strong static type checking forces the programmer to do a lot of extra work. And we think that's good, because we're whipping that ornery programmer into shape who would otherwise misbehave. But as a result, the programmer's doing a lot more typing...
Bill Venners: Finger typing?
Bruce Eckel: Yes, finger typing. With static type checking the programmer must do lot more finger typing and a lot more thinking about these details. The programmer uses valuable brain cycles up on that stuff, rather than on actually solving the problem. There are situations where latent typing, sometimes called weak typing, frees up what you're doing so much that you can really think about the problem and the expression becomes clean. The type checking still happens, it just happens later in the process.
Latent type checking gives you much more flexibility in your programming. The
way I describe it to C++ programmers is that with latent typing, or Python in
general, when you write a function, you get templates without templates. What
you're saying in C++ with a template is that you've got code that doesn't care what
type it works with. As long as these operations can be performed, then the code is
happy. It's actually being evaluated at compile time and spewing out horrible
error messages if it fails. But the idea is that the programmer is able to say, "I
would like a
Cats." The thing says, OK, as
long as I can perform these various operations on
Cats that I
want to, I don't care if it's
Cats or whatever. That's what you get
for free with Python without any of that template syntax. It turns out that's
incredibly powerful. It makes your programming a lot easier to write and, I think, to
But the thing is, if you try to do those operations on the inappropriate type, you actually have to do it at runtime to find out that that's a problem. If you are still totally convinced, as I guess I was at one time, that strong static type checking is the greatest thing in the world, as soon as that slips away into the later type checking, you start to get nervous. You think well, what if the thing that would cause the type to be checked doesn't happen? Because if it's latent checking, the checking doesn't happen until you try to use this thing, rather than when the compiler runs. But I think in Java we've also found out that we check things at both compile time and runtime. And it seems like we tend to find those problems out. Every once in a while you would imagine something might slip through, but that's really almost a surmise. It seems like most of the time things don't slip through. When they do slip through, you get an exception. You find out about it right away. So it's not as bad as we think coming from strong static type checking background.