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
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
Experienced Lisp programmers divide up their programs differently.
As well as top-down design, they follow a principle which could be called