Читать онлайн «Essays»

Автор Paul Graham

Programming Bottom-Up

Lisp for Web-Based Applications

Beating the Averages

Java's Cover

Being Popular

Five Questions about Language Design

The Roots of Lisp

The Other Road Ahead

What Made Lisp Different

Why Arc Isn't Especially Object-Oriented

Taste for Makers

What Languages Fix

Succinctness is Power

Revenge of the Nerds

A Plan for Spam

Design and Research

Better Bayesian Filtering

Why Nerds are Unpopular

The Hundred-Year Language

If Lisp is So Great

Hackers and Painters

Filters that Fight Back

What You Can't Say

The Word "Hacker"

The Python Paradox

Great Hackers

The Age of the Essay

What the Bubble Got Right

Bradley's Ghost

Made in USA

What You'll Wish You'd Known

How to Start a Startup

A Unified Theory of VC Suckagepad

Undergraduation

Writing, Briefly

Return of the Mac

Why Smart People Have Bad Ideas

The Submarine

Hiring is Obsolete

What Business Can Learn from Open Source

After the Ladder

Inequality and Risk

What I Did this Summer

Ideas for Startups

The Venture Capital Squeeze

How to Fund a Startup

Web 2. 0

How to Make Wealth

Good and Bad Procrastination

How to Do What You Love

Are Software Patents Evil?

The Hardest Lessons for Startups to Learn

How to Be Silicon Valley

Why Startups Condense in America

The Power of the Marginal

The Island Test

Copy What You Like

How to Present to Investors

A Student's Guide to Startups

The 18 Mistakes That Kill Startups

Mind the Gap

How Art Can Be Good

Learning from Founders

Is It Worth Being Wise?

Why to Not Not Start a Startup

Microsoft is Dead

Two Kinds of Judgement

The Hacker's Guide to Investors

An Alternative Theory of Unions

The Equity Equation

Stuff

Holding a Program in One's Head

How Not to Die

News from the Front

How to Do Philosophy

The Future of Web Startups

Why to Move to a Startup Hub

Six Principles for Making New Things

Trolls

A New Venture Animal

You Weren't Meant to Have a Boss

Programming Bottom-Up

(This essay is from the introduction to On Lisp. The red text explains the origins of Arc's name. )

It's a long-standing principle of programming style that the functional elements of a program should not be too large. If some component of a program grows beyond the stage where it's readily comprehensible, it becomes a mass of complexity which conceals errors as easily as a big city conceals fugitives. Such software will be hard to read, hard to test, and hard to debug.

In accordance with this principle, a large program must be divided into pieces, and the larger the program, the more it must be divided. How do you divide a program? The traditional approach is called top-down design: you say "the purpose of the program is to do these seven things, so I divide it into seven major subroutines. The first subroutine has to do these four things, so it in turn will have four of its own subroutines," and so on. This process continues until the whole program has the right level of granularity-- each part large enough to do something substantial, but small enough to be understood as a single unit.

Experienced Lisp programmers divide up their programs differently.

As well as top-down design, they follow a principle which could be called bottom-up design -- changing the language to suit the problem. In Lisp, you don't just write your program down toward the language, you also build the language up toward your program. As you're writing a program you may think "I wish Lisp had such-and-such an operator. " So you go and write it. Afterward you realize that using the new operator would simplify the design of another part of the program, and so on. Language and program evolve together. Like the border between two warring states, the boundary between language and program is drawn and redrawn, until eventually it comes to rest along the mountains and rivers, the natural frontiers of your problem. In the end your program will look as if the language had been designed for it. And when language and program fit one another well, you end up with code which is clear, small, and efficient.