The Hack as FormMany people unfamiliar with computer programming equate the word "hacking" with breaking into computer systems in order to steal information. Even the Oxford English Dictionary defines it as "an act of gaining unauthorized access to a computer system," from the Dutch or Swedish: hak, notch.[1] To programmers, however, the term hack is a word with "an extremely subtle and profound [meaning] which defies articulation."[2] It can also be (and this is possibly where the technical meaning arose) a kind of creative practical joke, especially one involving technology. In programming parlance, 'hack' generally means one of two things: a piece of code that solves exactly its given problem, if not aesthetically; or a very good piece of code. In short, the hack is "an appropriate application of ingenuity."[3] Most people don't see the code behind the software they use. For the people who do, the hacks are the places where the code solves a particularly difficult problem, even if the code is not pretty, or places where the code is aesthetically pleasing. Aesthetically pleasing code is well laid out, easy to read, and easy to maintain. These hacks are obvious to the trained eye, as a trained painter would notice good work from another artist.[4] Generally, hacks of the first kind are labeled with comments by the programmer, to describe why the hack was required. Even the same programmer rereading a hack can be unclear as to why the hack was required without an explanatory comment. If you ask those who are involved in software engineering or the teaching of programming, they refer to 'a hack' only as a bad piece of code. They focus on repeatability and teachability, two adjectives which do not apply to the hack, and to which I will return later. In this way, the hack is similar to the status of the essay, a topic Theodor Adorno has touched on in "The Essay as Form." In it, he argues against the prejudice that he reads against the essay in his native Germany: "The essay form has not yet, today, traveled the road to independence...from a primitive, undifferentiated unity with science, ethics, and art."[5] Adorno, by contrast, feels that the essay is an important literary form. The term “essay” comes from the French essayer, to attempt or try. Michel de Montaigne was the first to write essays, writing in the 16th century. They are personal, non-fiction works which are often shorter than other non-fiction works. There are various kinds of written essays: the personal essay, which is a short work which relates to the personal life of the author; and the academic essay, which is more argumentative, are two cases. The essay has also become popular in schools as a way to verify student's knowledge, but the five-paragraph essay I learned in high school (introduction, three body paragraphs, conclusion) bears little resemblance to other kinds of essays. The essay is a personal argument from the author's point of view. There is no topic that the essay is restricted to; essays have been written on every conceivable topic. Since the content is so varied,,there must be a common form that links all of the works called ”essays.” In Adorno's elucidation of the form of the essay, he makes many points that also apply to the form of the hack. The name itself speaks to the form the hack takes. 'Hack' in the typical sense means a rough, irregular cut. That almost perfectly describes a first pass at a hack. The code is rough and irregular, and a cut out of the full problem. As a verb, it means either rough, irregular cutting or the breaking up of a surface. This 'breaking up' is what the hack attempts to do to the system of computer science. It tries to deny the science the possibility of achieving what is assumes to be true, namely that all knowledge about computers can be subsumed into the science. Despite this denial, the hack is always situated within computer science. A hack is always within a larger program, and no number of hacks can remove coding from the field of computer science. Unlike the essay which can be a stand-alone work, the hack is always part of a larger program. What I will argue here is that the hack is also an important part of a program. Early on, Adorno brushes by the theme of play in the essay, only saying that play is "essential"[6] to the essay. This is not play in the sense of one playing a game of chess, but instead in the sense of experimentation. The importance of play to the hack is so great that I must dedicate more space to it. Many – if not most or all – hacks come from “playing” with the computer. Modern computers are complicated enough that frequently the only way to decide how the computer will behave is by experimenting. Play is so important to the hack that one of the other tenses, ”hacking,” indicates just this sort of playful experimenting with the computer. The form of the hack, therefore, must be conducive to this playfulness. It imposes only the smallest restrictions, those necessary for the computer to interpret the code. The upper limit is only the imagination of the hacker. Since computer code has only one interpretation (the computer's), a science has developed to generalize what has been learned about programming. Computer science explores what the computer is capable of doing, and within that, studies how programmers can instruct the computer. The hack sits within this science, as it is manifested in code. But it is at the edge, far closer to art than to computer science.
This clearly outlined goal solves one of the problems that the essay has. Adorno writes about the 'bad essay;' part of the blame rests with the essay's form. The form allows the writer to "grind down" good works into bad.[8] The essay can be edited until all the qualities that made it easy to read, well argued, and coherent are gone. This editing is not possible with the hack. It does not allow itself to be ground into java. The hack is more beautiful, or at least more precise, than regular code. Regular code can be used to solve simple problems, problems that have been solved before, but it cannot be used to solve complicated problems. Those require the application of ingenuity: a hack. Removing the hack's parts, or rewriting it, does not make it a bad hack. Hacks may be edited into bad code, but that make the code no longer a hack. There can be no negative moral judgment of the hack. Programmers sometimes label hacks as bad. But this is not a judgment of the quality of the hack, but of the content. In the Linux kernel, one of the programmers labeled a hack as awful:
This hack is labeled awful because the casts (the parts in parenthesis, which change the type of the variable to their right) are unaesthetic; they are there to get around a requirement of the language. The programmer has to include them so that the program runs, but they do not add anything to the meaning of the code. Computer science tries to pass just that kind of judgment on the hack. The hack does not fit into the carefully scripted world of science. Computer scientists feel that the hack is unnecessary, as all problems can be solved by the application of general principles, generic structures and algorithms. However, this view implicitly assumes that all knowledge necessary for solving problems can be included within computer science. The hack is a proof that the field cannot include all knowledge. The essay "does not try to see the eternal in the transient and distill it out; it tries to render the transient eternal."[10] Neither does the hack. Each hack is a rendering of some transient problem into eternal code. Programs remain in use longer than their programmers ever intend. Even though other programming languages are faster and easier to use, companies still have programs running that were written in the 1960s. Computer science collects the transient problems and tries to find the underlying generality so that the similar problems can be solved in the future. In general, this is not a problem. Trying to simplify work for those who would come after is a noble goal. But not all problems can be solved by the application of general principles. In fact, every problem that has not been solved requires at least some creativity on the part of the programmer. The hack does not play by the rules of the science; the hack does not require that the solution be general, nor does it require that it be easy. Its main requirement is that the problem be solved at the end. After that, the code can be as beautiful and well-formed as a painting. Or, it can be ugly and useful only for the problem it solves, like a garbage truck.[11] Either is acceptable and the better the programmer, the more beautiful the code will be. The hack is an embodiment of intuition, of experience. The hacker knows that each problem is different and that each needs different solutions. The hack requires that its author think and decide how to solve the problem best. This thought comes only with experience and practice with real problems because it is not taught in the classroom. The hack gets its validity through this experience. It cannot and does not rely on the generalized principles of computer science. Adorno writes (referring to the homme de lettres) that it "would not have occurred to anyone to dismiss what such a man of experience had to say as insignificant, arbitrary, and irrational on the grounds that it was only his own and could not simply be generalized in scientific fashion."[12] This is exactly what happens with the hack. Software engineers discard the wisdom of the hack because it cannot be generalized. Professors also disregard the hack, and teach nothing of it to their students. For a student who wishes to work with computer programs, he may go to school to be taught programming. There, he will learn the algorithms and methods that his predecessors have found and used. He will practice on problems that have been solved repeatedly for longer than he has been alive. He may also learn the theory of programming. Instead of working with actual code, he will think about code, model code, analyze code. He will work only with abstract versions of programs. The knowledge he takes away is about control. He learns to control the computer directly, and he learns the theories of that control. The hack denies this control. It is not about imposing the will of the programmer onto the computer. The programmer needs to treat the computer as an equal participant. She needs to convey and idea to the computer, but the code needs to play by the computer's rules. The programs have to be in a language the computer understands, and have to follow the syntax and grammar of that language. Additionally the program can only access the peripherals that the computer has attached. Although the rules are stricter, this is no different than the essay, which needs to be read by a reader. In the same way that knowing one's audience allows a writer to use terms and ideas that he might not be able to otherwise, the hack knowing its place allows it to “get away” with more. But this denial is also its power. By recognizing that it needs the computer, it allows for tricks to be played with the code that would otherwise be disallowed. A fictional account of a Real Programmer provides one of the best examples of this kind of trick:
The operations that the CPU uses are all numbered. What Mel was doing was using the operations stored in the program as both operations to execute and numbers in order to save space. Drum memory was small and slow, and so keeping values close to the operations that used them made the program run faster, and left more room for other operations. This is a hack, because typical programming would say that variables must be separate from the instructions. A key computer science concept is abstraction: making objects or functions more abstract, making them applicable to more data. When programmers name the CPU operations, instead of directly using the numbers, it is a kind of abstraction. “Abstracting away details” is a common goal, of moving details into other functions so that programmers only need to work about the more abstract interface. The higher the level of abstraction, the easier the code is to write and the less the programmer has to think about what is actually happening in the code. This is almost an antithesis of the use of the hack, the existence of which is tied up in the details of how the code functions. The hack relies on the programmer to keep track of the various details around how the code will run. This is different from detail in the typical software sense, which means the specifications for the software. That sense of detail assumes that it is possible to specify beforehand what the program will need to do. Experience shows that this is not possible. Requirements change, and specifying all the details beforehand only means that the problem solved at the end is not the same as the problem at the beginning. Some level of specification is required to manage a software project. The programmers need to know what kind of application they are writing, what programming language to write in, and what features are needed. However, more specification is often done. The different objects and functions can be specified, or what parts of the project each programmer will be responsible for. Specifying the objects and functions ahead of time is also describing how the problem will be solved, limiting what the programmers can do. The computer, however, does not require these specifications. The hack counters them; it "thinks conjointly and in freedom about things that in" its problem.[14] The specification outlines the relevant aspects of the objects involved in the problem. The hack can interact with the objects as a whole, and use whatever aspects it deems necessary. The point of the specification is to make the problem easy enough to solve that even mediocre programmers can solve it. But a level of intelligence and experience are necessary to create hacks, and it shows: the solutions of expert programmers are quicker and more elegant. Mediocre programmers depend on the specification. Like inexperienced cooks, mediocre programmers need much more explicit instructions in order to complete tasks. Experienced programmers can solve problems on their own, without the structure of a specification. Additionally, they can use their experience to write their code in tune with the problem. An early specification often doesn't give the best structure for the project, since how the project will develop is not known. When an experienced programmer creates the structure as he needs it, that structure is more adapted to the problem at hand. However, an early specification can help to keep multiple programmers working towards a common goal. Agile Programming, for example, uses 'stories' (how hypothetical users would use the software) instead of features as a way to focus development in the way an early specification would, but without the code structuring aspects. Working against structure is only one way in which the hack works against the system of computer science. The hack denies the very existence of a system of computer science. The point of computer science is to collect general solutions to problems. But the hack focuses on immediate problems. It puts a premium on thought, on thinking about the code that is being written now. Computer scientists like to plan out their code beforehand so that there are no surprises when the code is written. Hacks revel in those surprises, for it is there that most creativity is required, that the interesting code is written. When the computer or other software does not work as one expects, often a hack is required. The playful nature is key here, for it indicates a willingness to be surprised by results. There are two different kinds of surprise in programming: happy surprises and frustrating ones. Frustrating surprises happen when the computer (or other software programs) does not do what you expect, an experience every computer user is familiar with. These frustrating surprises mean that there is a problem the programmer will have write code to work around, making the code more complex. The happy surprises are those that happen when the computer does something exactly right, or you discover a previously unknown ability. These surprises allow the code to be better organized and cleaner. If there are more happy surprises, the code is more likely to take the form of a hack in the first sense. The programmer can use the new abilities to cleverly make the program better. Otherwise, the code will become convoluted, working around bugs in other places, and be riddled with hacks in the second sense. The essay has a similar advantage with regard to surprises. Unlike scientific writing (which knows where it's going before it begins), the essay follows its own path. If a surprising idea occurs in the middle, there is nothing stopping the essay from following that new idea. As Adorno notes, the essay "introduces concepts unceremoniously, 'immediately,' just as it receives them."[15] With no pattern to follow, the essayist can write down the path of her mind, and we as readers can follow it. Similarly, the hack can give to the computer code the thought paths of the programmer who wrote it, as if the computer were running inside his head. A freedom to create is essential to the hack. A hack cannot be forced, any more than a great work of art can be. The programmer needs to be able to experiment with the code, to see what works and what doesn't. It does not emerge, fully formed, as a solution from the mind of its maker. Instead, it is an iterative process, by which it slowly becomes more correct. Like an essay being edited, the hack approaches the solution as it gets reworked, tested, and reworked again. Without the freedom to rework the code as necessary, a hack is as impossible as a perfect first draft. That freedom does come with a disadvantage, which Adorno writes about in relation to the essay. "It has to pay for its affinity with open intellectual experience with a lack of security that the norm of established thought fears like death,"[16] he writes. Computer science also fears that open experience; it wants well-documented code, well-defined interfaces, code that another programmer could easily come in and maintain. A hack can be maintained, but because it is so specific, it is more difficult than maintaining other code. Computer science is also fearful because if an open experience can generate code that is better than theirs, then the time spent finding data structures and algorithms has all been for naught: what are those structures and algorithms for if not use by programmers? But the security of having a ground to fall back onto, of having decades of experience, is hard to give up. The programmer must have a strong faith that the hack is the appropriate solution and the experience to pull it off. This is another reason that hacks are labeled as such with comments as such: the documentation gives a public reason why a hack was chosen instead of a more common approach. The hack does not have a given structure: it creates its own based on the problem. One of the side effects of working on the fringes of science is that it is harder to use the structure that science provides. Sciences structure the results that are possible within them. Thomas Kuhn, a former professor at MIT, called this structuring a paradigm: a set of beliefs, theories, and values believed by a set of scientists. These beliefs allow scientists to work and give them a way to communicate among themselves. However, it also limits the results they are willing to accept. When experiments create problems for the paradigm, the problems are ignored until the paradigm shifts, incorporating solutions to the problems but creating new problems as well.[17] Computer science has paradigms, and they have created many different patterns into which code can fall. Although the patterns are often useful in general, they are rarely useful to the hack. Solving a problem in a new way usually means that the old ways of solving the problem were not working. Since the hack does this almost by default, it must create new structures that work with the patterns it creates while solving the problem. For example:
|