Hacker News Reader

Comment by mannykannot | Hacker News Reader

Before reading this article and its follow-on, I would have completely endorsed the view that global mutable state is the worst, but for the sorts of issues the author is writing about, it seems that global mutable state is precisely the thing that makes procedural solutions more straightforward. In this case, it seems to be an intuitive and straightforward model for how both the programmer and player view the problem.

View on HN

The only thing worse than global mutable state is a complicated and buggy structure that does the exact same thing that global mutable state does

It makes the most sense to me to default to immutable, but swap to mutable when appropriate.

There's kind-of a name for it too, it's a variation on blackboard programming, just not specifically for AI: https://en.wikipedia.org/wiki/Blackboard_system

The article didn't talk about global mutable state. Nobody likes global mutable state. Nobody, not even C programmers. If possible mutable state should always be local to a function.

Scroll down to where it talks about the game "Bumbler" - the game environment is global mutable state.

Until you attempt to multithread the logic and everything breaks.

This is true to the extent that it’s true to say that functional programming requires you to make copies of immutable structures every time something changes, which is to say not at all.

Multithreading is a problem when you have chaotic ownership of writes and updates. There are decades of prior art showing that this is a manageable problem using various strategies, and it’s not helpful to talk in absolutes rather than discussing the relative trade offs.

When your problem domain has changing global state, do you not have synchronization issues - ensuring that stale data is not used, for example - regardless of how you program it? I recall an article making this point, possibly by the same author.

Reply on news.ycombinator.com