Rich Hickey Urges End to In-Place Data Updates as Storage Expands
InfoQ
Software architectures must abandon mutable state for immutable values because overwriting records destroys historical facts, forcing enterprises to mine raw operational logs to reconstruct the past.
AI-assisted summary of The Value of Values with Rich Hickey — original source. Check the original for full context.
Source published:
Key ideas
- Place-Oriented Programming (PLOP)—the practice of overwriting memory addresses or database records—is an obsolete paradigm born of hardware constraints from an era before storage capacity expanded a millionfold. (2:01)
- Values are strictly immutable and semantically transparent, aggregating cleanly into larger values without the non-composable locking and cloning policies required by mutable objects. (8:06)
- Facts are inherently historical documentation of what occurred; because the past cannot be altered, updating or overwriting a fact in place is an architectural category error. (20:08)
- The Big Data boom is largely driven by businesses mining raw developer execution logs with MapReduce to recover the historical trends and rates of change that standard CRUD databases destructively erase. (24:27)
Detailed notes
## Background Published on YouTube by InfoQ on October 8, 2012, this keynote speech from JaxConf 2012 features Clojure creator and Datomic founder Rich Hickey. The talk analyzes how modern software engineering thinks about values in light of rising system complexity and the emergence of Big Data.
## TL;DR Rich Hickey critiques the industry's widespread reliance on 'Place-Oriented Programming' (PLOP), where mutable memory locations and destructive database updates repeatedly overwrite information. He redefines genuine information as an accumulation of immutable, semantically transparent values and time-bound facts that document what happened in the past. Highlighting the irony that developers insist on immutable version control and append-only logs for themselves while forcing destructive CRUD models onto business users, Hickey argues that modern hardware has entered a boundless 'Space Age' where new facts should always occupy new space rather than destroying existing data.
## Atmosphere & style The presentation is intellectually sharp, philosophical, and dryly humorous, anchored by Hickey's signature method of consulting dictionary etymologies to deconstruct industry dogma from first principles. Hickey paces his delivery with brisk momentum, guiding the audience through Socratic thought experiments that make standard object-oriented practices feel unexpectedly absurd. Watching it feels like a patient yet uncompromising wake-up call that challenges developers to unlearn decades of obsolete hardware habits.
## Bulletin - [02:01](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=121s) Place-Oriented Programming (PLOP)—the practice of overwriting memory addresses or database records—is an obsolete paradigm born of hardware constraints from an era before storage capacity expanded a millionfold. - [08:06](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=486s) Values are strictly immutable and semantically transparent, aggregating cleanly into larger values without the non-composable locking and cloning policies required by mutable objects. - [20:08](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=1208s) Facts are inherently historical documentation of what occurred; because the past cannot be altered, updating or overwriting a fact in place is an architectural category error. - [24:27](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=1467s) The Big Data boom is largely driven by businesses mining raw developer execution logs with MapReduce to recover the historical trends and rates of change that standard CRUD databases destructively erase.
## Key takeaways - [00:11](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=11s) Software engineering often mistakenly models facts as mutable storage locations accessed via get and set operations, corrupting the true definition of information. - [02:01](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=121s) Place-Oriented Programming (PLOP) defines any architecture where incoming new information overwrites and destroys older information, across both in-memory objects and durable databases. - [04:26](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=266s) In-place mutation made engineering sense when hardware was constrained to kilowords of memory, but persisting with it after a millionfold increase in capacity is unjustified. - [06:12](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=372s) Real-world memory and record-keeping systems—such as associative human recall and double-entry accounting ledgers—are inherently additive and never rely on destructive overwriting. - [08:06](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=486s) Values are defined by immutability and semantic transparency, establishing the comparability necessary for sound programmatic logic and equality testing. - [11:18](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=678s) Programming with immutable values eliminates defensive copying, provides deterministic reproducibility for automated tests, and allows trivial data fabrication without bespoke class hierarchies. - [13:16](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=796s) Object-oriented specificity has failed to deliver promised code reuse, instead producing boilerplate code explosions and increased defect rates by inventing new types for every problem. - [14:23](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=863s) Aggregates of immutable values automatically remain immutable values, whereas mutable objects require manual synchronization and cloning policies that fail to compose across abstraction layers. - [16:15](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=975s) Observing immutable values requires zero coordination or global read locks, allowing safe multi-threaded perception and clean inter-process boundary traversal like JSON or XML. - [20:08](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=1208s) By definition and Latin etymology, a fact represents an event that occurred in the past; because history cannot be changed, facts are immutable values bound to time. - [21:28](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=1288s) Conflating mechanical execution constructs (such as conveyor belts or queues) with the information model itself is an architectural mistake, as place has no legitimate role in modeling facts. - [24:27](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=1467s) Software developers demand complete, immutable temporal histories for their own source code repositories and system logs, yet deny those exact historical capabilities to business users. - [24:27](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=1467s) Big Data mining via tools like MapReduce emerged as an inefficient workaround for businesses trying to extract historical trends from noisy operations logs because primary databases only retained current state. - [27:55](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=1675s) In the modern era of practically boundless memory and cloud storage, information architectures must adopt the principle that new facts always require new space.
## Detailed walkthrough ### [00:11](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=11s) Defining Information and the Myth of the "Fact"
Rich Hickey opens the keynote by asking the audience how many of them work in "IT," joking that it stands for Information Technology or perhaps other things. As with his other keynotes, he consults his dictionary to ground the discussion in first principles. According to the dictionary, "information" derives from "inform," which means to convey knowledge via facts in order to give shape to the mind. Therefore, information simply consists of facts.
```mermaid flowchart TD accTitle: The Misguided Conception of Facts as Storage Places accDescr: Diagram illustrating the erroneous framing of facts as mutable storage locations with get/set operations versus genuine immutable information. subgraph ErroneousView["The Erroneous Mental Model"] P["Place / Location"] -->|"controls change"| O["Operations: get() / set()"] O -->|"overwrites"| F["'Fact' (as mutable storage)"] end subgraph AuthenticView["The Authentic Nature of Facts"] I["Information / Knowledge"] -->|"composed of"| AF["Immutable Facts"] AF -->|"gives shape to"| M["The Mind"] end ```
Hickey then intentionally leads the audience down a garden path by offering an absurd, programming-skewed definition of a fact: he defines a fact as a place where information is stored, complete with `get` and `set` operations that control how the fact can change, where conveying a fact simply means passing its location. Pausing to ask how many people feel uncomfortable with this characterization, Hickey calls out the absurdity directly: “This is not true right this is wrong everything I just said was wrong dead wrong and you should be uncomfortable this is not what facts are right so are facts places?”
[02:01](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=121s) Place-Oriented Programming (PLOP)
Turning back to the dictionary, Hickey notes that a "place" is a particular delimited portion of space with specificity to its named location. Programmers deal with places constantly: memory addresses and disk sectors are physical places with specific addresses whose contents can be replaced with new contents. The critical problem is whether software engineers are actually building systems centered around *information* when they rely so heavily on these places.
In modern programming—particularly object-oriented programming—mutable objects are fundamentally nothing more than thin abstractions draped over memory places. They expose methods, like getters and setters, to manipulate those places. On the persistence and durability side, the exact same pattern appears: database tables, documents, and records are treated as places governed by updates where new values overwrite old ones. Hickey coins an acronym for this dominant paradigm: **PLOP** (Place-Oriented Programming). He remarks, “You can tell when it's going on because anytime new information replaces old information you're doing Place oriented programming.”
- **In-Memory PLOP:** Mutable objects wrapping memory addresses, exposing mutating methods. - **Durable PLOP:** Database tables, documents, and records that implement updates in place. - **The PLOP Indicator:** Anytime incoming, new information overwrites and destroys old information, a system is practicing Place-Oriented Programming.
[04:26](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=266s) The Historical Rationale and the Millionfold Shift
Place-oriented programming was not invented out of malice or ignorance; in the early days of computing, hardware constraints gave developers no other choice. Hickey recalls a talk by Guy L. Steele Jr. describing programming on a machine with a meager four kilowords of memory. In that era, programmers had to know the exact physical address of every instruction and variable: even-numbered addresses starting at 2000 served as jump tables, specific locations held data, and code segments were repeatedly repurposed for data whenever they were not actively executing. Because memory and disks were tiny and wildly expensive, manipulating places in situ made total engineering sense.
However, Hickey emphasizes that the key qualifier is that it *used* to make sense. Over his programming career, hardware storage and memory capacity have grown by a factor of one million. To highlight the absurdity of sticking with primitive architectural patterns despite this transformation, he asks the audience to imagine how few physical rules would still apply if an automobile were suddenly made a million times larger. As Hickey points out, “What other thing in life you know has the same facts about it um remain true when the size of something changes by a millionfold imagine if your car was a million times bigger than it is what rules would still be would still apply what characteristics would still be true almost nothing but yet we're we're retaining decisions we made when things were much much smaller and and moving forward with them.”
[06:12](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=372s) Believing Our Own Myths: Real Memory and Real Records
The terms "memory" and "records" held rich human meanings long before electronic computers repurposed them. In computing, memory was reduced to volatile RAM addresses and records were flattened into mutable slots in database tables. The danger is that programmers have repeated these technological analogies for so long that they have begun to believe their own myths, ignoring how memory and record-keeping actually function in the real world.
Human memory is fundamentally an associative, open system rather than an address-based block of storage. If an acquaintance acquires a new email address, your brain does not locate the specific neurons storing the old address and overwrite them. Similarly, historical record-keeping on stone tablets or papyrus never involved chiseling down marble or applying erasers whenever new facts emerged. In commerce, double-entry accounting ledgers were designed explicitly around append-only operations: bookkeepers never erased ledger entries to fix mistakes; they created correcting entries. Overwriting and erasing are computational artifacts born of hardware scarcity, not reflections of actual record-keeping.
- **Human Memory:** An associative, open-ended biological system, not a grid of fixed address slots. - **Historical Records:** Carved in stone or inked on papyrus; never smoothed over or erased when conditions changed. - **Ledger Accounting:** Relies exclusively on append-only correcting entries to preserve an accurate historical audit trail.
[08:06](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=486s) Redefining Values: Immutability, Comparability, and Semantic Transparency
To steer the discipline back toward genuine information systems, Hickey turns to the core topic of the keynote: values. The dictionary defines "value" first as relative worth, and second as a magnitude, quantity, or number used to measure something else (such as the number 42). While programmers are comfortable with numeric values, the broader and more critical definition centers on comparability and relative worth. Measurement cannot exist in an absolute vacuum; it requires comparing one thing against another.
```mermaid flowchart LR accTitle: The Two Primitives of Values in Programming accDescr: Diagram highlighting immutability and semantic transparency as the foundational properties of programming values. subgraph ValueCharacteristics["Essential Properties of a Value"] direction TB IM["Immutability"] -->|"guarantees stability for"| C["Comparability & Logic"] ST["Semantic Transparency"] -->|"exposes meaning directly"| E["Equality Testing"] end ValueCharacteristics --> Dec["System Decision-Making"] ```
To test the concept, Hickey asks whether a string is a value. The answer depends entirely on immutability: an immutable string is a value, whereas a mutable string is not. Few developers who have worked in environments with mutable strings ever want to return to them. Although a string does not denote a numeric magnitude, an immutable string is directly comparable, and comparability is the bedrock of logic, equality, and sound decision-making. Hickey distills the concept for programming into two fundamental pillars: values are strictly immutable, and values are semantically transparent. Explaining why this distinction matters so profoundly against the backdrop of object-oriented encapsulation, Hickey concludes: “A value is about saying compare me to something else I'm telling you what my what my um what my precise meaning or significant is significance is right on the label right on the outside that's what a value is.”
[11:18](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=678s) Sharing, Reproducibility, and Ease of Fabrication
Rich Hickey moves directly into the core propositions that demonstrate why values are fundamentally good. Because his presentation was originally planned for an hour, he accelerates the pace to outline the characteristics that make values so valuable. The primary characteristic is that values can be freely shared without defensive friction. When working with an immutable entity, one can hand it to another component or thread without worrying about whether it will be modified or corrupted. Because neither side can mutate it, neither party has to worry about the other.
Values are also the foundation of reproducible results. Defining a function in terms of pure values guarantees that invoking it with identical inputs always yields the exact same answer. By contrast, if a function is defined around mutable "places," the result is completely dependent on whatever happens to reside in that place at that particular moment in time. This distinction is critical for automated testing. Hickey criticizes modern software practices where teams write extensive test suites against mutable state, pointing out that such tests fail to provide real guarantees because their outcomes depend entirely on whether the system can successfully reset a mutable place back to a specific prior state.
Values are extraordinarily easy to fabricate out of thin air across any programming environment. A developer can effortlessly construct a string, a list of numbers, a nested list, or a map of lists in virtually any language. Creating an ad-hoc instance of a bespoke, language-specific interface or class hierarchy, however, requires jumping through immense structural hoops. When data is represented as values, writing programs that generate other programs or automatically synthesize tests becomes straightforward.
> “So many people are running tests now of of places they don't tell you anything they don't tell you anything they're all conditional upon your ability to bring that place back to the same place to the same value right” — Rich Hickey
- **Frictionless sharing:** Handing an immutable value to another consumer eliminates shared-state bugs and defensive copying. - **True reproducibility:** Value-based functions behave deterministically, unlike place-oriented functions whose return values depend on volatile state. - **Fabrication simplicity:** Generic literals (primitives, maps, lists) can be instantiated instantly without class scaffolding, enabling metaprogramming and test generation.
---
[13:16](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=796s) Generic Reusability and the Failure of Object-Oriented Specificity
Values are inherently language-independent and generic. The fundamental concepts of strings, lists, numbers, and key-value maps exist entirely independent of Java, Clojure, or any other programming environment. Hickey argues that software engineering often overlooks the crushing costs of specificity. In the object-oriented paradigm—especially within statically typed environments like Java—every distinct idea receives a brand-new class.
This obsession with bespoke modeling produces an explosion of boilerplate code. Hickey notes the historical irony: object-oriented programming was sold on the promise of code reuse, yet it has achieved the exact opposite by incentivizing developers to invent brand-new, isolated types for every single problem. This massive accumulation of rigid, specialized code directly inflates surface area and bug density.
```mermaid flowchart TD accTitle: The Cost of Specificity versus Generic Values accDescr: Comparing how object-oriented bespoke classes multiply bugs compared to language-independent values.
subgraph OO["Object-Oriented Specificity"] O1["New Domain Concept"] --> O2["New Custom Class / Interface"] O2 --> O3["Explosion of Boilerplate Code"] O3 --> O4["Diminished Reuse & Increased Bugs"] end
subgraph Val["Value-Oriented Generics"] V1["New Domain Concept"] --> V2["Standard Generic Aggregates\n(Maps, Lists, Sets)"] V2 --> V3["Broad Reuse Across Systems"] V3 --> V4["Language-Independent Data"] end ```
> “Objects were supposed to support reuse they've done the exact opposite thing especially in typed languages you get very little reuse because you make a new thing every time and what does more code mean more code equals more bugs right away” — Rich Hickey
---
[14:23](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=863s) Value Aggregates and the Composition Breakdown of Objects
A crucial property that developers often fail to grasp is that values aggregate into values. While programmers widely accept that a number like 42 or an individual string should be immutable, they frequently balk at the idea of immutable collections. Hickey stresses that a collection composed of immutable values is itself an immutable value, carrying all the same guarantees as primitive scalars. Since no modern developer would willingly choose to work with mutable strings again, he questions why anyone still tolerates mutable collections.
When dealing with mutable objects in concurrent environments, developers must manually design locking policies and cloning semantics—work that Hickey compares to scribbling rules onto an informal "napkin." The fatal architectural flaw is that mutable locking and cloning policies do not compose:
| Architecture Layer | Values Composition | Mutable Objects Composition | |:--- |:--- |:--- | | **Atomic Elements** | Inherently thread-safe, immutable primitives. | Requires bespoke synchronization and locking semantics. | | **Aggregates / Composites** | Aggregates remain immutable values; all safety rules compose automatically. | Lock policies completely fall apart; developers must redesign synchronization from scratch. | | **Cloning Semantics** | Trivial (no-op or reference reuse; values cannot change). | Ambiguous ("it depends"); expensive deep copies vs. hazardous shallow copies. |
> “This composite of all these things for which I have lock policies now no longer has a lock policy I have to come up with a new one I have to come up with a new cloning policy and everything else over again values aggregate to values all the benefits apply to aggregates” — Rich Hickey
---
[16:15](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=975s) Perception, Memory, and Coordination Across Boundaries
Hickey shifts focus to how systems perceive, remember, and convey information. When conveying an immutable value to someone else, you transmit the exact data you saw. By contrast, pointing someone to a mutable "place" conveys nothing about the underlying information, because by the time the recipient inspects that place, its contents may have altered completely.
The same problem plagues perception. In order to perceive an aggregate composed of mutable places, an application must effectively freeze the world:
```mermaid flowchart LR accTitle: Perception in Places versus Values accDescr: Diagram contrasting locking the world to inspect mutable places versus leisurely observing an immutable value.
subgraph Places["Perception via Mutable Places"] P1["Request Observation"] --> P2["Acquire Global Lock\n('Stop the World')"] P2 --> P3["Read Mutating Memory"] P3 --> P4["Release Lock\n(Risk of Inconsistent Reads)"] end
subgraph Values["Perception via Values"] V1["Receive Value"] --> V2["Read and Reason at Leisure"] V2 --> V3["Consistent Observation Guaranteed\n(Zero Locking)"] end ```
Remembering state presents an identical obstacle: storing a naked reference to a mutable object fails because the underlying data can change underneath you, forcing developers into messy cloning routines. Hickey challenges the audience to think beyond a single process and look at distributed architectures. Across networks, developers have already discarded object-RPC paradigms like CORBA and DCOM in favor of value representations like JSON or XML.
Values eliminate the need for heavy-handed coordination like "read transactions," which Hickey notes violate physical intuition: in the physical world, looking at something does not require stopping time for everything else. Furthermore, programming with values grants "location flexibility"—allowing services, threads, or components to be rewritten in different languages or moved onto separate physical servers without breaking client contracts.
> “In physics we just look at each other we we don't have to stop everything in order to look at things so when we're programming with values and using values especially in storage we again have reduced coordination” — Rich Hickey
- **Perception without coordination:** Observing an immutable value requires zero locks, avoiding the "stop-the-world" pauses mandatory for mutable memory. - **Failures of object IPC:** Complex distributed object schemes (CORBA, DCOM) failed, replaced universally by generic value formats (JSON, XML). - **Location flexibility:** Value-driven boundaries enable shifting execution across threads, processes, and programming languages without altering core semantics.
---
[20:08](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=1208s) The True Nature of Facts: Time-Bound Values
Hickey ties the value proposition directly back to the concept of Information Technology and the definition of a fact. He reveals that treating facts as mutable places was an industry lie. While conventional intuition suggests that facts change over time—such as a country changing its head of state—facts themselves never change, because real facts inherently incorporate time.
Consulting the dictionary and etymology, Hickey points out that the word "fact" derives from a Latin past participle meaning "something that happened" or something known to have existed. A fact represents an event that occurred in reality, not a volatile storage location that can be erased or overwritten. While a country may inaugurate new presidents or a user may register new email addresses, the historical fact that Bill Clinton was President remains perpetually true. Because facts describe what occurred, building information systems that discard past facts in favor of only the most recent state fundamentally undermines the purpose of information.
> “Fact means something that happened something known to have happened or existed it comes from Latin and it comes from a past participle in Latin that means something that happened a fact is something that happened it's not a place it's not something you can change right Bill Clinton was President the fact that he was President will always be a fact” — Rich Hickey
[21:28](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=1288s) Why You Cannot Update a Fact
Information exists to inform people and convey knowledge, but knowledge is fundamentally derived from facts. When humans make decisions, they compare different moments in time, correlate facts, and evaluate changes across temporal baselines. Rich Hickey asks the audience to consider a thought experiment: imagine having to navigate the world knowing only the present value of every property or attribute, with zero memory of what came before. Decision-making under those conditions would be disastrous, yet the software industry routinely builds enterprise systems that do exactly that—remembering only the single most recent overwrite. Hickey points out the fundamental contradiction of calling these systems decision-support infrastructure: “And the reason why you can't update a fact is because you can't change the past and that's what facts are: they're documentation of the past.”
True information systems must be fundamentally about maintaining, manipulating, and presenting facts to provide real leverage to human decision-makers. While programming languages legitimately need process-oriented constructs to orchestrate execution, developers conflate those operational mechanics with information modeling. Programs naturally have parts that act like little industrial machines—with loading docks where data arrives, conveyor belts that transport it, and sorters that route pieces to different bins. While building machine-like language constructs is useful for running workflows, applying that mechanical metaphor to information itself is an architectural category error. Hickey stresses that constructs tied to physical memory locations have no business being part of an information model: “One of the big takeaways should be that place—that all of your constructs related to place—have no role at all in an information model.”
```mermaid flowchart LR accTitle: Mechanical Process vs Fact Accumulation accDescr: Contrasting machine-like processing pipelines with historical fact retention over time.
subgraph Process ["Process: The Machine Metaphor"] A["Loading Dock"] --> B["Conveyor Belt"] B --> C{"Sorter"} C --> D["Output A"] C --> E["Output B"] end
subgraph Information ["Information: Fact Model"] F["Fact at T0"] --> G["Fact at T1"] G --> H["Fact at T2"] end ```
[24:27](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=1467s) Programmer IT vs. Business IT: The Irony of Big Data
Hickey highlights that software engineers already instinctively understand the value of historical values because they reject update-in-place for their own tooling. When programmers manage their own primary artifact—source code—they do not use a raw file-system directory where every new edit overwrites the previous version without a paper trail. Nor would any developer accept a version control system stripped of dates, times, and commit logs. The same holds true for operations infrastructure: developers do not maintain a single-variable log that continually overwrites itself to say merely that the last latency was five milliseconds. They log continuously, appending every event with a precise timestamp because running a system without historical context is impossible.
```mermaid flowchart TD accTitle: Programmer IT versus Business IT accDescr: Comparing the immutable logging of programmer IT with the destructive updates forced onto business systems.
subgraph DevTooling ["Programmer IT (What We Build for Ourselves)"] VCS["Version Control: Complete Commit History + Timestamps"] Logs["System Logs: Continuous Append-Only Records + Timestamps"] end
subgraph BusinessTooling ["Business IT (What We Hand to Customers)"] DB["CRUD Database: Destructive In-Place Overwrites (Only Current State)"] end
subgraph BigDataConsequence ["The Big Data Reaction"] Mine["Business mines raw operations logs with MapReduce to recover lost history"] end
DB -.->|"Missing history forces"| Mine Logs -->|"Accidental historical record"| Mine ```
This divergence reveals the real driving force behind the Big Data phenomenon. Hickey contends that much of Big Data is simply business users realizing that the operational logs kept by programmers are vastly superior to the transactional databases built for the business. Business stakeholders look at developers and say: “That database you have I like better than the one you gave me, because the one that you gave me only remembers the last thing I told it, and your database, your logs, they know everything that happened in our business.” Desperate to identify trends and rates of change, companies turn to mining developer logs with MapReduce. Hickey views this as an embarrassing, reactive workaround: raw logs are cluttered with low-level execution noise and lack leverageable schema structure, reflecting the industry's failure to build proper, append-only business databases in the first place.
- Developers depend on complete temporal records for source code and application monitoring, yet deny business users those exact capabilities in business software. - Decision-making fundamentally requires calculating rates of change, spotting trends, and aggregating historical metrics—operations made impossible by destructive updates. - Mining raw execution logs is an inefficient stopgap caused by storing business facts in place-oriented database engines.
[27:55](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=1675s) Entering the Space Age: Retiring Place-Oriented Programming
Hickey argues that modern computing has officially crossed into the "Space Age." Historically, definitions of space have unified both physical extent and temporal duration: "the unlimited expanse in which all things are located and all events occur." In modern computing environments, developers no longer hit the physical boundaries of local storage: allocating memory with `new` succeeds indefinitely without immediate failure, and cloud storage like Amazon S3 never reports that it is full. When resources are virtually boundless, software is no longer constrained to operating within a fixed physical "place." Hickey urges developers to adopt a radically simple architectural rule: “Information systems should have a different approach: they should say that new facts require new space.”
```mermaid flowchart LR accTitle: Space-Oriented Information Architecture accDescr: How modern systems allocate new storage space for each successive fact rather than overwriting existing memory.
subgraph Space ["Unbounded Space (Memory / S3 / Distributed Storage)"] direction TB F1["Fact T0 (Immutable Value)"] F2["Fact T1 (Immutable Value)"] F3["Fact T2 (Immutable Value)"] end
F1 --- F2 --- F3 GC["Storage Garbage Collection handles reclamation asynchronously"] -.-> Space ```
The historical justification for place-oriented programming—such as $5,000 five-megabyte hard drives where every byte had to be conserved by overwriting existing memory—has been completely obsolete for years. Just as garbage collection automated the reclamation of dead memory references without forcing developers to manually overwrite active data, modern storage systems can manage persistence without destructive in-place updates. Hickey laments that the industry continues to design brand-new programming languages and databases that stubbornly cling to obsolete, place-oriented paradigms:
- Hardware economics have eliminated the storage constraints that originally forced engineers to mutate memory in place. - In-memory garbage collection patterns are shifting down the stack into persistent distributed storage engines. - Developers already accept the Space Age for their own logs and source repositories; they must now extend the same respect for historical values to the business applications they construct.
## Notable quotes > [27:55](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=1675s) Information systems should have a different approach: they should say that new facts require new space. — Rich Hickey
> [21:28](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=1288s) And the reason why you can't update a fact is because you can't change the past and that's what facts are: they're documentation of the past. — Rich Hickey
> [21:28](https://www.youtube.com/watch?v=-6BsiVyC1kM&t=1288s) One of the big takeaways should be that place—that all of your constructs related to place—have no role at all in an information model. — Rich Hickey
## Mentioned Rich Hickey, Clojure, Datomic, Guy L. Steele Jr., Bill Clinton, Java, CORBA, DCOM, JSON, XML, Amazon S3, MapReduce, JaxConf
## Video description In this keynote speech from JaxConf 2012, Rich Hickey, creator of Clojure and founder of Datomic gives an awesome analysis of the changing way we think about values (not the philosphoical kind) in light of the increasing complexity of information technology and the advent of Big Data. The broad subject of the talk makes it worth watching for almost anyone in the programming world, and was one of the highlights of the JaxConf lineup.
If you like the talk, check out Hickey's other appearance at JaxConf2012 here: http://marakana.com/s/rich_hickey_on_deconstructing_the_database,1261/index.html
[Source](https://www.youtube.com/watch?v=-6BsiVyC1kM)