Guido van Rossum

From August 21 through 24, I attended the O'Reilly Open Source Software Convention in Monterey, California. It was a great location, great weather and a great conference. The first two days were tutorials, followed by two days of conferences and the trade show. The show was generally excellent, with over 1600 attendees.

The conference was an outgrowth of a Perl conference, and it had tracks on Linux, Apache, Python, Sendmail and Tcl/Tk, as well as the Perl track. This variety of tracks afforded a great opportunity for the various open-source software tribes to get to know each other.

I tried to play the field and attended a Samba tutorial in the Linux track, a modperl tutorial in the Apache track, a Tcl/Tk introduction, and a Python tools for XML programming tutorial.

During the two days of the conference, I spent some time in conferences, including keynotes by Guy Kawasaki and Bill Joy, and some time at the Linux Journal booth. As a whole, it was a great conference. Miguel de Iscaza, leader of the GNOME project, summed it up by pointing out that, unlike other recent shows, this really was a conference for developers by developers. From the tutorials to the included lunches, good organization and good content were evident everywhere. I look forward to attending the conference again next year.

With a large Python track, Guido von Rossum was, of course, in attendance. Our scheduled 30-minute interview turned into an enjoyable three-and-one-half-hour evening on the Monterey waterfront. The first part of the interview is included here. After this interview, Guido went on to talk about CP4E, his project to turn Python into the language used in colleges. That portion of our interview is here: An Interview with Guido van Rossum.

Phil: Python vs. Perl? Obvious question. I heard last night that some Python guys and Perl guys met, and now you are good buddies. Or actually John Orwant said, “The Python guys are a lot nicer than the Perl guys.”

Guido: The funny thing is that while there is a lot of animosity in the lower ranks, I've actually been very friendly with Larry Wall and Tom Christiansen ever since we met five years ago at the VHLL symposium that Tom organized. Tom really wanted me there and made sure I was among the invited speakers describing one of the three major scripting languages.

Phil: What was the third?

Guido: Tcl. Well, maybe Python was the third!

Phil: I've been doing shell programming and AWK programming for close to 20 years and if somebody says, “Here, can you write this in Perl?” the answer is, “Well, yeah I can,” and the reason I can is because I've got 20 years of experience writing in all the pieces that make up Perl. But to go out and tell somebody, “Oh, you are going to learn a new programming language and the design of this language makes perfect sense” is an issue. I don't see how I can do that with Perl, and yet I can do that with Python. That's the distinction for me.

Guido: I think the core of the matter is that Perl has a very UNIX background and claims to be portable. If you talk to people, they all think Windows stinks and UNIX is the one true operating system.

Phil: I think that too!

Guido: Well, you better, given your choice of profession! That is a very typical point of view you find a lot in the Perl world. There also seems to be a bit of dislike for GUIs or anything that smells of user friendly. Part of the UNIX community has that dislike. I grew up in a research environment where we used UNIX; we were one of the earliest UNIX sites in Europe and one of the earliest Internet sites in Europe as well. But we weren't so partial to UNIX. We were interested in what came next. For a while, I considered myself a graphical-user-interface designer—learned a lot about user interfaces.

Phil: What were you doing at the design end? Or what were you implementating on?

Guido: Oh, the implementation varies—eleven X Window systems as well as Macintosh. I almost never touched a Windows box until Windows 95. Because, before that, any GUI programming was hell. Windows has grown up a lot. There was actually an interesting Python on Windows, even with Windows 3.1. I think that's where Mark Hammon started, actually.

Phil: You said you are not really using Linux right now. What are you using as a platform?

Guido: At work, I have a very big Solaris box on my desk. At home, I have a laptop fast enough and big enough to serve as a desktop machine, and it dual-boots Windows 98 and Linux. I use Windows just for compatibility with many of the people at work and for historical reasons, because we were using a lot of Windows applications. I don't use Windows much for programming; the only programming I do on Windows is—well, there are two kinds—little games programmed in Python, toy applications for testing some idea where it doesn't matter which platform I'm using, and maintenance for the Python port to Windows. The Python port to Windows has two components to it—the core part, which I manage, and the old Windows-specific additions, which Mark Hammon manages. So people typically download two files, and they can get both from http://www.python.org/. The first one is the standard Python distribution which gives you a command-line interpreter, documentation and the standard library—a bunch of goodies. And then, actually, I looked at a bunch of statistics—one third of the people who download Windows installers also download Mark Hammon's extensions.

Phil: What's the ratio of Windows users to UNIX users?

Guido: I don't know about actual users, but downloads from python.org are something like two-thirds Windows and one-third UNIX. All sorts of explanations for that, probably because the UNIX people can build from source. One download may represent a larger number of users. With Windows, I imagine one download often represents one user. Linux, at least, also has the possibility of downloading RPMs from a different site—we don't have any statistics for other sites.

Phil: Plus, Python comes with virtually every Linux distribution anyway.

Guido: Yeah, well, there are lots of complaints about that. They're not very up-to-date and they don't have a very large set of standard extensions, so it takes a little extra work to configure them at compile time. If you want the full Python installation on your Red Hat Linux, for example, you want to download all of Andre's stuff.

Phil: By the way, I actually do use Python. I've been telling people at the office, “We've got to start programming in Python.” We went through a couple of Perl programmers who could produce code extremely fast, but when they found new jobs, we were sitting around going, “What is this stuff?”

Guido: That is one of the things I've always had as part of my philosophy: it's much more important that you can read someone else's code than how fast you can produce your own code. Again, that is something very few people in the Perl community appreciate. I know Tom Christiansen does appreciate it. But many of the people who are in the trenches doing Perl programming don't have the time to learn how to write it right; they just copy the examples they found in the legacy of the previous person who was hacking at that site.

Phil: Sometimes that's fine. I write a lot of disposable stuff in AWK. Here is some data, I've got to turn it into something and load it—fine.

Guido: As long as you actually dispose of it!

Phil: Exactly!

Guido: My dad used to say there is nothing more permanent than a temporary solution. A lot of disposable software ends up persisting beyond all reason.

That is actually one of the big differences between the Perl philosophy and the Python philosophy. Perl gives you lots of different ways of doing things which makes it much harder for the reader, because if you are writing code, you need to know only what you know—you need to know only one way to do what you want to do. But, if you are reading, you need to know everything before you can actually read it. I mean, it's not so different from understanding a language like English. My passive vocabulary, what I can understand when people speak to me, is a lot larger than my active vocabulary—the words I can actually use myself. Not growing up as a native speaker, my active vocabulary is smaller than that of a typical native speaker. For the casual programmer, you have the same situation where you know enough of the language to get by for your own programming needs. But if someone else presents you with something he wrote, he probably knows a different subset, and there is no agreement on what the basic 600 words are that you both need to know to get by. It's often quicker to run a program and see the results, then reproduce the code in an idiom you know and start hacking on corrections, than it is to try to understand how the code works and change that.

Phil: That's similar to what IBM did with PL/1, the ultimate language. If you went into a company that had both FORTRAN and Cobol programmers and you said, “You are all going to write in PL1,” then the Cobol programmers wrote Cobol in PL/1 and the FORTRAN programmers wrote FORTRAN in PL/1!

Guido: And the Algol programmers wrote Algol in PL/1.

Phil: It seems like Python is starting to be taken really seriously in web development and so on. Is Python being taken seriously in academia? I guess I mean relative to Perl, because Perl isn't, as far as I can see.

Guido: I would say Python is being taken a lot more seriously. There are language designers who don't approve of certain short cuts, or the fact that Python doesn't have static typing, or the fact that there are other languages out there that are as good as Python is, and again borrow all the good features from those languages.

Phil: What languages?

Guido: Some people think, for instance, that Dylan—which I think has a very academic flavor—is everything Python is plus so much more.

Phil: Dylan? I've never heard of it.

Guido: Well, that's exactly Dylan's problem. I don't know, but I think it started out as a LISP variant, with sort of an alternative syntax. The syntax was deliberately unLISPish in order not to scare off everyone who is not already brainwashed with LISP, because LISP has one of the biggest image problems of any programming language in the world.

Phil: I had to learn LISP in college, and I can appreciate that! Keypunching parentheses is not my favorite thing.

Guido: I like a lot of the concepts of LISP, but I strongly disagree with their approach to syntax, which happens to be the same approach Tcl has, more or less. Which is, there is no syntax, or it's so simple you have to do everything else outside the syntax.

Phil: Is Tcl making it at all in academia?

Guido: I am sort of removed from academia, so I don't quite know. I don't think so. I mean, one or two people I spoke to recently from academia had a very strong opinion that Python was a decent language and Perl and Tcl were not.

Phil: To me, the biggest thing lacking in Python is books. To learn the language, basically, there are three books out there: the two O'Reilly books and the one you wrote...

Guido: I didn't write that!

Phil: Okay, the book you didn't write!

Guido: Aaron Watters wrote it. I was originally supposed to write one chapter. When I came back from vacation ready to write the chapter, they had changed the deadline and already started printing! So I thought, hmmm, good! Until the beginning of this year, there were clearly too few books. Right now, Learning Python is by far my favorite Python book.

Phil: Hey! It's mine too!

Guido: Yeah. I think what we'll see is that several other publishers will start publishing Python books. I mean, I've been talking to authors, and I actually managed to piss one off because I didn't like the chapter he sent me. But everyone else I'm fairly okay with. And the one I pissed off is going to continue anyway, so more power to him. There will probably be five or six more books by the end of the year. Mark Hammon and Andy Robinson have almost completed another O'Reilly Python book, specifically for Windows users. Dave Beazley, who is solidly in academia—an assistant professor at the University of Chicago—has already finished writing and turned in the manuscript for a quick Python book for the experienced programmer. It has all the information you need to learn the language quickly and start using it. There is one big appendix in the book which is almost the entire library reference manual. All the relevant things are in the New Riders series. I think two different people are working on Python books with Tkinter. There is another quick Python introduction, and plans for something like an 800-page book with lots of annotated examples. So there is lots of stuff coming out, and it's aimed at a much larger variety of users. The first books that come out try to be everything for everyone, and that is kind of hard.

Phil: I guess the big thing you are playing with now is JPython?

Guido: JPython is really big, but I'm not personally very involved, actually. One of my well-respected colleagues at the CNRI (Corporation for National Research Initiatives) is now doing the maintenance after Jim Hugunin (see http://www.python.org/) and the original author have decided to move to the West Coast.

Phil: JPython is a really neat thing. If Java actually becomes the success it wishes to be ...

Guido: Java is a decent language, but it really needs a companion like Python. I have to admit that was one of the things I was very skeptical about initially when Jim Hugunin came up with the idea. I thought, “Oh, my! That is going to be so slow! That's not going to be worth it.” It was a little slow, but not so slow as to be unusable. I had to push Jim to add some psychological tricks to the way the interpreter initializes itself. I think the current version quickly prints the command line, the first prompt and then actually finishes initialization. This has the advantage that during the second or so it takes you to type your first command, the initialization finishes, so when you hit return, you have an instant response.

Phil: I worked for a computer sciences department on the development of an operating system in 1970 when everyone was using a teletype. We had a basic interpreter, and when you typed run, the basic interpreter printed out the name of the program and the current date and time. It did that to cover up the fact that it was compiling it into byte code before it was going to run. Same story, but you had a lot more time when you had about 50 characters to print on a 10-character-per-second teletype.

Guido: Well, that kind of trick still works, but JPython is its own world. I think it is the only language integrated with Java in this particular way, where you basically have cross-language inheritance. You can inherit in Java from a Python class and vice versa, and you can override methods in each direction. So the people who use it, use it typically as an extension language for a large system totally or almost totally written in Java, where they need to provide some end-user program ability. I think one product, Object Domain, is an application that is sort of UML for Java programs, and you can do all sorts of manipulations with the UML objects. In a little corner of the screen is a Python prompt—when what you can do with the menus doesn't give you enough flexibility, you can write your own Python code right there and execute it. That is how JPython is used as an extension language to Java. That is the equivalent of what people have been doing with CPython in C or C++ applications all this time. But with Java, there really weren't very many options like that, and Javascript hasn't made it outside the embedded HTML world.

Phil: I haven't done much with Javascript.

Guido: It's actually a decent language. It doesn't have the whole object-oriented kit and kaboodle Python has, and that's its big weakness. Actually, Javascript and Python share a lot of syntactical ideas, and the dynamics of the language is also more or less the same. It's probably purely coincidental.

Phil: In the near future, we will be developing some software that needs a local user as well as a web-based human interface and a database back end. The local user interface needs to be semi-graphical with minimal keystrokes. We are considering using Python and a database such as MySQL or Postgres. Are we on the right track, or are we crazy?

Guido: There are tons of options. I don't know if you've done any research yet in that area, but I still like Tkinter best—it seems to be the most popular. It is called the de facto standard. I like it because it is portable between Windows, UNIX and Macintosh. I think the only other option that has those three platforms is WX Windows, which is a big C++-based thing. It used to have a Python port that was fairly poor; I think it's all been redone, and I hear it is much better now. I've never used it myself, because I am so happy with Tk interface. I've also seen other good things. Some of my colleagues have just started playing with GTK, and it certainly looks very slick; the code is about as clean as Tkinter code. Apparently, the GTK port for Python is actively being maintained, unlike some other offerings. I think there is a KDE or a Qt port that is not being maintained any longer.

Phil: The biggest problem we decided we had with most Tk documentation is that it is attached to Tcl, which is the best way to confuse somebody who is trying to write something else. I guess there is a book coming out.

Guido: There are already two books coming out—I have no idea when exactly, so it may even be another year. I expect it to be a little earlier than that. In the meantime, the best place to go for information is the HOWTO section, or there is some kind of resource guide on the python.org site where Tkinter is actually one of the topics which basically has pointers to all the other stuff you need to know. The best documentation for Tkinter is the web pages Fredrick Lund put together and had on his Python web site.

When we designed Tkinter, we were aware of the fact that we couldn't possibly document it all. Certainly not document all the semantics. STK was changing because when we started Tkinter, Tcl/Tk was at release 7.3 or so. We knew Tcl/Tk was going to evolve, so we ported most parts. We set up a very regular structure of mapping between Tk commands and Tkinter, mapped in classes. So, you can prepare a small set of rules that say, if it looks like this in Tk, it looks like this in Python. Along with that, there is a lot of information you can learn from the standard Tcl/Tk documentation. Tcl/Tk has excellent man pages. Whenever you are unsure what options to the grep command are or how to do a button that has a particular property, look it up in the Tk documentation and apply the mapping—sure enough, it works in the Python world.

Phil: That's cool. It's likely that's the way we will go.

Guido: Can I offer one piece of advice? I think one of the reasons for the success of Python, Perl, Tcl, Linux and Apache is lots of extensibility. People can scratch their own itch by writing their own little module that does what they need to do so they don't have to bother the original developers with “Can you please add this feature?,” the problem every sort of fixed system ends up with.

Phil: I agree completely. There are just too many pieces of software that were written to solve somebody's problem but actually didn't solve it, where the marketing department took care of explaining why it did solve it. There is a company in Redmond that is really known for doing exactly that.

Guido: Their recent offerings are actually pretty extendable, but where they aren't—that's when it's bad.

Phil: Is the Python community ready for a magazine?

Guido: Probably not yet.

Phil: That's what I told John Orwant about the Perl community, but he didn't believe me!

Guido: Well, that's good! With this kind of stuff, I'm always happy to be proven wrong. We tried an on-line magazine and there were one or two issues and that was it.

Phil: Yeah, I saw it.

Guido: Realistically, the Python community is an order of magnitude smaller than the Perl community. If you look at the number of Python people at this conference vs. the whole thing, that's probably an order of magnitude plus a factor of two maybe. So we need to grow.

Phil: The limiting factor in any magazine is advertising. When you buy a subscription, that pays for the postal service to get the magazine to you. It's advertising revenue that pays for producing the magazine. I feel like Python is in a place where there really aren't any potential advertisers except book publishers.

Guido: There aren't many people who have Python products. I mean, there are a lot of people who have products that use Python in some corner of the product. There are also lots of people who use Python but don't sell Python stuff directly. I don't know if you know it, but Industrial Light and Magic uses Python. Yahoo! bought a small company called 411, which had one of the earlier more successful web-mail applications that, not incidentally, was written in Python. Actually, I think that has happened at least twice now. I know two almost-identical cases where a small, start-up company used Python very quickly to prototype and release a product that is first of its kind. They were the first to market it, and they were so successful they were bought by a large organization, looking for a product in that area, whose efforts haven't paid off just yet. Once it gets absorbed into that big company, what usually happens is it gets rewritten in C++. That's what's happening with Yahoo! Mail, mainly because they have, after maybe two years of experience, settled on the course of the features. Now they are interested in dealing with the 80,000 subscribers they get every week or every day or so. They buy new hardware too, but you need to use that new hardware efficiently, so they rewrite the stuff in C++. If anyone had started writing that stuff from scratch in C++, he would never have gotten the product out!

Phil: They'd still be writing it!

Guido: Exactly! And because during the initial three months or so of figuring out exactly what you want, you rewrite the thing so many times and that's where you really need the very high-level dynamic range.

Phil: How common is that, that people are prototyping in Python and rewriting it in C++ or some other semi-reasonable language?

Guido: I'd say it's common for the things that become a blatant success. Lots of places end up not bothering doing the rewrite in C++, even though they always have that as part of their strategy, because the prototype works well, and performance isn't the problem in many cases.

Phil: Certainly over the years, we have addressed performance by making cheaper hardware that's faster.

Guido: Such a lovely development!

Phil: I remember UCSD P system, and other than Pascal, it isn't exactly the savior of world language. If UCSD P system had appeared with the speed of today's hardware, it would have been an amazing success because nobody would have cared. It would have solved the problem.

Guido: I manage to follow only a very small piece of the general free software world. But I am often amazed to see people post a small C program—maybe a thousand lines—that they spent a lot of time on and that does a job well. And I think, “My God! Why did they bother writing it in C? What's the performance need here?” If this is something to manage your calendar, for example, why would you bother writing that in C?

Phil: Well, that's all I have to pick on you about. Thanks for taking the time to talk to me.