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."
Would you consider any of these people to be scientists or engineers? Does the fact that their art is useful have any bearing on that question? Does the deterministic nature of gravity and paint make them empirical investigators? The average architect probably knows a lot more science than the average hacker.
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
If it evokes an emotional reaction, it's ART!
Using microsoft products evokes a raticaly diffrent reaction then using let's say an Apple product, or a Linux product.
Why would it be insulting for art and science to be the same thing. A good deal of science goes into art, and art into science.
There is no sanctuary. There is no sanctuary. SHUT UP! There is no shut up. There is no shut up.
This is nothing more than one of those compare and contrast essays which one has cranked out hundreds by the end of high school. Given any two professions, one could derive the same relationships: e.g.,
"When I finished grad school in blank I went to blank school to study blanking. A lot of people seemed surprised that someone interested in blanks would also be interested in blanking. They seemed to think that blanking and blanking were very different kinds of work-- that blanking was cold, precise, and methodical, and that blanking was the frenzied expression of some primal urge.
"Both of these images are wrong. Blanking and blanking have a lot in common. In fact, of all the different types of people I've known, blankers and blankers are among the most alike."
If Slashdot were chemistry it would look like this:Cadaverine
"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.
Art deals with human emotions, feeling, states of mind[...]
Excuse me, I've seen some pieces of code that are VERY beautiful and emotional. I'm not saying that a programmer and a painter should be grouped together, but there can be some extreme beauty in a piece of code. That's like saying that minimalists aren't artists because I think that a yellow dot on a red piece of canvas doesn't draw any emotions. Other people might look at that dot and see their entire life summed up, and get all teary eyed. Different people get emotional reactions to different things. I can still remember to this day the moment I first saw and understood recursion. I nearly creamed my pants when I read through my first recursive function. That's just one of many emotional reactions I've had to beautiful code.
remember, not everyone thinks just how you do.
This space for rent, inquire within.
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?
Computer Science is as much a science as Physics or Biology. The problem is that "Computer Scientists" rarely, if ever, do actual Computer Science after they get thier degrees.
How many people out there with C.S. degrees have gotten jobs that require them to develop, for example, a new compression algorithm? When's the last time you wrote your own language and a complier to go with it? I'm not saying it never happens, but the reality is that most Computer Scientists wind up being Software Engineers.
I mean, It's important to have the scientific background when being an engineer. How many civil engineers do you know that never learned static-state physics? But developing software systems is no more a science than designing cars or buildings. It's applied science, which is a different thing.
Where are your observable phenomena?
The data streams in and out of the processor dont count? The output on your screen doesn't count?
Your testable hypotheses?
I think I can make an O(log(n)) algorithm to do blah blah. I think that malloc algorithm A will improve throughput 30% over algorithm B.
Your experimental data?
No data in computers, that's for sure.
Your replicable results?
Nope. No way to copy a computer program. Good point.
I don't need no instructions to know how to rock!!!!
the people who love to code *are* the real hackers.
just because the media coopted the term to mean script-kiddies and crackers doesn't mean the original meaning is lost to the old school.
PG, whatever else you can say about him, is an old school lisp hacker. This can be confusing to people who are too young or uninformed, but I can see why P.G. holds onto the original meaning.
So you hate it when people use the term hacker in its original meaning? How do you think they feel about people using the new bastardized version?
The exceptions and formality of Java are supposed to aid development by making sure you've crossed all your t's and dotted your i's when it comes to error handling and type checking. (emphasis mine)
;-) That is indeed the "strong, static type checking" party line.
You carefully qualified your statement so I won't lay into you
An increasing number of smart people are starting to ask questions about that party line though. They'll try out a dynamic language like Python, and the disaster promised by the static typing advocates conspicuously fails to materialize. For two examples of this, see Are Dynamic Languages Going to Replace Static Languages? and Strong Typing vs. Strong Testing. A lot of other people are leaning this way too in newsgroups and on personal weblogs, and of course a lot of people still believe the party line.
Personally, I'm suspicious of "received wisdom" that's much older then 10 or 20 years, as the static typing claims are; the world has changed a lot since then in a lot of ways, not least of which is our improved understanding of how to build things (i.e., even in non-technological ways).
If hackers are painters, then text editors are the "bowl of fruit" painting. Check freshmeat if you don't believe me. :)
Paul Graham is a well-known Lisp programmer. He didn't beat us over the head with it in his article, but I'm pretty sure that he considers Lisp (Common Lisp, in particular) to be that good language, for yesterday and today at least.
I suppose that it's an acquired taste, but I'm convinced that it's a taste well worth acquiring. Here is a little screed I wrote to explain why I hold that conviction. Graham wrote several articles which tell his reasons. Some which pop to mind are: Beating the averages, Lisp in web based applications and What made Lisp different
By the way, Lisp doesn't have to be very slow. Here is a pointer to a paper which might get you started.
See what I've been reading.