[ratww]

> Immediately I remind myself that the implementation from the book ignores the problem of persistence completely. If you close that application it loses all the state. I think this is not an accident. This is where things go wrong for OOP really fast.

This point hits hard.

Managing "live" scattered state that is gonna go away when the program dies is hard in itself. But as soon as you have to persist it or do anything fancy with it, you pretty much have to change the whole approach of your app. This is why it's always a good idea to start with established frameworks that handle persistence if you're ever gonna need it. Bolting-on is just too hard.

It also reminds me of my first job, in a Desktop app. State became so complex that to apply a "global change", like currency or language, it was required to close the app and open again. It was something very common, seeing how many apps required such things.

In the middle of my career I also worked in a very large video game. The higher ups wanted to change how "game saving" worked and instead of having to serialise just the basic stuff (health, lives, level) we needed to change it to serialise the whole game state including enemy positions and actions. It was the biggest change we did and we ended up having to add lots of boilerplate because of the scattered state. IMO, ECS was a very interesting development purely because now state is not encapsulated anymore, making serialisation completely separate from everything else.

Curiously, as much as modern frontend programming is maligned, such issues are easier to solve with central state management libraries like Redux.

[neutronicus]

Ha

I do like how ECS and Redux have that common thread of rediscovering global state

[ratww]

True. There's lots of parallels between those two things and relational databases, too.

In the end it seems that the "web app with a database" is becoming the template for other types of apps.