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."
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
You are either trolling or you are confused between what a hacker does and what a cracker does. My guess is the former, but I'll give you the benefit of the doubt.
Hacker: writes code, likes to write neat code, usually of a functional nature
Cracker: breaks into systems.
I know, I know...the media long ago hijacked the term 'hacker' to refer to both sets of activities. The article in question uses the correct definition of the term though.
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.
Is at The Pragmatic Programmers web site.
Actually, Art History is filled with that (without the 1337 speak, of course). Read Vasari's Lives of the Artists, for instance.
If you find a copy of the Jargon File before ES-"raving lunatic"-R took it over, you'll see that it defines hacker to mean "one who breaks into systems" without any sort of warning about incorrectness. It is only when ESR took over that suddenly this became "strongly deprecated".
I can't remember whether that version even had an entry for cracker in it. But don't take that as an implied assertion that it didn't.
Admitedly I haven't RTFA but ...
And when you RTFA, you'll realize that your comment has nothing whatsoever to do with the article.
that is being addressed partly by the research and practice of agile methodologies. The idea is to change the focus of software development to a new set of principles (for example favoring running software over documentation).
There is also a problem with the way that many managers and business people view software creation as a construction or engineering process. I wrote a paper about this: "The Software Construction Analogy is Broken". The summary is that software has so many attributes that are unlike physical things that its creation cannot be accurately mapped to the creation of buildings. For example, the economics of distribution are completely different: a building cannot generally be moved after it is constructed, yet software can not only be moved, but also can be duplicated for almost zero cost.
Ultimately, I think that software creation is actually the creation of completely new media of communication. Every program created defines a new set of communication interactions that didn't exist before. We don't really have any "science" for that.
Helping with organizational effectiveness is our job.
However long lines of text go against fast reading... some 10 words per line is about the optimum for small eye movement and leverage of whole paragraphs comprehension by a single plank of your eyes...
when I maximize my browser in my 21'' monitor, it's always because the huge left menubars webmail sites have, but I ususally let open the history sidebar on my phonix/firebird, it makes for a good bookmark and makes sites easier to read [note]
best regards
Note: except when I open about 30 tabs in a single window, usually when googling, then I need all the space I have for the tabbar... I think that what NetCaptor does (several lines of tabs) is actually neater, even if it fiddles your vertical space for reading (i hate frames, the upper frames with banners also take much of the vertical space for fast reading.... :(
Leet speak is a trick which can be used to get around filters and to avoid showing up in search results. Googling for "dope" won't find "d0pe" and "fu<k" isn't blocked by a 7-words-you-can't-say-on-tv filter.
"Just once, I'd like to meet an alien menace that wasn't immune to bullets." -- The Brigadier, Dr. Who
> Personally, I love LISP.
/usr/bin (Python, Perl, TCL or whatnot.) Clisp has a C interface (like most other Lisps, including the ones above) which lets you link to any shared/static library which has a C interface (almost all Unix software.)
Amen to that.
> If only there were good UNIX API bindings for it,
> and a good graphical toolkit...
Lisp has good UNIX API and good GUI toolkits. [PUBLIC DOMAIN LICENSE, Native compiler with kickass code-generator.]
Lisp has good UNIX API and good GUI toolkits. [Commercial, free personal use, great IDE and GUI editor, kickass code generator, database, object system, etc, etc. This is the stuff dreams are made of, best development environment I have ever had the pleasure to use.]
Lisp has good UNIX API and good GUI toolkist. [Commercial, free for personal use, relatively affordable, best GUI toolkit (native look and feel on all supported platforms.)
If that isn't enough for you. GNU Clisp runs on more platforms than a flaming wazooka. Don't be bothered by the interpreter (most Lisps are compiled btw, and NOT interpreted as legend has it.) Clisp is FASTER than the stuff you find in your
There is also Corman Lisp which is strictly Windows for now. This beast has direct access to Win32 API and COM objects.
- Kumade Khawi
you're confusing weak typing with dynamic typing.
lisp can be as strongly typed as you wish.
you only get the bogus type conversions in languages like C,
(void *)thing
One answer is that it is not fading (too much :-)
There are several fine commercial Lisp development systems and many fine/good free Common Lisp compilers.
You are right though - relatively few programmers seriously use Lisp. This does not bother me in the least. Personally, I always like to use the right tool for a job. Choosing the right tool also involves issues like "can I find a programmer to maintain this code", etc.
I used Common Lisp recently on a commercial product that I developed - I was only planning on selling "shrink wrapped" executables and the algorythms that I used were tricky (for me at least) to figure out - so using Lisp seemed like a good choice.
On the other hand, I make most of my living writing (or getting customers started with) Java server side stuff - using Java and web standards helps insure the value of the resulting project (with source code) over the long haul.
A few months ago, I had to do some tricky coding - I used Smalltalk to get the algorithm right - then rewriting in Java was trivial.
BTW, I enjoy using different programming languages.
-Mark