# Immutability we can afford

DevFeed: [Immutability we can afford](<https://devfeed.tech/articles/immutability-we-can-afford-26022.md>)

Original publisher: [Read original article](<https://elizarov.medium.com/immutability-we-can-afford-10c0dcb8351d?source=rss-4762e889f8fc------2>)

Author: Roman Elizarov

Published: 2020-07-22T09:18:28Z

Content type: opinion

Language: en

Sources: [Stories by Roman Elizarov on Medium](<https://devfeed.tech/sources/stories-by-roman-elizarov-on-medium.md>)

Topics: [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>), [Programming](<https://devfeed.tech/topics/programming.md>), [Software](<https://devfeed.tech/topics/software.md>), [ui](<https://devfeed.tech/topics/ui.md>), [Caching](<https://devfeed.tech/topics/caching.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [asynchronous](<https://devfeed.tech/tags/asynchronous.md>), [caching](<https://devfeed.tech/tags/caching.md>), [code](<https://devfeed.tech/tags/code.md>), [debugging](<https://devfeed.tech/tags/debugging.md>), [immutability](<https://devfeed.tech/tags/immutability.md>), [languages](<https://devfeed.tech/tags/languages.md>), [object](<https://devfeed.tech/tags/object.md>), [programming](<https://devfeed.tech/tags/programming.md>), [programming-languages](<https://devfeed.tech/tags/programming-languages.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>), [state](<https://devfeed.tech/tags/state.md>), [ui](<https://devfeed.tech/tags/ui.md>)

## AI overview

The article traces the shift from mutable global state and object-encapsulated state toward immutability. It argues that mutable state becomes difficult to reason about in user interfaces and asynchronous systems, where unexpected mutations complicate debugging, event processing, and caching.

## Source excerpt

Photo by Li Yang on Unsplash At the dawn of software engineering computers were programmed directly in machine code, then in assembly, and only later in higher-level languages. Computers are imperative. They operate by executing instructions that mutate their state, stored in registers and memory. Naturally, the same was true about programming languages. In the old world of expensive computers with limited resources, the primary concern was an efficient translation of higher-level abstractions into low-level code. The past glory of mutable state It used to be a normal practice to write software in a way that mimics the actual computer architecture with thousands of global variables that are being mutated by various pieces of the system. It might be shocking for a modern developer to learn that just recently there were cars on the street, designed as late as 2005, that ran what we would call the "Spaghetti" code. The software industry, in general, had firmly moved past the unruly global state before the end of the last century. The rise of the object-oriented programming paradigm had established an orderly approach with the encapsulation of all the mutable state in our software systems inside of objects. It had fueled tremendous growth in the complexity of modern software, layering abstractions above abstractions, while still maintaining a reasonable degree of human's ability to make sense of it. However, any developer who worked on a non-trivial piece of UI using an object-oriented framework, or had programmed in another domain with lots of asynchronously occurring events, can tell you stories of debugging all those cases where mutable state, even encapsulated into objects, continually trips you. You expect this object to be in a such and such state, but due to some rare sequence of events, it turns out to be in a state you did not expect, having been mutated by another piece of code. For example, take a popular architectural pattern where a repository class encapsu