“Do not try and bend the spoon – that’s impossible. Instead, only try to realize the truth… there is no spoon.” – Young Monk, The Matrix

Before entering into a technical discussion about Bitcoin, it’s useful to recall a core concept of computer science that was famously illustrated in the movie The Matrix: there is no spoon. To be more specific, the semantics humans use to describe software are completely arbitrary. Humans rely on these arbitrary semantic specifications to describe software because technically precise descriptions of software are highly complex, non-intuitive, and therefore usually ineffective at helping people understand its emergent behavior.

A technically precise way to describe software is that it is a set of instructions that tells a discrete state machine what to state to take. As discussed in the literature review, software exists because people figured out how to digitize computer programming instructions and convert them into electric signals that can be electronically stored in general-purpose computer memory. The technically precise description of software technology is surprisingly uncommon – many are not aware that computers are 2,000 years old, and instructing computers consisted entirely of kinetic actions involving pulling levers, turning dials, pushing buttons, and plugging wires until very recently. The first programmable, general-purpose mechanical computers didn’t have software. The first programmable, general-purpose electromechanical computers didn’t have software. Even the first all-electric, programmable general-purpose computers didn’t have software. Computer programming required forces acting against masses for more than a century before people figured out how to convert programming instructions into electric signals, and how to design machines that could actually store those programs.

Stored-program, general-purpose computers were so revolutionary and capable that people often forget there was a time when the profession of computer programming didn’t involve what we now call “soft” ware. Society is still reeling from the metacognitive disruption of this invention. Stored-program, general-purpose computers have shown society, time and time again, that many of the kinetic activities humans perform can be converted into electric signals and performed by a machine. The tricky party is figuring out how to assemble these signals in such a way that they cause a computer to behave like we want them to behave. This is such a hard problem that it birthed entirely new fields of science (computer science) and engineering (software engineering).

Today, most computer programming descriptions with which people are familiar (ex. clouds, stacks, languages, functions, for/while loops, containers, objects, microservices, etc) are abstractions – metaphors that computer scientists and software engineers conjure up from their own limited experience and domain knowledge. Why? Because abstractions are extremely useful cognitive tools. They create mental models that help people wrap their heads around phenomenological computer behavior which is far more complex than our weak human brains have the capacity to grasp.

Generally speaking, humans lack the intellectual capacity to understand the immensely complex and counter-intuitive behavior of stored-program general-purpose electric computers, so we use metaphors purely out of cognitive necessity. We also play to our strengths – humans are both master abstractors and master pattern recognizers. One of the most common abstractions that software engineers use is object-oriented design. Software is described as if it were comprised of object so that people can more easily visualize and understand its emergent behavior. After all, the reality with which we are so familiar is comprised of objects, so it makes sense to pretend like software is the same way. This method of software abstraction, which didn’t emerge until decades after people learned how to convert computer programming instructions into electric signals, has become so common and ubiquitous that people have actually begun to metacognitively perceive software as real-world objects (more on this later).

This phenomenon speaks to the skill of software engineers. Their ability to instruct discrete state machines how to behave like objects is so masterful that people have become convinced that software are actual objects. But as the young monk from The Matrix reminds us, there is no spoon. There is only a general-purpose computer equipped with a set of instructions that tell it how to behave like a spoon, which we arbitrarily call a spoon so that our pitiful minds can attempt to understand the computer’s complex emergent behavior.

Just like there is no spoon, there is also no cloud. People just started calling software a “cloud” after software engineers figured out how to program computers to behave like massive-scale ethereal clusters of particles called clouds. There is also no such thing as a stack. People just started calling software a stack after software engineers figured out how to program computers to share the same proximal, topological behavior as a stack. There is no such thing as the container. People just started calling software containers after software engineers figured out how to program computers to share the same uniform, hardened, vessel-like behavior of a container.

There is technically not even that method of communication we call a language. People just started referring to computer programming instructions as languages after software engineers figured out a method for converting electrically-stored computer programming instructions into something that shares the same emergent, syntactic-symbol-meaning-conveyance behavior as written language. As discussed in Section XXX, it took two millennia for computer instructions to evolve from kinetic actions, to machine code, to abstractions perceived as assembly languages, to what software developers now metacognitively take for granted as general-purpose language. Like practically everything else in the profession of computer programming, humans gradually figured out how to describe and perceive the emergent behavior of computing instructions using the abstractions with which they were already familiar: things like integers, variables, words, and even sequences of words. Computer programmers did what humans do best and saw patterns of behavior that resemble what they know.

Alas, there is no spoon. Technically speaking, there is no such thing as integers, variables, and English words present in software; there is only a state machine programmed to take one of two states: true or false. At scale, these machines behave like things we perceive as integers and variables. At an even larger scale, these machines behave like things we perceive as languages and objects. This changing perception is metacognitively rewiring society into believing and accepting that software doesn’t just behave like a language, it is a language; software doesn’t just behave like an object, it is an object. These subtle, almost imperceptible changes in the way that humans perceive computer programs represent major metacognitive leaps in society. The lines separating the real world from the virtual world are blurring. The difference between the universe and the metaverse is becoming more indistinguishable with each passing day.

This is the context from which the topic of Bitcoin should be addressed. Software is only a set of instructions that tells a discrete state machine what state to take. The complex emergent behavior of a computer following those instructions, and the function for which that emergent behavior is utilized, is usually what people describe when they talk about software. And almost everything we use to describe that emergent behavior is not technically precise or accurate. But we do it anyway, because technically precise descriptions of software are demonstrably unhelpful at intuiting its complex behavior. Arbitrary, semantic, and abstract specifications are much more effective at getting large quantities of people to understand the same complex behavior.

Due to their imprecision, arbitrariness, and subjective semantics, abstract specifications are not an ideal basis for comparing differences in emergent behavior between different software, especially different software that happens to share similar (but equally arbitrary, semantic, and abstract) specifications. When attempting to compare the complex emergent behavior of two similarly-described pieces of software, it is far more appropriate to focus on physical and systemic differences. Unfortunately, this concept is often lost on people. Software enthusiasts will proceed to argue about the form and function of software using nothing but semantic abstractions to shape their thinking and formulate their opinions, oblivious to the fact that these expressions are arbitrary and therefore intellectually impotent. Nevertheless, they will use semantic expressions to posture and insist that one kind of software has intrinsic merit over another kind of software, without giving credence to the young monk’s fundamental lesson in computer science: there is no spoon.

When talking about different complex behaviors that emerge from the execution of software, physical and systemic differences are what matter, not the arbitrary semantic descriptions we use to describe that behavior. Arbitrary semantic descriptions have no effect on emergent behavior; they’re irrelevant except for the fact that they’re useful at helping people overcome their struggle to grasp the highly counterintuitive task of programming stored-program, general-purpose computing machines. When challenged, people who don’t understand this will often double down on the descriptive detail of their arbitrary semantic specifications to feign precision or superior technical understanding. This serves only to illustrate their ignorance of computer science and their own metacognition.

A summary of the core concept presented in this section is as follows:

• Core Concept: There is no spoon. There is only a stored-program, general-purpose computer that is instructed to share the same complex emergent behavior as a spoon. Humans use arbitrary semantic abstractions like objects and languages to describe a computer program’s complex emergent behavior because computer programming is too intrinsically complex, non-intuitive, and difficult to understand without metaphors that relate them to what people know. From a metacognitive perspective, this causes people to begin to perceive computer programming instructions as being the same as abstractions they use to describe its behavior. Consequently, society has begun to perceive software as a real-world language. Likewise, society has begun to perceive software as real-world objects.