The Master and the Slave
The epistemology of computational terms
A bug in the code
On September 9, 1947, operators working on the Harvard Mark II, an early electromechanical computer operated by the U.S. Navy, were trying to understand why the machine was producing errors. When they opened the hardware, they found the culprit: a moth crushed between the contacts of Relay 70, Panel F. Its body had prevented the circuit from closing.
The operators removed the insect with tweezers and taped it into the facility logbook. Beneath it, they wrote:
“First actual case of a bug being found.”
The word bug already existed in engineering. It had been used before to describe faults and technical disturbances. But the moth remains powerful because it made the metaphor literal. An invisible failure inside a machine suddenly had a body.
This is where computing reveals something essential about itself. When engineers needed to describe abstract processes, they borrowed from the human world. They reached for words shaped by labor, command, obedience, commerce, religion, violence, and hierarchy.
The problem is not that technical language is sometimes offensive. The deeper problem is that technical language does not only describe systems. It helps produce the world in which those systems become thinkable.
Neutral technology does not exist. Every technical vocabulary carries a worldview. The question is not whether technology can escape metaphor, but which metaphors we allow to become infrastructure.
Master and slave
For decades, computing used the terms master and slave to describe systems in which one component controlled another. The master issued commands. The slave obeyed.
At first, this seems like efficient technical shorthand. One device governs another device. One process controls another process. The hierarchy is immediately understood.
But that is exactly the issue.
Why not choose to call it controller and executor, or primary and secondary? Once the architecture is imagined in those terms, other forms of organization become harder to see. Consensus, negotiation, reciprocity, peer-to-peer coordination, and distributed autonomy begin to appear as inefficiencies rather than legitimate design principles.
This is how language becomes infrastructure. Not because a word forces a machine into existence, but because it quietly organizes what engineers consider normal.
The persistence of 'master and slave' reveals more than just a habit; it echoes the Hegelian dialectic. It is an architecture built on ego-driven expectations, projecting a human desire for absolute dominance.
The colors of trust
The same logic appears in the old cybersecurity terms blacklist and whitelist. A blacklist blocked dangerous or untrusted entities. A whitelist allowed safe or trusted entities. For years, this vocabulary circulated through software culture as if it were purely technical.
The replacement terms blocklist and allowlist are not only more socially accountable. They are more precise. A blocklist blocks. An allowlist allows. The function becomes visible without depending on inherited associations between color and value.
One term explains the system. The other carries a cultural residue.
Killing the process
When a program freezes or consumes too much memory, the operating system may stop it. Technically, this means ending a running process and releasing its resources.
But the command line does not call this care, repair, or closure. It calls it kill.
To kill a process is to assert final authority over it. The user does not negotiate with the program. The process is marked as misbehaving, and the administrator executes the command.
Modern interfaces soften this language. Apple gives users Force Quit. Microsoft gives them End Task. These phrases sound managerial. But underneath the polished interface, the older vocabulary remains. There is taskkill.
No one is literally murdering software. A process is not alive. But that is not the point. The point is that system administration is imagined through sovereignty. The machine becomes a territory. Code becomes a population of obedient or disobedient actors. The developer becomes the figure who decides what may continue and what must disappear.
The violence is not in the death of the process. The violence is in the administrative imagination.
The religion of commerce
In the 1980s, Apple helped popularize the figure of the software evangelist. The evangelist was not simply a salesperson. The evangelist converted others to a platform. The task was not only to explain software, but to generate belief around it.
Today, technology evangelists still appear across the industry. Their work is to persuade developers to adopt frameworks, APIs, cloud services, and technical ecosystems.
The word is revealing because it maps religious conversion onto corporate infrastructure. A platform is not only used. It is believed in. Its advantages are preached. Its community is cultivated. Its competitors become heresies. The evangelist reveals something the industry often hides: technology is not sold only as a tool. It is spread as a worldview.
The myth of neutrality
Master and slave. Blacklist and whitelist. Kill command. Tech evangelist. Each term carries an inherited structure. Domination. Purity. Execution. Conversion. Together, they expose the illusion of neutral technology. Computation is not built only from logic, mathematics, and engineering necessity. It is also built from cultural memory.
Changing terminology does not automatically change the world. A system can remove master and slave from its documentation while keeping the same command structure intact. A company can replace blacklist with blocklist while preserving the same politics of exclusion.
But to say “it is only language” is to misunderstand technical culture. Language defines the space of design before design begins. It tells engineers what kind of relation they are building. It tells users what kind of behavior is expected. It tells institutions what kind of control feels normal.
The words do not merely label the machine. They rehearse the social order that the machine may later reproduce.
This matters especially now, as artificial intelligence becomes the dominant metaphorical field of contemporary technology. We already speak of assistants, agents, copilots, alignment, training, hallucination, memory, autonomy, and obedience. None of these words are neutral. Each one proposes a relationship between human and machine before the relationship has been fully understood.
The danger lies in anthropomorphizing a large language model. Words like 'hallucination' grant the machine a psyche, subtly shifting the blame for errors away from the developers' dataset and onto the machine's imaginary subconscious.
If we call AI an assistant, we imagine it as having unquestionable obedience. The future of technology will not only be shaped by models, chips, datasets, and interfaces. It will also be shaped by the metaphors that teach us what those systems are allowed to become.
Neutral technology does not exist. But accountable language might.