Type Checking and Techie Control - A Conversation with Bruce Eckel, Part III

Type Checking and Techie Control - A Conversation with Bruce Eckel, Part III

Type Checking and Techie Control
A Conversation with Bruce Eckel, Part III
by Bill Venners
July 7, 2003

Page 1 of 3 >>

Advertisement

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

* In Part I: Python and the Programmer, Bruce Eckel explains why he feels Python is "about him," how minimizing clutter improves productivity, and the relationship between backwards compatibility and programmer pain.
* In Part II: The Zen of Python, Bruce Eckel explains why he prefers Python's valuing programmer productivity over program performance, Python's you-want-it-you-can-have-it attitude, and Python's zen-like learning curve.
* In this third installment, Bruce Eckel explains why he prefers Python's latent type checking and techie control of language evolution.

Discovering Errors

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 Bag of 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 read.

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.

Finding Errors with Real Data

Bill Venners: You said in your keynote, "Errors discovered with real data seem to me to be the hardest to find."

Bruce Eckel: Yes. If I'm writing a Python program, I can very rapidly get to the point where I have a working program, and then I can actually feed it real data. And it seems like certain kinds of errors are much harder to find without putting real data into it. When you're trying to make something, the closer you can get it to the real thing as soon as possible, the more you'll find out about it early on. You really have to get it that close, or things will slip through the cracks.

Bill Venners: You're saying it takes me longer to write code that is statically checked at compile time, but the problems the compiler finds are not the kind of problems that have to do with real data.

Bruce Eckel: That's actually very well put. Once I get the program running, I feed it real data. Then I'm going to find some interesting errors. So the sooner I can do that, the sooner I can find those errors.

Marketing and the Techies

Bill Venners: The fourth reason you gave in your "Why I Love Python" keynote was, "Marketing people are not involved."

Bruce Eckel: The Python venture is basically controlled by the techies. We make decisions based on what's going to make the life of the programmer easier. Even with C++, which was a standards committee, I remember early decisions being based on worries about the existence of a body of code which was a drop in the bucket relative to what we have now. But they were saying, "We can't make this change in the language because we would break all that existing code," which was basically trivial. We should have made those changes at the time. That was sort of a marketing decision because many of the people on the committee were representing companies who had vested interests in C++ in some way or another.

Certainly people that come to the Python conferences often use Python within companies. But I guess it's rarer that Python is the flagship programming environment of any sizable company. They always end up using something else. Because of that, the people who are coming, even if they are coming from a company that's using Python actively, are typically more Python enthusiasts than people worried about how Python will affect the bottom line. Although now there is the Python Software Foundation, and basically that's a way for companies to contribute to the continuing development of Python and at least have the ear of the core Python team. So in XP terms they would be customer representatives, I suppose, although they don't have that much leverage. They have the ability to communicate that much easier.
Next Week

Come back Monday, July 14 for Part IV of a conversation with Elliotte Rusty Harold. I am now staggering the publication of several interviews at once, to give the reader variety. The next installment of this interview with Bruce Eckel will appear in the near future. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.
Talk Back!

Have an opinion about type checking, finding errors, or techie versus marketing control of technologies? Discuss this article in the News & Ideas Forum topic, Type Checking and Techie Control.
Resources

Bruce Eckel's Mindview, Inc.:
http://www.mindview.net/

Bruce Eckel's essay on checked exceptions: Does Java Need Checked Exceptions?:
http://www.mindview.net/Etc/Discussions/CheckedExceptions

Bruce Eckel's Public and In-House Seminars:
http://mindview.net/Seminars

Bruce Eckel's Weblog:
http://www.mindview.net/WebLog

Python.org, the Python Language Website:
http://www.python.org/

Introductory Material on Python:
http://www.python.org/doc/Intros.html

Python Tutorial:
http://www.python.org/doc/current/tut/tut.html

Python FAQ Wizard:
http://www.python.org/cgi-bin/faqw.py