Recently I was discussing the difference between machine code and source code with a visitor, and the turning point of the discussion was the program’s intentionality. Little did I realize at the time that I was talking with a code hacker.

Wikipedia defines a hack in the following terms:

All of the modern meanings seem to be rooted in its widespread use as slang throughout the Massachusetts Institute of Technology (MIT), starting in the 1960s. There, the original meaning of “hack” was a quick, elaborate and/or bodged solution students devised for technical obstacle; it was used with hacker, meaning one who discovers and implements a hack. The word itself comes from the German word meaning “someone who makes furniture with an axe”,[

Although these intuitive notions of “quick fix,” ”temporary solution” and ”work-around” capture the basic idea of a code hack, it raises the more interesting question: What makes a proper piece of work different from a hack? I think we can cite two main features: first, a proper change is made with full knowledge of the context and intentions of the system so that it maintains the original design concepts; and second, the work does not introduce new potential errors and faults.

Program hacks are pragmatic. They attempt to evade program security checks, copyright protections, or user authentication requirements, or to alter the program’s behavior in ways it was never meant to do. As long as the change meets the hacker’s short-term goals, its long-term effects are unimportant, because he takes no responsibility for the program. He isn’t, in other words, creating something for a user community, he’s doing something for himself.

How does this relate to the question of semantics in program code? It means a hacker can make guesses about the program’s behavior without accepting the responsibility of guessing correctly. As long as the change has the result he wants, he’s satisfied, but the hacker makes no claims to have understood all the consequences of the change or how it will affect the future behavior of the program in untested situations.

Intentions relate to constructs, such as programs, in the same way a shop manual relates to a car, or an architectural blueprint relates to a building. Computer programs also require additional documentation, such as flow charts to explain the high level program flow, and design documents, to state the designer’s original intentions for the program. This duality between a specification, such as the shop manual, and the construct, such as the car, reflects the difference between intentions and facts. The car is what it is, and does what it does, and without some additional specification beyond the car itself, it’s impossible to say whether the car’s condition is correct or faulty. Same thing with the program. Without a statement of intentions, the program code can only be taken at face value: it does what it does. The hacker’s belief that he knows what it does and what it’s supposed to do has no supporting evidence. because he doesn’t have the program’s specifications.

But isn’t this exactly like the scientist’s stand in relation to the universe he studies? We don’t have the specifications for the physical and natural laws of the universe. We have to guess at them. And often, engineering and technology bases its operation on these guesses, sometimes in ways that risk human life. Engineering examples such as the Tacoma Narrows bridge in Seattle, alias “Galloping Gertie,” which wsa destroyed by harmonic oscillations, document the cost that these erroneous guesses can have.

In any philosophy of science, we have to take account of its nature as a hack. We do it for practical and pragmatic reasons, because even the hacks are better than total ignorance, but society is well advised to treat science and technology as the hack it is, and exercise caution. This warning comes at a time when we are beginning to use genetic and brain sciences to tamper with our basic nature as human beings.