Hackers & Painters: Big Ideas from the Computer Age

by Paul Graham

But as you become expert in a field, you’ll start to hear little voices saying, What a hack! There must be a better way. Don’t ignore those voices. Cultivate them. The recipe for great work is: very exacting taste, plus the ability to gratify it.

Languages do differ, but it’s hard to say for certain which are best. The field is still evolving.

So it is probably all to the good that programmers live in a post-Babel world. If we were all using the same language, it would probably be the wrong one.

This is just a guess. I may be wrong. My point here is not to diss Java, but to raise the issue of evolutionary trees and get people asking, where on the tree is language x?

It’s because staying close to the main branches is a useful heuristic for finding languages that will be good to program in now.

The reason I want to know what languages will be like in a hundred years is so that I know which branch of the tree to bet on now.

An essay, in the original sense, is something you write to try to figure something out.

think some of the best programs were essays, in the sense that the authors didn’t know when they started exactly what they were trying to write.

What programmers in a hundred years will be looking for, most of all, is a language where you can throw together an unbelievably inefficient version 1 of a program with the least possible effort.

Wasting programmer time is the true inefficiency, not wasting machine time. This will become ever more clear as computers get faster.

Could a programming language go so far as to get rid of numbers as a fundamental data type? I ask this less as a serious question than as a way to play chicken with the future.

The future is pretty long. If there’s something we can do to decrease the number of axioms in the core language, that would seem the side to bet on as t approaches infinity.

Bill Woods once told me that, as a rule of thumb, each layer of interpretation costs a factor of ten in speed. This extra cost buys you flexibility.

I expect that, as with the stupendous speed of the underlying hardware, parallelism will be something that is available if you ask for it explicitly, but ordinarily not used.

Version 1s will ordinarily ignore any advantages to be got from parallel computation, just as they will ignore advantages to be got from specific representations of data.

As this gap widens, profilers will become increasingly important.

Now we have two ideas that, if you combine them, suggest interesting possibilities: (1) the hundred-year language could, in principle, be designed today, and (2) such a language, if it existed, might be good to program in today.

When you learn to drive, one of the principles they teach you is to align the car not by lining up the hood with the stripes painted on the road, but by aiming at some point in the distance. Even if all you care about is what happens in the next ten feet, this is the right answer. I think we should do the same thing with programming languages.

Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot.

When you choose technology, you have to ignore what other people are doing, and consider only what will work best.

This is especially true in a startup. In a big company, you can do what all the other big companies are doing. But a startup can’t do what all the other startups do. I don’t think a lot of people realize this, even in startups.

The survival rate for startups is way less than fifty percent. So if you’re running a startup, you had better be doing something odd. If not, you’re in trouble.

Back in 1995, we knew something that I don’t think our competitors understood, and few understand even now: when you’re writing software that only has to run on your own servers, you can use any language you want.

Our secret weapon was similar. We wrote our software in a weird AI language, with a bizarre syntax full of parentheses. For years it had annoyed me to hear Lisp described that way. But now it worked to our advantage. In business, there is nothing more valuable than a technical advantage your competitors don’t understand.

In business, as in war, surprise is worth as much as force.

I’ll begin with a shockingly controversial statement: programming languages vary in power.

What’s less often understood is that there is a more general principle here: that if you have a choice of several languages, it is, all other things being equal, a mistake to program in anything but the most powerful one.

But in general, for application software, you want to be using the most powerful (reasonably efficient) language you can get, and using anything else is a mistake, of exactly the same kind, though possibly in a lesser degree, as programming in machine language.

By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.)

You can’t trust the opinions of the others, because of the Blub paradox: they’re satisfied with whatever language they happen to use, because it dictates the way they think about programs.

Macros are harder to write than ordinary Lisp functions, and it’s bad style to use them when they’re not necessary. So every macro in that code is there because it has to be.

If you think of using Lisp in a startup, you shouldn’t worry that it isn’t widely understood. You should hope that it stays that way.

Ordinarily technology changes fast. But programming languages are different: programming languages are not just technology, but what programmers think in. They’re half technology and half religion.

The disadvantage of believing that all programming languages are equivalent is that it’s not true. But the advantage is that it makes your life a lot simpler.

So the short explanation of why this 1950s language is not obsolete is that it was not technology but math, and math doesn’t get stale.

The right thing to compare Lisp to is not 1950s hardware but the Quick sort algorithm, which was discovered in 1960 and is still the fastest general-purpose sort.

Programs composed of expressions. Lisp programs are trees of expressions, each of which returns a value. This is in contrast to Fortran and most succeeding languages, which distinguish between expressions and statements.

Lisp looks strange not so much because it has a strange syntax as because it has no syntax; you express programs directly in the parse trees that get built behind the scenes when other languages are parsed, and these trees are made of lists, which are Lisp data structures.

A Lisp macro can be anything from an abbreviation to a compiler for a new language. If you really want to understand Lisp, or just expand your programming horizons, I would learn more about macros.

You can write little glue programs in Lisp too (I use it as a desktop calculator), but the biggest win for languages like Lisp is at the other end of the spectrum, where you need to write sophisticated programs to solve hard problems in the face of fierce competition.

In fact, choosing a more powerful language probably decreases the size of the team you need, because (a) if you use a more powerful language, you probably won’t need as many hackers, and (b) hackers who work in more advanced languages are likely to be smarter.

You can’t let the suits make technical decisions for you. Did it alarm potential acquirers that we used Lisp? Some, slightly, but if we hadn’t used Lisp, we wouldn’t have been able to write the software that made them want to buy us. What seemed like an anomaly to them was in fact cause and effect.

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.

One technique you can use, if the language will let you, is something called bottom-up programming. Instead of simply writing your application in the base language, you build on top of the base language a language for writing programs like yours, then write your program in it.

A really good hacker can squeeze more out of better tools.

The terms “cutting-edge” and “accounting” do not sound good together. But when you import this criterion into decisions about technology, you start to get the wrong answers.

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.

So here we have two pieces of information that I think are very valuable. In fact, I know it from my own experience. Number 1, languages vary in power. Number 2, most managers deliberately ignore this.

What does make a language popular? Do popular languages deserve their popularity? Is it worth trying to define a good programming language? How would you do it?

So whether or not a language has to be good to be popular, I think a language has to be popular to be good.