Global Mutable State is bad.
Global Mutable State is bad.
Global Mutable State is bad.
But which state and in what context?
Your Oracle is Bad
Do you use a database? Because if you do, it is a Global Mutable State. Is it bad? I don’t think so, it’s very useful.
The mutability concept is “bent” by databases like Datomic since it introduces a time dimension, but even in Datomic, for most cases, you only need to know “the latest” value, and it is going to mutate. Yes, over time, but nevertheless, for an application that cares about a stock price: it mutates. This is just how we understand the world: it is our own Global State and it Mutates over time, and it’s great!
Your Oracle Connection is Bad
Do you ever connect to a database? Because if you do, it is a Global Mutable State. Oh, wait, it should not be global, it should be well encapsulated and only used in functions / components / classes / modules / local bindings that need it right? We should narrow it down as much as possible.
All correct. But… narrow it down all you want, if you rely on this database connection in 42 places in your codebase and this connection dies, it affects all 42 places, no matter how well “localized” they are. So why not embrace this fact and just admit that this is a Global Mutable State: e.g. you can call connection.disconnect() in any of these 42 places, and it is going to affect all the rest. If it is easier, we can call it a Quite Global Mutable State.
Your Configuration is Bad
Do you rely on any configuration files that you load from Zookeper / etcd / file system? Ah.. but they are not mutable. Ah.. but they are.
Say you support reloading these configs at runtime, a pretty common pattern, and quite useful for certain systems. Every time you mutate it and reload, it affects all components of an application that rely on it. “Yes, but don’t put it as a top level mutable reference, so a beginner programmer can mutate it by mistake, and then it is not easy to reason about it”… Ok, somewhat a fair point => you can still keep it as a global reference, if you need, but point it to an immutable map: done.
Your Salary is Bad
Some questions with the same answers as above:
* Is your network socket connection bad?
* Is your global threadpool bad?
* Is your queue bad?
* …
But this is not to say that any state is naturally a Global Mutable State, or that we, as programmers should not worry about it, quite the contrary, we should take a great care about the “business”/”problem” state.
Say you have an application that deducts taxes from peoples’ salaries, and does so concurrently. If you have your “next salary” as a Global Mutable State, you might end up borrowing for the mortgage this month.. computer error, oops.
The point is: resources, I/O, external storage, etc.. are all examples of the real Quite Global Mutable State. Yes, this state can be hidden from certain components, and only available in some, but its change(s) immediately affect all the components that rely on it, which is “quite global” as the state goes.
You are Bad
You change over time, well I do. We evolve and mutate. Is it bad? Should we be caged into the smallest possible cages so it is easier to reason about us? :) I don’t think so. Ok, so instead should we expose ourselves to anybody who can hurt us? Also, no. We choose how to present ourselves to the Universe, so why can’t we have the same choices in software? We are smart, we can do this!