Paul Graham: "Design and Research"

Paul Graham, Design and Research , January 2003



Hackers and Artists , chapter 15

Design and Research

Thanks for the translation knagaev

')

(This article basically contains a programmatic report on the NEPLS in the fall of 2002)



Visitors to America are often taken aback by the manner of Americans starting a conversation with the question “What are you doing?” I have never loved this question. I very rarely heard a decent response to it. But now I think I solved this problem. Now, if someone asks what I do, I look him straight in the eye and say "I design a new Lisp dialect ." I recommend this answer to anyone who does not like being interested in what they are doing. The conversation immediately turn to other topics.



I do not think that doing research programming languages. I'm just designing one of them, as someone can design a building, or a chair, or a new font. I'm not trying to discover something new. I just want to create a language that will be good for programming on it. To some extent, it makes life so much easier.



The differences between design and research are similar to the opposition of the new and the good. The architectural solution should not be new, but should be of high quality. The results of the study do not have to be correct, but must have a novelty. I think that these two ways converge on top: the best design is superior to its predecessors based on the use of new ideas, and the best research solves problems that are not so much new, but actually worthy of a solution. So, ultimately, we strive for one thing, just move from different sides.







Today I want to talk about what your goal looks like on the other hand. What do you do differently when you consider a programming language as an object of design, and not as a topic for study?



The biggest difference is that you focus more on the user. Design begins with questions: for whom it is done and what do they need from it? In particular, a good architect does not begin by creating a solution that is then forcibly hung on users, but by examining likely users and assessing their needs.



Please note, I said "their needs" and not "their wishes." I do not intend to create the impression that the work of a designer means working like a quick bake in haste of everything that only the client does not wish.



“The buyer is always right” has the meaning that the design is only as good as the user’s work. If you wrote a novel that bored you at all, or made a terribly uncomfortable chair, you worked badly, period. You are not at all excused by the fact that the novel or chair is designed taking into account the most advanced theoretical principles.



And yet the development of what suits the user does not at all mean doing what he tells you. Users do not know all the possibilities, and often they are mistaken what they really want.



The solution to this paradox, in my opinion, is that you have to design it for the user, but design what he needs, and not the Wishlist he talks about. This is very similar to treatment. You cannot treat the patient for only the symptoms. When a patient tells you about his symptoms, you have to figure out what is wrong with him and cure it.



Focusing on user requirements is one of the principles on which most of the techniques of proper design are based, and around which most problems are concentrated.



If the right decision has to meet the user's requirements, then who is this user? When I say that design should be for users, it does not mean that a quality project is aimed at the lowest common denominator. You can choose any user group you want. If you develop, for example, a tool, you can design it for anyone, from beginners to experts, and what would be a good solution for one group may be unacceptable for another. The bottom line is that you must select a specific user group. I think that you do not even have the right to evaluate bad design or good, except with respect to some hypothetical user.



Most likely, you will achieve a good solution when the designer himself will be included in the group of target users. When you develop something for a group to which you do not have a relationship, it usually turns out that you consider these people to be simplified compared to yourself.



This is a difficult situation, because, looking at his user down, albeit sympathetically, the designer inevitably corrupts. I suspect that very few projects of residential buildings in the United States were developed by architects who were then going to live in them. You can find the same for programming languages. C, Lisp and Smalltalk were created for themselves. Cobol, Ada and Java were created for use by other people.



If you think that you are projecting for idiots, there is little chance that you will create something good, even for idiots.



And yet, even if you design something for the most qualified users, you do it for people. Another state of affairs in the research field. In mathematics, you do not choose abstractions so that people can easily understand them; you choose those that make the proof shorter. I think that this is true for all major scientific disciplines. Scientific calculations do not have to be ergonomic.



In art, everything is different. Designing entirely for people. The human body is a bizarre design, but when you are constructing a chair, it is exactly what you are doing everything for and nothing else. All forms of art should cater to the wishes of the person and his faults. For example, for painting with other similar content, a picture with people will be more interesting than the same without people. And it is not just a historical coincidence that the great paintings of the Renaissance are filled with images of people. If it were not so, painting as an art form would not be so popular.



Whether you like it or not, programming languages ​​are designed for people, and I assume that the human mind is as clumsy and distinctive as the human body. Some ideas are seized by people easily, but some are not. For example, it seems that we have very limited opportunities to work with individual elements. This is what primarily makes programming languages ​​a useful invention; if we could keep a lot of elements in mind, we would simply program in machine codes.



Also note that languages, as a rule, are not a means for writing ready-made programs, but with the help of which programs should be developed. Any artist can tell you that in different situations you may need different materials.



For example, marble is a beautiful and reliable material for decorating ready-made ideas, but it is hopelessly not suitable for working out new ones.



The program, like the proof, is a tree that starts to branch incorrectly and bad branches are cut off. So the quality check of the language will not be how beautiful the finished program looks on it, but how simple the path to this finished program was. The option that provides you with the elegance of finished programs does not necessarily provide an elegant development process. For example, I once wrote several macros with macros full of nested reverse quotes that look like small diamonds, but writing them took hours of disgusting trial-and-error coding, and to be honest, I'm not completely sure that they are completely infallible.



We often act using the look of a complete program to assess a language. It looks very plausible if the solutions of the problem written in two different languages ​​are considered, and at the same time one of the versions of the program turned out much shorter than the other. But if you approach this problem from an artistic point of view, you will most likely rely less on testing in this way. It is unlikely that you want, in the end, to get a programming language like marble.



For example, a huge breakthrough in software development is the top-level interactive environment, which in Lisp is called the REPL environment or the read-eval-print loop. And when such an environment is implemented, it has a real effect on the design of the language. For example, it will not work well in languages ​​where you must declare variables before use. When you just type expressions in an interactive environment, you want to assign x a value and start using it. You do not want to be forced to declare type x first. You can challenge each of these assumptions, but if a language with a top-level implemented environment is considered a convenient language, and mandatory type declarations are not compatible with this environment, then none of the languages ​​that make type declarations mandatory can be convenient for programming.



In practice, to achieve good design, you must become a close friend to your users and remain with them. You need to continuously polish your ideas with real users, especially in the initial stages. One of the reasons why Jane Austen's novels are so good is because she read them out loud to her family. That is why she never indulged her weaknesses and did not fall into aesthetic descriptions of landscapes or pathetic philosophizing. (The philosophy was present, but was woven into the narrative, and not stuck on top, like a label.) If you open an average sample of “literature” and imagine that you are reading to your friends out loud, as if you wrote it yourself, then you will feel keenly what it costs to the reader. .



In the software development world, this idea is known as "The worse, the better." In fact, this concept combines several ideas about the truth of which people are still arguing. But one of the main components of this concept is that if you are developing something new, you should post a prototype to users as soon as possible.



The opposite approach can be called the strategy of Hale Mary (“pass for luck”). Instead of quickly releasing a prototype and then gradually improving it, you can try to create a complete, finished product right away as one long pass with a touchdown. As far as I know, this is a recipe for disaster. This path led to the self-destruction of countless startups during the dot-com bubble. I have not heard of any cases where this approach worked.



Outside of the programming world, people may not realize that the principle “The worse, the better” can be found everywhere in art. For example, in the visual arts, this idea was discovered during the Renaissance. Now almost every drawing teacher will tell you that the only correct technique to get an exact image will not move slowly along the contour of the object, since inaccuracies accumulate and you will eventually find out that the lines do not match. On the contrary, you should sketch a few quick strokes in about the right place, and then gradually improve this initial sketch.



In many areas of art, other materials have been used to create prototypes for a long time. Matrices for fonts that are cut from metal are first drawn with a brush on paper. Statues for casting in bronze are pre-fashioned from wax. Tapestry embroidery ornaments are drawn on paper in ink. Stone buildings are checked on a reduced scale in the form of wooden models.



What made painting with oil so promising when it became popular in the fifteenth century was the opportunity to get the final result from the prototype. If necessary, you could make a rough design, but you were not attached to it; You could clarify all the details and make significant changes in the process of working on it.



With software you can do the same. The prototype does not have to be just a mockup; You can refine it and get the final product. I think that this should be done in all cases where it is possible. This will allow you to take advantage of new insights arising from the development process. But what is very likely, and even more important, prototyping is useful for a positive attitude.



Positive working attitude is a decisive factor in the design. I am amazed at how little people pay attention to it. One of my first art teachers told me: if you draw and you feel bored, your drawing will be boring. For example, suppose you need to draw a building, and you decide to draw each brick separately. If you want, you can do it, but if you get bored in the middle, and you begin to mechanically sculpt the bricks instead of respecting the quality of each, the picture will look worse than if you would just mark them.



Creating something, gradually improving the prototype, is useful for your mood, because it keeps you passionate. In software development, I have this rule: the code must always be working. If you write something that can be tested within an hour, you have the prospect of a quick promotion that motivates. The same is true in art, in particular, oil painting. Most artists begin with a vague outline and gradually draw it. If you work in such a manner, you will never, in fact, dwell in the evening on something that looks unfinished. Indeed, artists even have a saying: “A drawing can never be finished, you can only stop working on it”. This idea is familiar to anyone who has developed software.



Mood is another reason that makes it difficult to do something for an unqualified user. It’s hard to stay interested in something that you don’t like yourself. When creating something good, you should think “oh, this is really excellent,” and not “what a crap; Well, this moron like. "



Designing makes sense as creativity for people. But here people are not just users. The designer is also a man.



Notice, I'm always talking about the "designer", as a specific individual. In order for a design solution to be of any quality, it must be developed under the control of a single specialist. At the same time, it is considered admissible if several people work together in one research project. For me, this seems to be one of the most interesting differences between design and research.



There are cases of collective work in art, but most of them look like molecular compounds, and not like nuclear fusion. In the operatic genre it often happens when one person writes the libretto and the other writes music. In the Renaissance, apprentices from northern Europe were often hired to paint landscapes for background paintings by Italian masters. But this is not a real collaboration. These cases are more reminiscent of Robert Frost's phrase: “behind good fences - good neighbors”. You can glue pieces of good design together, but in each part there must be one master of your individual project.



I do not mean that a good project requires one person to think through everything. Nothing can be more valuable than the advice of a specialist whose decisions you trust. But after the discussion is completed, the final choice remains for those responsible.



Why research can be conducted together, but not design? This is an interesting question. And I do not know the answer. Perhaps when design and research are conducted simultaneously, the best result of the research becomes a good design, and in real life this cannot be done by the co-authors. A huge number of the most famous scientists probably worked alone. But I have not enough data to say if there is a pattern here. It may be just the fact that many famous scientists worked at a time when collective creativity was not yet popular.



But no matter how it is in science, in art real collective creativity is found disappearing rarely. Collective design solutions are synonymous with bad design solutions. Why is this so? Is there any way to avoid this?



I tend to think that no - a good project requires a dictator. One of the reasons is that a good design must be solid, with the same quality of all components. If solutions are an idea that fits in the head of one person, it can also fit in the head of the user.



(still fresh - Paul Graham: “Why Y Combinator?” and Paul Graham: High-tech society )

---

The book "Hackers and Artists"









Another 107+ articles by Paul Graham on Habré.

(Who wants to help with the translation - connect)



If you are interested in getting into Y Combinator and Graham's ideas are close to you, write in a personal, I have a couple of ideas.



Is your startup ready to apply to Y Combinator?