Original ↗
Technology
Design and Research
paulgraham.com
Technology
11 min read → 45 sec
Programming language design is framed as a user-centered design problem rather than a research problem. The piece argues for designing around human needs, iterative prototypes, and single-person control.
Design aims for what is good, research aims for what is new
Programming language design should start from user needs, not user requests or theory
02 / 12
003
Good design depends on a specific user, and works best when the designer is that user
Good or bad design cannot be judged without naming the intended user group
03 / 12
004
C, Lisp, and Smalltalk were built for their designers
Cobol, Ada, and Java were built for others
04 / 12
005
Users are the measure of design quality, but they often misread what they actually need
05 / 12
006
Designing for users you see as less sophisticated tends to corrupt the design
06 / 12
007
A language should be judged by how cleanly programs are developed, not just finished code
Shorter finished programs can mislead, because elegant output can hide an ugly development process
07 / 12
008
Programming languages are for humans, and human limits on detail shape what makes them usable
08 / 12
009
An interactive toplevel is a huge win, and mandatory type declarations work poorly with it
09 / 12
010
Good design needs constant contact with users, so prototypes should reach them as early as possible
10 / 12
011
Good design usually needs one person in control, because design by committee produces bad design
11 / 12
Read the full source
Design and Research
paulgraham.com
12 / 12
Carouse
Turn any article, video, or podcast into a carousel you can browse in 30 seconds.
Carouse any link