Slashdot Mirror
Paul Graham: Hackers and Painters
larsberg writes "Another wonderful article from Paul Graham on hackers, their lifestyle, and their tools. It's entitled "Hackers and Painters", and provides a great description of how the great hackers write code. The article is definitely worth a read, especially for those who have an inkling that any field that has to place the word "Science" in its name probably isn't really a science after all."
So, he's saying Political Science isn't Science?! No wonder everyone looks at me funny when I wear a lab coat around the office...
May 2003
(This essay is derived from a guest lecture at Harvard, which incorporated an earlier talk at Northeastern.)
When I finished grad school in computer science I went to art school to study painting. A lot of people seemed surprised that someone interested in computers would also be interested in painting. They seemed to think that hacking and painting were very different kinds of work-- that hacking was cold, precise, and methodical, and that painting was the frenzied expression of some primal urge.
Both of these images are wrong. Hacking and painting have a lot in common. In fact, of all the different types of people I've known, hackers and painters are among the most alike.
What hackers and painters have in common is that they're both makers. Along with composers, architects, and writers, what hackers and painters are trying to do is make good things. They're not doing research per se, though if in the course of trying to make good things they discover some new technique, so much the better.
I've never liked the term "computer science." The main reason I don't like it is that there's no such thing. Computer science is a grab bag of tenuously related areas thrown together by an accident of history, like Yugoslavia. At one end you have people who are really mathematicians, but call what they're doing computer science so they can get DARPA grants. In the middle you have people working on something like the natural history of computers-- studying the behavior of algorithms for routing data through networks, for example. And then at the other extreme you have the hackers, who are trying to write interesting software, and for whom computers are just a medium of expression, as concrete is for architects or paint for painters. It's as if mathematicians, physicists, and architects all had to be in the same department.
Sometimes what the hackers do is called "software engineering," but this term is just as misleading. Good software designers are no more engineers than architects are. The border between architecture and engineering is not sharply defined, but it's there. It falls between what and how: architects decide what to do, and engineers figure out how to do it.
What and how should not be kept too separate. You're asking for trouble if you try to decide what to do without understanding how to do it. But hacking can certainly be more than just deciding how to implement some spec. At its best, it's creating the spec-- though it turns out the best way to do that is to implement it.
Perhaps one day "computer science" will, like Yugoslavia, get broken up into its component parts. That might be a good thing. Especially if it meant independence for my native land, hacking.
Bundling all these different types of work together in one department may be convenient administratively, but it's confusing intellectually. That's the other reason I don't like the name "computer science." Arguably the people in the middle are doing something like an experimental science. But the people at either end, the hackers and the mathematicians, are not actually doing science.
The mathematicians don't seem bothered by this. They happily set to work proving theorems like the other mathematicians over in the math department, and probably soon stop noticing that the building they work in says ``computer science'' on the outside. But for the hackers this label is a problem. If what they're doing is called science, it makes them feel they ought to be acting scientific. So instead of doing what they really want to do, which is to design beautiful software, hackers in universities and research labs feel they ought to be writing research papers.
In the best case, the papers are just a formality. Hackers write cool software, and then write a paper about it, and the paper becomes a proxy for the achievement represented by the software. But often this mismatch causes problems. It's easy to drift away from building beautiful things toward building ugly things that make m
When you meet someone now who is writing a compiler or hacking a Unix kernel, at least you know they're not just doing it to pick up chicks.
At least he finished with a well thought out and carefully researched conclusion.
That changes my perceptions completely
"Those who cast the votes decide nothing; those who count the votes decide everything." (attrib. Joseph Stalin)
I liked reading this article because lately I've started to work on my drawing skills. It's very humbling to do something I'm skilled at (coding) and then move to something where people can barely tell what I'm trying to draw.
One commonality I've seen so far is that you just have to jump in and do what you can before anyone can help you. Posting questions like "how do I write an OS?" or "how do I draw such-and-such?" will yield theory but not get you far. On your first tries it's going to look like a bunch of scribbles (or spaghetti code that is far from compilable), but you have to put something down for others to critique. And of course coding and art both take tons of practice time. This goes along with just trying and not worrying about the results. If I didn't code unless I was sure each line was perfectly bug free.. well, that's impossible.
I've been working on realistic and anime-style people. Humans are the most rewarding subjects and also one of the hardest to draw, but I wouldn't want to draw anything else. For anyone else wanting to start in this direction, I recommend the PolyKarbon BBS. There are some amazingly talented people there that are very helpful. This site with anatomy books is a good reference. If you have more helpful links, like a newsgroup for new artists (I haven't found any that are good), please post them.
I don't know any real hackers that speak like that either, just the wannabes.
Programming / Hacking is neither and art or a science and yet it is both. If you don't program you probably would not understand, but if you've ever implemented your own b-tree in an application, you'll probably agree. Most likely, whether or not you agree depends on what type of software you have written in the past.
Art and science are probably closer than most people believe. Leonardo da Vinci painted some of the most astounding scenes ever painted; yet, he also studied science, literature, and the Christian bible. Many mathematicians would say that math is an art, heck there are probably some artists that believe art is a science.
Knuth says that computer programming is an art, but I dare you to read his books and claim they are devoid of science.
In short... It's all depends on the application.
10: PRINT "Everything old is new again."
20: GOTO 10
"Perhaps one day "computer science" will, like Yugoslavia, get broken up into its component parts"
This is already the case. There are people specializing in writing comp-sci software (compiler etc...), there all those double-majors who write software for their other degree specialization (software for given domains like geophysical etc...), there are people who specialise on the ergonomic of the GUI, etc....
This isn't that different from people designing a car, a thing that is both functional and can be beautiful. It takes engineer and designer to make a car.
Now don't tell me "I am the creative type", I am writting software, science doesn't apply to me. I once work in a software lab where the lab had been producing software for several decades. One day the person in charge of QA convinced the person in charge of development to bring some quality type tools like cyclomatic analysis (McCabe etc...). A few engineer came up with that argument that they were producing art, that a software couldn't / shouldn't judge them.
Well, they did two things: They ran McCabe against a lot of their software, some that have been in the market for decades, and there was a direct correlation between the "level" the tool was finding and the number of patches applied to the piece of software. Then they analysed code per current programers: The artsy types were writting complex code that the QA dept. kept sending back !!
Conclusion, there is a place for "out there" artsy type to inovated in a small shop, there is a place in ergonomic to write "beautifull software", but a serious piece of software does need some science.
Think about this, how beautifull would a car that looks good but keeps breaking down be ? Doesn't this remind you a lot of the software out there ?
He's not referring to all programming as "hacking". In fact, the article mentions how most of the programmers in the corporate world do jobs that have absolutely nothing to do with his concept of hacking. Hacking has a heavy dose of design on it. In fact, Graham argues that design happens to be more important than the actual implementation, it just happens that the implementation gets done as you design.
On most cases, coding to a design, instead of coding to user specs, restricts the task so much that there is little chance of creativity. That's not Hacking at all. On the other hand, desigining a +100,000 LOC complex, flexible system, designing it's data structures and object relationships, is so much more complex than "grunt coding" that I think it is way closer to architecture than it is to building a brick wall.
If you belive that all design/code is more like building a house than paiting it's just because you've not seen a truly brilliant, innovative design yet. I hope you're lucky enough to see one, or better yet, create one.
anything that requires creativity, and not just observational descovery is an art.
You can do computer science, and you will get a bullet proof system, but it takes a hell of a long time. People arn't that good at science, that why we created computers. code-breaking and missile targeting and the nuke.
thank God the internet isn't a human right.
What a great quote. This is so very true.
Dynamic typing is a win here because you don't have to commit to specific data representations up front. But the key to flexibility, I think, is to make the language very abstract.
From what I've seen, very few people - espessially those with degress in computer science - share my views on programming. This article takes a different approach to it, but it's the same view I have, when it gets down to it. I usually say that when programming, you shouldn't be bothering with types, memory locations, pointers, and other nonsense that has nothing to do with how the program works. Or in other words, the formal 'scientific' aspects of programming.
Most people will disagree with me here, and I've been involved in many arguments over it. My programing language of choice right now? PHP. Why? Because it sucks less than the other choices. It still boggles my mind that C is used to do any high-level programming (ie, anything besides api's to system calls, and writing drivers and kernels). "But it's so much faster" I hear all the B.Sc's saying. And they're right, it does run faster. It also takes ten times as long to code. And ten times as long to find all the strange bugs and buffer overflows that eventually show up as exploits.
Paul Graham hints at it in his article, but there is no good language right now for writing applications in. PHP in itself is a nice language to write, although it's an interpreted language, not compilied. Perl is a bit too messy for my liking (Paul also mentions this when he says he knows people who wrote perl programs and came back and couldn't understand how they worked), although it is quite powerful. Java is nice in theory, but implemented a bit slowly, and it's a bit too scientific, really -- you spend so much time handling exceptions and making sure all your code is very formal.
So what's the answer? I don't know. But it doesn't exist yet, as far as I know. Until then I'll continue running my slow PHP programs on modern "slow" computers. That run at a mere 1.5 GHz.
Speak before you think
Paul Graham is a smart guy. He made millions selling his company to Yahoo. He's written several books on Lisp. He regularly has speaking engagements. And he does practice what he preaches, actually using high level languages rather just bashing away at C++, but still using it for everything, like most people do. He also manages to completely stay away from the usual topics, like Linux vs. Windows. Oh, all right, one more "and": And he has some unpopular opinions, like that of OOP being overrated smoke and mirrors.
That said, his view of what it means to hack is certainly different than what it usually means in geek circles. Actually, I should go further than that: Paul Graham isn't even a geek. Nobody would call Feynman or Dyson a geek, would they? Paul Graham is someone of high intelligence who happens to be applying that intelligence to computer programming (and writing, and speaking, and painting). This is much different from the typical hacker who pounds out C code because he has nothing better to do and revels in the geek traditions of arguing about Linux distributions, Star Trek movies, and yes, posting to Slashdot. In short, Paul Graham is a geek by association, because of what he decided he likes to do, whereas most hackers revel in their own geekiness, pointless and inbred though it may be.
If you really want to pick an analogy, I'd pick carpentry. Not finish carpentry, as that's too artistic on the scale, but rather functional carpentry. For instance, a carpenter with no real experience and no tools can build a table out of what they find lying around. Some tables have four different legs of four different sizes, one's attached by childrens paste, and another with a high strength steel bolt. See most OSS packages for the coding analogue. A better carpenter has a few tools and makes a better structure, giving a more functional table. Better programs stand up well provided you embrace their rigid design criteria. A master carpenter might the best looking table and design it such that he could come back and add drawers later or replace it with a bigger top or taller legs.
Carpentry, like software, is mostly about figuring out what pieces you'll need and how to piece them together. That's the essence of engineering. Those who study traditional engineering disciplines often scoff at the idea of software engineering because it violates the traditional way of doing the engineering before construction. That hasn't always been the case, and even today some software is developed by traditional engineering techniques. That's not an invalid way to do it, although it is more expensive. Software engineers are embracing the engineer-on-the-fly paradigm, and that's a new idea that nobody really knows how to teach.
In carpentry as in software, the engineering and fabrication are distinct and separable. I wouldn't consider it unlikely that in the future software architecture (engineering) will be done by a different group of people than the coding (fabrication). This is starting to show up now with many companies doing their architecture in UML and then sending it overseas for actual implementation.
This has run way longer than I wanted, so I'll stop here.. Just a few thoughts on a slow morning.
Maybe I'm just too old (OK, yesterday was my 40th birthday, so call me a curmudgeon if you want, I've been called worse) but when I started out as a systems programmer, it was fashionable to speak English. Leet-speak doesn't exactly do much to promote ease of communication, does it?
When I have to code in Java (most of the time), I try to keep my applications as short as possible by first developing and testing low level class libraries to support a project - once these are tested, I find it easier to write much shorter application programs that I can tweak easily.
Still, I find Common Lisp to be my most productive language (Smalltalk is pretty good also :-).
-Mark
I disagree. It seems like there is a stigma against the "hacking method" of development in the large software engineering companies. I totally related to the hacking mentality he described, and I have felt (since college) that this is not the "right way" to do things. I learned to hack in jr. high and high school, while college taught me rigorous design and implementation methods. These methods are anti-hacking because they focus on a lot of up-front paper design and process, whereas the hacking mentality involves working out the problem in code on-the-fly and refining over time. It's not unlike roughing out a sculpture in clay and progressively adding detail and changing things here and there as you go rather than working out the sculpture ahead of time.
So the point of this is that he is trying to say that hacking is a legitimate technique that has advantages over the traditional, slower and possibly less flexible, software engineering moethods and he's doing it by drawing parallels to how artists work. I think the truth is that you need a little of both.
Software is obviously not a single subject: it is like language, and can be applied in many different ways.
Let me take a simple example. There are two main ways that people look at the world of problems: they search for the commonality, or they search for the particularity. Now, I would argue that good software is built by finding the common patterns and solving those, but that is just the way I make software. Other people I've worked with do the opposite: they focus on hundreds or thousands of individual cases. Clearly we have different types of mind - what I consider mindless and irrelevant detail is to my colleagues the only part worth solving.
Painters, artists obviously work the same way. So do writers, archietcts, and all creative people, including scientists. There are hacker chemists, and there are the synthesizing chemists.
Personally, I find that the best art comes from using standard patterns in new way: for instance, good photgraphy relies on excellent understanding of light and subject, but every image must be unique. The best science takes the other extreme: determined effort to find the core patterns and understand those. Ten experiments that are each unique are worthless. Ten experiments that give the same results each time are perfect.
Two more dimensions to this, in my experience. First, men and women tend to different approaches when it comes to creating and problem solving. More men like to hack, not because we're taught that but because our brains work that way. Second, with age our minds also seem to change: older brains can understand a depth of asbtraction that escapes younger minds. Software is all about abstraction, unlike science or art, but very much like language. Young geniuses may be able to hold thousands of details in their heads, but they cannot (generally) use them to build large-scale abstractions that work well. Again, the same for writers.
No accident that some of the best programmers ever are also linguists and writers.
Sig for sale or rent. One previous user. Inquire within.