Doug Kaye: Hello, and welcome to IT Conversations, a series of interviews with experts in today's hot topics in information technology. I'm your host, Doug Kaye, and my guest today is author, programmer and programming language architect, Paul Graham. In 1995 working with Robert Morris, Paul built what was arguably the first major web-based application, Viaweb, which was acquired Yahoo in 1998 and became Yahoo Stores. In 2002 he described a simple Bayesian spam filter that has inspired many of today's spam filtering packages. Paul is also the author of two books on Lisp and most recently a very different book entitled Hackers and Painters, published by O'Reilly & Associates. Hello Paul, thanks for joining me today.
Paul Graham: Thank you.
Thanks for inviting me.
Doug Kaye: Paul, one of the things that you are allowed to title a book Hackers and Painters because as I look in your resume, you've actually studied painting in Europe. That's something you don't talk a lot about, but tell us a little bit about how someone with such a strong technical background got involved with painting. Paul Graham: Well I realized that what I liked about computers was not computer science in the sense of studying them and figuring out what one might do sort of mathematically. What I liked is making stuff and that's what painters do, too, they make stuff. And they make stuff that is sort of to many people more colorful and may be more interesting than software so it was just a naturally exciting thing to do, to go paint.
Doug Kaye: How did you get started with painting, was it something you did as a child?
Paul Graham: No, actually I didn't, not particularly, not anymore than other kids did. What happened was, I went to visit a friend of mine; he was a graduate student a Carnegie Mellon, and in the afternoon I went down the hill to the Carnegie museum, which is actually a great museum. And I was walking around; it was a weekday and in the middle of the day and there wasn't really anybody else there, and I could really see the paintings without this big crowd of people. And I thought these weren't made by some mysterious, other group of people called 'artists' or some other tribe, I could do this. I could make these too if I wanted to, if I tried hard enough and wouldn't that be a great thing to do. It was this epiphany. So I really was, and in fact am, really untalented, but as in hacking, hard work accounts for an awful lot in painting, and so I thought if I worked hard enough I could paint well and that's what I tried to do. Doug Kaye: Are you still painting?
Paul Graham: No, actually I haven't painted anything for a couple of years, I don't think, maybe a year and a half, and that's one reason I don't talk much about painting itself in Hackers and Painters because I don't really consider myself to be a painter. I consider myself to be someone who is trained in painting, and there are lot of people who are trained in one thing, but do something else. There are a lot of people who are trained in math, but what they actually do is physics. There are a lot of people out there who are trained as painters, but don't work as painters because there are a lot of kids go to art school and have very few opportunities to make money painting. Doug Kaye: Well Hackers and Painters is quite an eclectic book. It's quite unusual in fact to be published by O'Reilly; it's in hardcover no less. It appears that it's a collection of essays you've written over some period time. Is there a singular concept that binds these various essays that caused you to put them together in a single book?
Paul Graham: Well, I suppose, yes there is a…in running through them all which is about hackers, meaning really good programmers, what do really good programmers do. So some essays are specifically about hackers like what is the hacker ethic? That is what the chapter, Good Bad Attitude is about. And then others are about the things hackers do, like care a lot about programming languages or write web based applications and stuff like that. It's the kind of book that someone who is or really wants to be a very good programmer would find talked about things they had probably wondered about. Doug Kaye: The first chapter of the book really caught me by surprise, it wasn't what I expected given the title of the book. This chapter is entitled, Why Nerds are Unpopular and it's a fairly personal analysis of what it's like to be a nerd in junior high school. Why did you write this chapter? What was the message you were trying to get across and who you were writing this for?
Paul Graham: The people I really wrote that for is high school kids now. I wanted to write something that would tell them what I wished I had known at the time. And when you're a kid people just sort of hand you this kind of life you're supposed to live on a plate and say, "Here eat this." You're used to being told what to do all the time and you never consider that in fact the adults might actually be kind of clueless sometimes and give you the wrong stuff. And so the life that we give teenagers to lead now is actually terribly broken because of some things that have happened in the economy. Teenagers are economically not all that useful now, but you have to do something with them and so you store them in this warehouse for their teenage years until they're old enough to be trusted in college. And this ends up producing this life that is just disastrous to live in and it just feels really terrible. And they even have this excuse about why you feel so terrible: It's hormones, right? But you never hear any mention of hormones before the 20th Century, you never hear any of this, any references to this idea that all teenagers are supposed to be crazy.
So I think there's something else that makes teenagers feel so unhappy and so crazy and that is the weirdness of high school and merely knowing that there's something terribly wrong should make them feel better. It's like you're walking around and you feel, "Oh my God, I feel terrible! What's going on with me?" and then you take your temperature and you have a temperature of 102, well that explains why you have a headache.
Doug Kaye: Is it your sense that it's fairly specific to American culture in the 20th and 21st century? Paul Graham: Well I have got a lot of emails from people all over the world saying, "Wow, it's just like this is my country too." I have had so much email about this, literally, probably 2000 emails about this. I think it's worse in America, but it's fundamentally the same problem everywhere. Doug Kaye: Is there a solution? Do you see something that we as a society can do to alleviate thisis problem, because there's a lot of pain and suffering going on during those years. Paul Graham: Yeah! Well, look at the root of the problem. One root of the problem is that everybody is stuck together in one place with nothing to do. So one possible solution is this Stuyvesant kind of solution where you take…you have different kinds of high schools for kids who are interested in different things and the nerds who are interested in the sciences and so on, go to special high schools like Stuyvesant in New York, magnet schools. That would make it a little better. Another thing that would make it better is teenage kids did actually have something to do. Everybody thinks they need to be idle somehow or that 17-year-olds can do anything, but it might be that 17-year-olds could do something and that all these laws that are intended to protect kids from child labor? Maybe that's not actually saving them from something they need to be saved from. Doug Kaye: The second chapter of the book, which is in fact entitled Hackers and Painters, draws parallels between hacking and painting. In what ways do you think to program is more like painting than it is like some of our more common metaphors such as engineering?
Paul Graham: One big difference between painting and engineering is engineers.in buildings for example there is this distinction between architects and engineers. Architects decide what the building is going to look like basically and then they say to an engineer, "Can I do this? And then how?" And the engineer figures out how. So architects figure out "what," engineers figure out "how." Well painters do both. Painters decide what to paint and then have to paint it. And hackers in the best case also do both. They're not merely engineers who just figure out "how." The great hackers decide "what" and then figure out "how." And in fact the two can influence one another in a cycle in the best case. In the best case, you figure out "what" by trying various "hows." Doug Kaye: Now you particularly, I noticed, dislike the term computer science. Why is that?
Paul Graham: I always felt so cheesy saying it. I still feel people say, "You have a Ph.D. in what?" and I say "In computer science." Maybe it was because I was an undergraduate at Cornell where they had all these departments like Poultry Science and Food Science. It seems like when you have some kind of field that's not really a field yet, you stick some noun onto the word science and that's what you called your field. Maybe I'm going to get in a lot of trouble with people in Poultry Science for saying this. Doug Kaye: Well, it's an often-debated topic, whether it is computer science as opposed to another term, which is software engineering. People take exception to that too.
Paul Graham: Well here's another term. Look at what Don Knuth did. Arguably if anybody knows what the story is with computers, it's Don Knuth and he seems to have very pointedly called his big series of books, The Art of Computer Programming. I don't think that was a coincidence. Doug Kaye: Continuing on the theme of understanding hacking and hackers, you wrote that empathy is probably the single most important difference between a good hacker and a great one.
Paul Graham: Yes.
Doug Kaye: What is empathy in this context, and why is it so important for you?
Paul Graham: Well empathy means putting yourself in the other person's position, in particular, the user of your software. And hackers don't always realize this because often they design software for which they themselves are the typical user. So if you're designing a compiler or an editor, at least an editor of the types that programmers use like Emacs or an operating system or something like that, then you're designing stuff for yourself, and it's okay, you don't have any difficulty putting yourself in the other person's position. But you want to design anything beyond those few kinds of tools that programers use, you have to be able to see what the user is going to think when he approaches your program, and this is very different from what you'll think, because you wrote it and you understand everything. So you have to be able to put yourself in the position of someone who has no idea of what he's going to get when he sits down and tries to use your program. Doug Kaye: Is there a technique for doing that? How can you train someone to be empathetic, or is there a way that you can determine that someone is empathetic before hiring them, for example?
Paul Graham: Well a lot of people get trained in empathy as kids. This is why parents are always telling you, "Look at it from their point of view." That's what they're trying to teach you, not to be this […]. A lot of people never manage to learn that as kids. I think empathy is something that is largely an aptitude. You can help people learn it, but there's also a large ingredient of just inherent aptitude in empathy. Some people are naturally empathetic and some people aren't. The weird thing is it seems like people in the sciences may be naturally less empathetic than other people, which is a problem, because that's the world hackers are in. Doug Kaye: Many of the lessons you learned about both programming and business are from your experiences building and then selling Viaweb. For example, you wrote, "When we interviewed programmers, the main thing we cared about was the kind of software that they wrote in their spare time." Paul Graham: Yes.
Doug Kaye: I can see that, but tell me a little bit more about what you learn from interviewing someone and asking them about what they code when they're not getting paid for it. Paul Graham: Well, what you're mainly looking for, or what we were mainly looking for and what I think most people probably ought to be looking for when they hire programmers, is to find people who really love to program because not just for programming, but for anything, to be really good at something you have to love to do it. And so anybody who loves to program, is probably not going to be content with whatever random stuff they're told to do at work. They're probably going to have some great project of their own that they're working on. So it's not so much you care about what the particular project is. What you care about is that they have one and that they're really into it. It almost doesn't matter what it is. I mean it's cool if it's something interesting, especially if it's related to the kind of thing you want to hire them to do, but that doesn't matter. The main thing that matters is that they love to code.
We found we knew after three or four minutes really whether we wanted to hire somebody. We had three tests, one, were they really smart? Two, were they a really good programmer because there are plenty of people who are smart, but somehow or other don't end up translating to being a good programmer. And three, could we stand them, because there are a lot of people who are really smart and really good programmers but you just could not stand to talk to them for more than five minutes. And so if they passed those three tests: really smart, really good programer, and we could stand them, that was it. That was our three criteria.
Doug Kaye: You ultimately did manage to sell Viaweb to Yahoo and when you wrote about that experience, one of my favorite quotes came out. You wrote, "I remember sitting back in the dentist's chair, waiting for the drill, and feeling like I was on vacation." Tell us how you got to that point.
Paul Graham: Well, I had left a board meeting to go to the dentist. Board meetings are always terribly painful. It could be it was because I was an ineffectual CEO and didn't manage things properly, but it seemed like our board meetings were just always the most rancorous arguments. We got a reputation actually in the Boston high-tech VC community as being some kind of "dysfunctional startup" they called us. We may have argued a lot, but we made customers very very happy, and that's what ends up mattering. Doug Kaye: I was really surprised to learn that Viaweb was written in Lisp.
Paul Graham: Well, it wasn't written entirely in Lisp. It was the editor that was written in Lisp. The editor that the merchants used to make their online stores was written in Lisp. The shopping basket that the customers used to buy things from the online stores, was written in C. Doug Kaye: Why is that? Why some and some?
Paul Graham: Well they had to do very different things. There had to be…there were for every store there were one or two orders of magnitude more shoppers, a lot more shoppers than there are merchants. And so the shopping bag process had to be a really lightweight process whereas it didn't have to do much. The shopping basket…you put stuff in your shopping basket, and you look at the stuff in your shopping basket and maybe you delete things from your shopping basket or change quantities or place your order and after that about it, so it was not a huge program. It was small and it had be fast, whereas the editor, we tried to make feel like a WYSIWYG, a what-you-see-is-what-you-get program and that required some fancy tricks.
Doug Kaye: Tell us a little bit about your long history with Lisp and ultimately why you selected it for this project for example.
Paul Graham: Well, I selected it for this project partly because it was a really good language for writing programs and partly because I couldn't program in any other language except Lisp. It was slam-dunk.
Doug Kaye: Did you start with Lisp in school?
Paul Graham: Yes, I started learning Lisp in the early in 1980s, I think 1983, back when Lisp was supposed to be the language of artifical intelligence, which was a big thing then. By the time I got to graduate school in 1986, I quickly realized that artifical intelligence was a complete crock. And so I thought, "Boy, what can I salvage from the wreckage? Of all the stuff I have learnt what's actually good?" And I thought, "You know, what I really like about AI is Lisp hacking, Lisp is really good, so I'll just concentrate on Lisp." So I switched into working on programming languages.
Doug Kaye: How did a major application or at least a piece of an application written in Lisp ever pass the technical due diligence of the acquirers?
Paul Graham: Well, we had all the users. By the time Yahoo bought us, we were by far the market leader in online store software. So they would've had to… for their techie guys to say, "Oh, no, no we can't buy this because they wrote the thin Lisp," they would have to choose, if they were going to buy some kind of e-commerce software, they would have to buy one of our competitors who wrote their software in maybe a more palatable language, but in fact because of that had far fewer users. So they were forced to make a decision about this.
But I think for Yahoo particularly it was not as frightening as it might have been for other buyers. And the reason was think about where Yahoo came from. Jerry Yang and David Filo, the founders of Yahoo, were grad students in Computer Science at Stanford. Who founded the Stanford Computer Science Department? John McCarthy, the inventor of Lisp. He also was one of the founders of the MIT Computer Science department and he invented timesharing. John McCarthy was one of the big geniuses of early computer science. And so at these very high-end places like MIT and CMU and Stanford, there's a lot of Lisp going around. If you study in the computer science department at some community college in Oklahoma they're going to teach Cobol and Java. But if you go to MIT or Stanford, it's Lisp and ML and languages like that. Doug Kaye: You mentioned Cobol and Java and one of the things you wrote, and I am sure you know where I'm going with this, you referred to Cobol as an evolutionary dead end, a Neanderthal language. Okay, that's fair enough; I don't think you'd get a lot of argument, but you also predicted a similar fate for Java… Paul Graham: Yes. Doug Kaye: …which has got to be one of your more controversial statements. Why, do you believe Java will follow in the footsteps of Cobol?
Paul Graham: Well it was written with the same intentions. I've found looking at programming languages that you can divide them into two classes. There are the languages that people wrote in order to use themselves to write software, and so C is the perfect example of this. Those guys at Bell Labs they wanted to write system software and they need a language to write Unix in, and they made C for themselves. They made that language good because they were the ones who were going to have to eat what they cooked.
If you look at Cobol, Cobol was designed by a committee of smart people, or people who believed they were smart, to be used by dumb people. They were consciously thinking, "We're going to make this language for ordinary schmoes to use," and that's how the designers of Java felt, too. They thought, "We want to make a language that looks familiar like C because that's what lots of users are used to and yet we're going to piecemeal glom onto it some stuff from these more advanced languages like garbage collections and dynamic allocation and stuff like that." So you end up with this: first of all it's a dumbed-down language designed for people not as smart as the designers and it's a Frankenstein language in the sense that they take something familiar and try and stick onto it some more advanced stuff. Doug Kaye: You know, if Java is not going to survive… Paul Graham: Oh, I didn't say it wasn't going to survive. I said that it was going to be an evolutionary dead end, that it's going to have no intellectual descendants. It's enormously popular. Survive? It's the most popular language, it just replaced, you know what, Cobol, as the most popular language. It is the new Cobol. I think Java will continue to be used for a long time and will be enormously popular, but it won't have any effect on programming languages, and when it does die it won't have any…like Cobol, Cobol wasn't replaced by the next Cobol, it was replaced by something completely different, Java, and the same thing will happen in Java. Doug Kaye: What interesting branches in the evolutionary tree are we seeing developed today?
Paul Graham: I think Perl is actually very interesting. I have some reservations about Perl but I look at it and I think, "Wow that's an interesting idea." They have some very interesting ideas in there and the language has a lot of stuff in it that's broken but that's because they are trying to do new stuff. I admire that.
Doug Kaye: Following in the genealogy of languages you've got a new project. You're working on a language called Arc, which I admit I know nothing about. Tell us a little bit about Arc, why you're doing it and what it's going to look like. Paul Graham: It's a dialect of Lisp. One of the unusual things about Lisp is that it has dialects and that's because of something about its design. Lisp's definition is a language that it has these seven axioms and out of those seven axioms you can make all the rest, so anything that has these seven axioms is a dialect of Lisp. So it is a dialect of Lisp like common Lisp and Scheme. There hasn't been a new dialect of Lisp for a long time. The most recent was Common Lisp in the mid 80s and back in the mid 80s a language was a different kind of thing than it is now. Back in the mid 80s, a language was nearly a spec. So that's what Common Lisp is, a specification, and so is Scheme. But now when people talk about a programming language they mean something like Perl or Python or Ruby that's not just a spec, but an implementation with new versions successfully, and some people who are in charge have actually adding stuff to it. So it's going to be a dialect of Lisp, but in the new Perl, Python, Ruby model of what a programming language is instead of the old Pascal/FORTRAN model where it's just a specification written down somewhere. Doug Kaye: What stage are you at with the development of the language?
Paul Graham: Well, I'm at two stages. I have a fairly good implementation of an earlier definition of the language that I actually use to write programs. In fact that's where the whole spam filtering step came out of. I wrote this spam filter in order to make sure this language was actually good for writing programs and the spam filter turned out to be really good. I wrote something about it and a lot of other people wrote spam filters like it. But also simultaneously I'm working on a new axiomatic core of the language. I'm trying to do what McCarthy did in building up a language from axioms the same way Euclid did with geometry, but continue to…all the data structures, I/O, everything you need in the language because in the old original Lisp, McCarthy just built up the core of computation and then handed it to his graduate students and from that point they just took everything else from Algol. Doug Kaye: You mentioned the experiments you've done with spam filtering. Why don't you talk a little about that, tell us what you've learned and where you think that's all heading. Paul Graham: Well, I don't think it's heading in any very different direction lately. What I learned is that a very very simplest statistical algorithm ends up being very good at spam filtering and this is a huge surprise to me. The simple statistical algorithm that I wrote first, I wrote because I always try and write software by writing the simplest possible things first and then gradually add features to it. This is supposed to be just a version 1 and I thought that I would have to use something much more complicated to filter spam effectively. But when I tried it out on my accumulated spam, which I think then was the pathetically small amount of 4000 spams--I get that in about two days now--I found it could filter out 99.5% of it. I was astonished. So I immediately sat down and wrote something, a plan for spam actually--it's in the book--that talked about how this filter works and why I thought it was a good bet for the future and within days people were writing open source implementations of this algorithm. Doug Kaye: And is it your sense that from what you see that's the current best solution to spam? Paul Graham: Yes, in fact most spam filters now including the ones at AOL and Yahoo Mail and probably Gmail, too, all use some variant of this algorithm. I knew Google was up to something a year ago when I did a search for Bayesian on Google and I got a help-wanted ad from Google itself. So I'm pretty sure Google spam filter works this way too. They'd be stupid not to. Thank God, despite spamers very vigilant efforts to try and get around these filters in the last year or so, they still work because I am constantly worrying that spamers will figure out same way to get around Bayesian and filters and then everyone will hate me for wasting all their time sending them down this ultimately mistaken path.
Doug Kaye: Back to Arc for a moment, if someone is interested in following your work, are you publishing it online these days?
Paul Graham: There's nothing on the web about Arc, because I resolutely avoid being in the situation where people always asking me, "So what's new, what have you done last month?" So if people are interested, they can go to my website and there's an e-mail address they can send an e-mail to and I'll tell them when something is ready and usable. But until there's something ready to use I'm not going to put progress reports on the web. Doug Kaye: Do you have a sense of when that might be though?
Paul Graham: Well, you know it could be years because Lisp itself was invented in 1958, so I feel like people have waited over 40 years for a really good Lisp implementation and I don't mind if they have to wait for another two in order to make sure that it is actually really good. Doug Kaye: Well Paul, I think I speak for many people that we look forward to the ultimate announcement of Arc whenever that may be. Thanks for speaking with me today Paul.
Paul Graham: Thank you.
Doug Kaye: And thanks to all of you for listening to IT Conversations. This edition was recorded on July 13, 2004. My guest had been Paul Graham. You will find his personal website at www.PaulGraham.com. My name is Doug Kaye and I hope you'll join me next time for another edition of IT Conversations. This interview and many others are provided by ITConversations, please visit their website at http://www.itconversations.com
