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."
You laugh, but in a networking class I had back in high school, the instructor wore a freakin lab coat. I never did understand that....
I lost my concept of community when my community lost all concept of me.
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 Graham doesn't understand is the distinction between those fiew people who can blend art and science and those of us who work in the trenches every day.
Here's the thing. It's great if you can create huge, scalable architectures from scratch. You have the chance to create art.
But if you're like me, spending days slogging through large codebases with relatively inexperienced developers, you NEED to be engineers. Otherwise, people who don't have 20+ years experience will do whatever they want and call it "art."
You NEED engineering processes (design, QA, etc.) to remain sane. Graham doesn't see this because he doesn't have to.
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.
My degrees (bachelors and masters) are in painting, and I've worked for the last 8 years writing code. I'd say my art background has definately been a benefit.
Art (can) be about seeing overall patterns and relationships between seemingly dissimilar things, as well as about organizing and processing information in a way that gives meaning to it.
Sounds like the skills I use everyday as a programmer.
Shame you didn't RTFA, as your point is explicitly addressed:
I felt it was important to the worth of the article that he actually covered important points like this. Overall, whether or not one agrees with the author's use of the word "hacker" in this context, I as a programmer recognised so many things in this article that I have come to understand and appreciate in the past 30 years of mucking about with these wondrous machines. I was able to think of specific examples from my own experience of every important point made.
YMMV... :-)
Using HTML in email is like putting sound effects on your phone calls. Just say <strong>no</strong>.
Eh, I think the author's main point was that hacking, much like painting, is the creation of something that has been imbibed with the author's creativity. Safecracking doesn't yield any new creations to the world, you just open a safe. It may be an art form to crack a safe quickly and precisely, but I think you're really stretching the definition of art form and blurring it with common slang.
--trb
I am the only Hacker/Painter at my company. All of the other Hackers are Hacker/Musicians.
They act like I am really unusual. Util I read this article I was starting to think I was the only one.
Why are Musicians so common but Painter's not in the Hacker community?
The city is being overrun by a herd of Lucy Liu's.
Programming is as an art as bridge buidling is.
What about this?
Art or no?
www.6502asm.com - Code 6502 assembly or.. DIE!!
Sometimes it's fun to read the slashdot reactions before RTFA. One poster header "painters" and assumes Graham is talking about the Bubba who shows up to cuss and slap cheap paint on apartment walls. Other people assumes he's talking about the code monkeys in the world. The "fun" thing about today is no one listens anymore. Maybe it's just me, but he's not comparing the techniques. He's comparing what makes these people tick. Einstein is one of the great Physics hackers, but he was also supposed to play a mean violin. The wiring that allows people to pull visions out of thin air works in both worlds. Graham isn't saying anything terribly new (at least to me). I was screwing with creating code in Junior High and writing short stories by High School. By the time I was done with college I had a degree in Physics, work in the humanities and published poems and paintings that had been in shows. I've been asked the same question and I always said Physics (or hacking) and the arts back up to each. More correctly the one that can create in Physics/thru hacking is often the same mind that could envision great art. Same mind, different techniques: creation ex nihilo.
the clock on the wall says 4 til 7
i always felt that the most important issue, was not just being a maker, or constructivist, but being professional about my business conduct. if there was one and only one thing i learned it was that a proper presentation of one's self would decide if someone else will pay you to make things for them. after that, its all wine and roses, and blooshot eyes and doing what you love.
The supreme accomplishment is to blur the line between work and play. Arnold Toynbee (1889 - 1975)
"You never want a serious crisis to go to waste." - Rahm Emanuel
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
pg mentions john lions and his supressed Unix tome. this is a great feature article about it, and some (possibly not so anonymous) linux kernel hacker with a really kewl girlfriend.
"You never want a serious crisis to go to waste." - Rahm Emanuel
I came to programming after years of painting (this guy did it the other way around), and have to agree with many of the analogies he draws, i.e. learning by experience rather than intensive studying; designing by code rather than specification; empathising with the user as part of the design process; &c.
Some folks ask me why I don't paint anymore, and I tell them I get my creative kicks writing software. Nice to know I'm not the only one who thinks this way (because you know the management won't understand!).
need a free COBOL editor for Windows?
For me, I thought the article meandered a bit and even outright contradicted itself in places.
To wit:
He espouses how important it is to keep the design fluid and to change it midstream as necessary, even being fast and loose with data types. While that may indulge the hacker in being creative, it also wreaks havoc on one conveniently omitted aspect of software: maintainability. Rare indeed is the code that is written and never touched ageain. I'm sure someone can toss in statistics about what percent of time or effort is invested in the creation of code, versus all the maintenance required in it later...
To ensure you are not shooting yourself in the foot with this method, the hacker/developer/maker needs to devote a certain amount of time in thought and design before beginning to code. If a stumbling block is detected, legitimate thought must be put into how much code must be *undone* and started over to ensure clean code at the finish. Merely exploiting the fact that you have sloppy data types that can be used in multiple ways will only lead to more convoluted (and certainly less intuitive) code.
Another issue that Paul just sort of tosses out as fact is his claim of how most mediums were at their peak "early on", as in "The paintings made between 1430 and 1500 are still unsurpassed.". Now, I'm no art expert, but doesn't painting predate this by several millennia? Wouldn't the use of perspective by the Greeks seem like a monumental echelon above the flat art of the Egyptians? And aren't the Eqyptians to be praised for their realistic portraits relative to cave art? I'm pretty sure that 15th century art only represents generation after generation of gradual improvements. The fact that the artists following that era began to explore more abstract approaches like impressionism, expressionism and whatnot (http://www.quizbowlonline.com/artmovements.html) does not automatically elevate the "realists" to the pinnacle of the medium.
In any case, it was oversimplifications like this that made the premise a little harder for me to swallow. Very valid points were made, but the analogies do break down in a few places...
But I still marvel at how effective Popfile is. Paul has his moments of genius, there's no doubt.
In the Portland, Ore area and like card games? Check out: http://groups.yahoo.com/group/portlandgames/
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.