The UI being global mutable state isn't actually true on all platforms (but is true on the web). And even then its possible to "hide" that to some degree in well designed frameworks.

Never say never, but half of your examples _shouldn't_ be globally mutable state.

You seem to be talking about accessing things through interfaces, so that one can change whatever is on the other side of the interface. For testing, for example.

I am referring to something that there is only one of, while the program is running, which holds state, and that all part of a program potentially have access to.

Even if a dependency is injected, if it has state, and all parts of the program could potentially access it, I would consider it global mutable state.

This is part of the problem with the 'don't use global mutable state' advice. If what you really mean is 'access state through interfaces', then that's what we should say.

So, to be concrete, in my use of the term, a file cache is global mutable state because

a) I don't want multiple caches, potentially with the same content, in my program. In fact, this would be bad enough that I'd like to be confident it can't accidentally happen. I understand that some caches don't need this guarantee, but some do.

b) All parts of my program that use a file, use the cache to retrieve it.

c) The contents (and therefore the behavior, most specifically the timing) of the cache depends on the history of the program up to that point.

However, my implementation, I access files through an interface, so it would be trivial to change implementation.

Dependency injection does not insulate you from the global mutable state. It is a way of managing containers for state (or other behavior). Those containers can have any boundaries within your program you choose, from global down to the most local (remember that 'global versus local' is a continuum, not a binary).

Not all parts of the program could potentially access it - it's injected where it's needed but only where it's needed, if other parts of the program wanted access to it you would have to change them so that it was injected there as well.

It makes little substantive difference whether the import is in code or in a separate declaration. Little substantive difference to whether the state is global and mutable, that is. Don't misunderstand me as claiming dependency injection is pointless.

Yet each component is supposed to implement component/Lifecycle protocol... in other words, an interface.

And component is actually awful in practice. It may look neat in theory, but it's too simple and results in a mess not much better than it would be without it.

In some other Python code, I have some global objects which manage some data, but few or none standalone global variables. There just doesn't seem to be much need.

I think of the code that I wrote when I first started programming. Nearly every variable was global, because I simply couldn't be bothered to think about where it could be accessed from. But nowadays I can't remember the last time that I used a global variable, and I'm no worse off for it. For beginners it's a tempting tool to turn to, and we need to continue teaching aversion to it. Like `goto`, we can both consider it harmful and also happily allow its use when well-considered.

(Historical fact: very ancient versions of Rust didn't have global state at all, as Graydon was hoping to find a way to avoid ever needing to use it; eventually he was persuaded otherwise. Though global mutable state in Rust still requires the `unsafe` keyword to access due to the risk of concurrent access, so it's rare to see it in the wild (and quite obvious when it is).)

But here's the problem I have. If we don't want people to use global variables, the advice should be 'don't use global variables'. There is no need to wrap it up in 'avoid global mutable state', when using global mutable state is unavoidable in many cases and the best engineering solution in many others.

At the point you have to nuance it to 'reduce your code's exposure use global mutable state, accessing it through mockable interfaces, and defensively checking its values' to mean 'don't use global variables', it may be simpler to say what we mean.

For example: there is a comment lower down in this thread of someone confused by the advice in the context of the game engine. I've worked with hundreds of game engines, every one of them has global mutable state.

For example, in back-end Java dev, I never use singleton objects in the truest sense of the pattern; singletons cannot be mocked out to test units in isolation. Instead, instantiate it with a dependency injection container and let your framework (Guice, Spring) wire things together. In effect, your global state becomes contained within a single context. Nothing stopping you having two contexts in the same runtime environment though.

I find static methods are okay if they are concise and have no state; in particular if I'd never want to test the caller without it making the call to the static method anyway. This is becoming more important with Java 8's lambdas and needing to write helper methods.

On the other hand, the cost of doing this might not be worthwhile for a game dev? Do game devs write unit tests? I have no idea.

Yes. Therefore you need to check every bit of data coming from user. You need to be ready to a lot of breakage, and need to code ways to recover for it. Working with external data is hard, need a lot of checking and exception handling. It is nightmare and you do not want to propagate this to every line of your code. So just do not create global state.

> a database is global mutable state, as is the DOM / UI.

And this also. You always need to expect something unexpected with global mutable state. DOM can be changed while your code is working with it. You should write code, that can notice such an inconvenience and be nice in this case. Or to write code that just works and do not breaks things, if something unexpected happened. Or code that makes unexpected impossible to happen. The same with databases.

I often miss transactions and checks on regular in-memory data. While it must be operative, and cannot be done out-of-process or even out-of-context, locks and dispatching is a mess at the end of the day, because correct paths are usually independent, and vice versa — conficting paths can simply fail or retry at the end, wasting cpu time, not developer's. Actually, good principles (i.e. explicit context, no globals, strict hierarchy, etc) are resembling transactions in a sense; you copy parts of state to worker(-s), delay updates into results and reintegrate these in dispatcher in a blocking manner. Only by hand.

One thing that stops me from doing everything in just sqlite is copying. You always copy to and copy back and every += becomes a copy operation. Right now (well for some background time) I'm thinking of the language that has the concept of transactions and relational algebra built right into the base types, but is not so cumbersome to write and/or poorly optimized like conventional database scripting. Mating rdbms internals with e.g. C-likes (as the common least) would be nice to test in real tasks.

Ps. I'm sure I'm missing some past info on that; if someone is aware of the details, you're welcome to share.

I am curious if you've looked at C# and their LINQ stuff though as it sounds like it might check a lot of those boxes. I'm no C# expert myself, haven't used it for several years (since right before LINQ was introduced) so I'm not sure, but it looked to be along those lines when it was being proposed.

As of right now (for game projects) my strategy is to use source code generation to make the working language behave in a database-like fashion and emit a static result, rather than to engineer a complete dynamic schema with a scripting runtime and all the bells and whistles of a standalone database. The latter is both harder to build and lets me leverage fewer of the tools of the host environment.

Regarding caching your processor tends to feel otherwise and has multiple levels of cache because globally mutating state in a coherent way is slow as molasses.

I can't wait to hear what awesome program needs a connection pool and access to the JIT at the same time. Are you writing a SQL compiler that sends mail?

Is your awesome program by any chance written in JavaScript or PHP?

PS. Databases aren't really global mutable state as in when you ask your database for a count of rows in a table the answer you get back won't ever change because magic.

Also, because of the ways database ARE global mutable state you run into all the issues you typically do with global mutable state. And then the places you do have global mutable state turn into performance nightmares. (Read: Hot spots)

The way I think about it is that if you create a global variable for a user, you are saying that there is always a one-to-one correspondence between a user (maybe the current user) and a process.

In some apps (such as command-line apps) you can assume that the OS user is always the current user. But if you ever write an app that might be used by more than one person, you probably want to keep track of which user you're currently talking about. For example, are there multiple profiles? User switching? Simulated users in tests? There are relatively few objects that we can sure will always be one-to-one with a process. When writing libraries this is especially uncertain since you don't know the app's architecture.

It is basically a language which trains you to try to err on the side of caution.

It's often preferable to be religious when you can be, as even if you do there will still be plenty of bugbears left to watch out for.