A Conversation with Bruce Eckel, Part II

---

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 this second installment, 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.

Productivity over Performance

Bill Venners: In the introduction to your "Why I Love Python" keynote, you gave ten reasons you love Python. Number eight was that Python doesn't value performance over your productivity.

Bruce Eckel: Valuing performance over productivity is an issue with a lot of languages. We all know it is good to avoid premature optimization. It's hard not to optimize prematurely when programming, and perhaps the same thing is true when designing languages. Language designers often say, "I see this is going to make your life harder and productivity lower, but because I know performance is important, I'm going to do it anyway." The Python designers said, "No, programmer productivity is the most important thing. We can worry about performance later." That's really what you should do.

So the Python designers try to make Python as fast as possible, but they don't, for example, make you declare variables and use static type checking. They said, "Latent type checking is really an important feature. We're going to make sure that happens, so the programmer gets the best experience." Maybe latent type checking requires some compromise in performance, but it turns out that for maybe 80% of the programs you write, performance doesn't really matter. And for the other 20%, when performance is really important, it's possible to profile and optimize.

Take Zope, for example. Zope is the enterprise application server I use for my website. Zope is virtually all Python, but includes some C code, because they profiled and optimized Zope so it would run faster. When Zope was put on my machine, I discovered it was noticeably faster than Apache had been. That seemed surprising to me, but my server guy said Apache was designed for correctness and not for speed, so it wasn't that surprising to him. Because Apache was written in C, I figured it ought to be faster. But it turned out Zope was faster.

Freedom and Responsibility

Bill Venners: In your keynote, your seventh reason for loving Python was, "It doesn't treat me like I'm stupid." Could you speak a bit about that?

Bruce Eckel: When Java came along, they bashed C++, a language that I had worked with I don't know how many years. I had been going to standards committee meetings, etc, and I understood C++ very well. I understood the C++ design decisions. The Java people poo poo-ed those design decisions. They said, "C++ is bad and we're really great." But then I started delving into Java, and there were a number of decisions they made that were not particularly enlightened.

For example, Java doesn't have operator overloading. In C++, operator overloading is in fact quite complicated. But a lot of that complexity is because you can pass objects or references in C++, and there's no garbage collector. So operator overloading gets really messy in C++. But, ironically, in Java, you could easily do operator overloading, because all those problems basically go away. First of all, in Java you're only dealing with references. And second, you've got the garbage collector. Nevertheless, they came along and said, "Well, we decided that operator overloading was a bad thing, and it would be dangerous for us to let you have it. So you can't." Well, OK, except that Strings in Java have operator overloading. You've got operator + and operator +=. It's a little difficult to swallow, because they're saying operator overloading is bad, but gee, it was awfully useful here. That's precisely true. Operator overloading is useful in certain areas. Java is filled with those sorts of decisions.

In Python, they basically say, "You want it? You can have it. We're not going to try and protect you from yourself, saying these features are too dangerous." So there's all kind of stuff in Python. Python has metaclasses, for example.

Bill Venners: What are metaclasses?

Bruce Eckel: Metaclasses are really powerful. If you look at a class as a factory for objects, a metaclass is a factory for classes. A class has the information about what an object looks like. If you mess with a class, you change what the objects look like. If you mess with a metaclass, you change what the classes look like. For example, with the help of some of the people in the Python community, I duplicated Java's synchronized keyword using metaclasses. So I can have synchronized methods on classes. Whenever you use synchronized, the metaclass would insert the necessary code at the beginning and the end of the method. You start looking at that and you go, wow.

Bill Venners: So metaclasses are an example of where the Python designers are giving people something that may be a little dangerous if abused, but very helpful when used appropriately.

Bruce Eckel: It is hard to say. We might see something like metaclasses eventually in Java, because they've been adding more interesting features to Java, like dynamic proxies. For Python, things like dynamic proxies and delegation are just one-liners. They are quite straightforward.

One of the things I find that's remarkable about Python is that it has a very even learning curve. Maybe it's not even a curve, It's kind of a straight line. Learning Python has a zen-like quality, because Python doesn't try to make the world something else. The designers of Java wanted to make the entire world look like a Java virtual machine and the Java libraries. In addition, Java's designers decided that the C++ approach of allowing functions and global variables in addition to classes is bad. So everything in Java has to be declared in a class. For that reason, Utah Valley State College stopped using Java as an introductory language. They actually teach C++ as a first language, because they found it a lot easier.

Python would make an even better first language to teach programming. It's such a gentle learning curve. You can start with scripts, and of course some people dismiss Python as a scripting language, because you can script with it. You start teaching scripts. You can teach functions. Then later you can add classes. Then you can go onto things like metaclasses. Python has many more of these powerful constructs that you can learn when you're ready. And I think that's very impressive, because it doesn't say you should only be an object-oriented programmer.

And in addition, the way that Python treats platforms is very reasonable. Python says, we're going to allow you use all the stuff you want in Unix or Windows. Now, beware that if you decide to use these specific, Unix-only libraries, you're not going to be cross-platform. But you'll know that. So it's your choice. Rather than saying, "No, you can't even know what the underlying platform is." So Python can be cross platform just fine. But if you want to talk to the specific operating system—if you want to talk to the Unix facilities, to COM, or whatever—it says fine. You can do that. They say, "How can we help you," rather than, "How can we coerce you behave the way that we think you should?"

Code versus Thought Experiment

Bill Venners: The sixth reason you gave in your keynote for loving Python was, "I don't wait forever for a full implementation of the language." What did you mean by that?

Bruce Eckel: I was talking about C++ there, still smarting from, Gee, did Microsoft ever implement C++ fully? Java was a great relief over C++ in that department. A new version of Java would come along, and all the features would be there. Whereas in C++ we would say, "Let's think about how templates work," and years later we would get a template implementation, and maybe not then. Only in the last year or two have we seen truly full implementations of templates and the language in general. That was just incredibly frustrating. With Python, the language features are actually tried out live. They'll decide they're interested in trying out certain features. They'll do a fork of Python, put the features in, and see how it flies. That's a much nicer way to design a language than by thought experiment, as we basically did with C++.

Next Week

Come back Monday, June 30 for Part III 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.

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

Talk back!

Have an opinion? Readers have already posted 7 comments about this article. Why not add yours?

About the author

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima.com. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project that produced the ServiceUI API. The ServiceUI became the de facto standard way to associate user interfaces to Jini services, and was the first Jini community standard approved via the Jini Decision Process. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community. He currently devotes most of his energy to building Artima.com into an ever more useful resource for developers.