Hackers & Painters: Big Ideas from the Computer Age

by Paul Graham

Lisp macros are unique. And believe it or not, what they do is related to the parentheses.

be. What that means is that at least 20-25% of the code in this program is doing things that you can’t easily do in any other language.

Lisp’s power is multiplied by the fact that your competitors don’t get it.

If you ever do find yourself working for a startup, here’s a handy tip for evaluating competitors. Read their job listings.

The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience.

The pointy-haired boss miraculously combines two qualities that are common by themselves, but rarely seen together: (a) he knows nothing whatsoever about technology, and (b) he has very strong opinions about it.

false. The pointy-haired boss believes that all programming languages are pretty much equivalent.

right. Some languages are better, for certain problems, than others.

explode. As long as he considers all languages equivalent, all he has to do is choose the one that seems to have the most momentum, and since that’s more a question of fashion than technology, even he can probably get the right answer.

As a rule, the more demanding the application, the more leverage you get from using a powerful language. But plenty of projects are not demanding at all.

In server-based applications you can get away with using the most advanced technologies,

Surely by now we all know that software is best developed by teams of less than ten people. And you shouldn’t have trouble hiring hackers on that scale for any language anyone has ever heard of.

You can’t let the suits make technical decisions for you.

If you start a startup, don’t design your product to please VCs or potential acquirers. Design your product to please the users. If you win the users, everything else will follow. And if you don’t, no one will care how comfortingly orthodox your technology choices were.

If you’re trying to solve a hard problem with a language that’s too low-level, you reach a point where there is just too much to keep in your head at once.

Technology often should be cutting-edge. In programming languages, as Erann Gat has pointed out, what “industry best practice” actually gets you is not the best, but merely the average.

If you want to win in a software business, just take on the hardest problem you can find, use the most powerful language you can get, and wait for your competitors’ pointy-haired bosses to revert to the mean.

The Dream Language

Programming languages are not theorems. They’re tools, designed for people, and they have to be designed to suit human strengths and weaknesses as much as shoes have to be designed for human feet.

One thing hackers like is succinctness.

The most important kind of succinctness comes from making the language more abstract.

Good programmers often want to do dangerous and unsavory things.

Let yourself be second-guessed.

A really good language should be both clean and dirty: cleanly designed, with a small core of well understood and highly orthogonal operators, but dirty in the sense that it lets hackers have their way with it.

To be attractive to hackers, a language must be good for writing the kinds of programs they want to write. And that means, perhaps surprisingly, that it has to be good for writing throwaway programs.

A throwaway program is a program you write quickly for some limited task:

And so, paradoxically, if you want to make a language that is used for big systems, you have to make it good for writing throwaway programs, because that’s where big systems come from.

programs? To start with, it must be readily available.

Another thing you want in a throwaway program is succinctness.

Of course the ultimate in succinctness is to have the program already written for you, and merely to call it.

I think future programming languages will have libraries that are as carefully designed as the core language.

A friend of mine rarely does anything the first time someone asks him. He knows that people sometimes ask for things they turn out not to want. To avoid wasting his time, he waits till the third or fourth time he’s asked to do something. By then whoever’s asking him may be fairly annoyed, but at least they probably really do want whatever they’re asking for.

So anyone who invents something new has to expect to keep repeating their message for years before people will start to get it.

It’s not when people notice you’re there that they pay attention; it’s when they notice you’re still there.

“The best writing is rewriting,” wrote E. B. White. Every good writer knows this, and it’s true for software too. The most important part of design is redesign.

worry made the work good.

If you can keep hope and worry balanced, they will drive a project forward the same way your two legs drive a bicycle forward.

In young hackers, optimism predominates. They produce something, are convinced it’s great, and never improve it. In old hackers, skepticism predominates, and they won’t even dare to take on ambitious projects.

Prose can be rewritten over and over until you’re happy with it. But software, as a rule, doesn’t get redesigned enough.

Users are a double-edged sword. They can help you improve your language, but they can also deter you from improving it.

So choose your users carefully, and be slow to grow their number. Having users is like optimization: the wise course is to delay it.

Introducing change is like pulling off a bandage: the pain is a memory almost...

it’s not a good idea to have a language designed by a committee. Commit...

Design and Research

And yet, making what works for the user doesn’t mean simply making what the user tells you to.

Users don’t know what all the choices are, and are often mistaken about what they really want.

you have to pick some group of users. I don’t think you can even talk about good or bad design except with reference to some intended user. You’re most likely to get good design if the intended users include the designer himself.

And looking down on the user, however benevolently, always seems to corrupt the designer.

If you think you’re designing something for idiots, odds are you’re not designing something good, even for idiots.

Over in the arts, things are different. Design is all about people.