5 ms·

Isn't a database global mutable state? Or a filesystem? If global, mutable state is considered problematic when programming in the small (i.e. single program),

Isn't a database global mutable state? Or a filesystem? If global, mutable state is considered problematic when programming in the small (i.e. single program), why is it unquestioned when building much larger, more complicated systems that we also need to reason about?

JadeNB 9y ago
> Isn't a database global mutable state? Or a filesystem? Yes, hence file (and database) locking!
bsears 9y ago
Global, mutable state is not necessarily a bad thing, it just needs to be managed very carefully (like through a database!) so all your mutations are routed through a single source of truth.
vikiomega9 9y ago
There are patterns around this. For example, persistent data structures and application patterns such as event sourcing. Design concepts like bounded contexts and microservices also count. I think at a larger scale it becomes much harder to try and transform the system around immutable state. At the end of the day if most one needs to do is store CRUD items the easiest way forward is persist schema to a DB.
keymone 9y ago
database is sufficiently isolated, provides all sorts of safe mechanics to deal with state and people still mess it up. filesystem is basically a database with simpler interface, less guarantees and more ways to mess up. internal global mutable state within your program is just a wild west. especially in multi-threaded environments.
inglor 9y ago
A database is only global and mutable if any part of your code can create it. If you isolate the database access to one module and then force other modules to interact with it through instances of that module in a controlled way - it's not global (but certainly mutable). The same goes to your filesystem, the key thing is: global as global access vs. global as "there is one of it". The same goes for the singleton pattern (which are terrible) vs. just having one of something.
- adrianratnapala 9y ago
  I don't get this. Once you mutate the database, then the behaviour of any code anywhere that uses the DB, whether directly or through a module is potentially affected by the mutation. Modularisation is great and all, but it doesn't make concurrency and cache-coherency problems go away. In fact it sometimes makes those things worse (or at least more opaque).
  - wiz21c 9y ago
    The database (at least the relational ones (I don't know the nosql thing)) is actually a very well behaved global state. It gives you guarantees about its mutability which you often don't have in your own code (well, in mine at least :-)). Moreover, the transactional nature of those DB actually percolates in many places in the code and makes it more reliable. So I'd say the database is a very special mutable thing, it's not as general as the usual proposal of GMS and therefore, it's much less dangerous.
    - deleted 9y ago
      [deleted]
  - inglor 9y ago
    I'll try to elaborate, global _app_ state is different from global state "in the wild". The internet is "global state" but you wouldn't call any code that makes HTTP requests global state because the "globality" is isolated inside your app. Global can mean several things, my point was only that "globality" inside your app can (and should) be very constrainted while acknowledging some things are indeed global from your app's point of view. A good example of this is having a global "db" object vs. a DB instance passed to places. This is more about whether or not your code should care about where it gets data or not. I think this (now classic) talk is a nice explanation about why your components should not "look for things" in the global but instead should be explicit about dependencies any why it's easier to reason about: https://www.youtube.com/watch?v=RlfLCWKxHJ0 https://www.youtube.com/watch?v=RlfLCWKxHJ0
adrianratnapala 9y ago
Yes such things are global mutable state. Worse yet, for big systems "global" means "global to an earth-wide network", not just to a single process. That's why the design discussions about how to do stuff on such networks always centre on how to manage this global, distributed, mutable state. It really is hard stuff. The nice thing, is that once you have done that design work, and are programming "in the small" to implement it, the individual processes can be stateless.
bcherny 9y ago
Database state is not necessarily global or mutable. See for example Rich Hickey's Datomic [0]. [0] https://www.infoq.com/presentations/Datomic-Database-Value https://www.infoq.com/presentations/Datomic-Database-Value
lmm 9y ago
> Isn't a database global mutable state? Or a filesystem? Yes. > If global, mutable state is considered problematic when programming in the small (i.e. single program), why is it unquestioned when building much larger, more complicated systems that we also need to reason about? It is, and should be, considered problematic. The filesystem can mostly be avoided. The database should probably be rebuilt into something that's easier to reason about. See e.g. https://www.confluent.io/blog/turning-the-database-inside-out-with-apache-samza/ https://www.confluent.io/blog/turning-the-database-inside-ou...
novembermike 9y ago
Reality is global mutable state. You can't get away from it entirely, you can only isolate it.
mightybyte 9y ago
Yes, databases and filesystems are global mutable state (at least if you do anything other than append to them). And they also require vastly more care. For instance, if you store a JSON blob in your database, you have to be VERY careful with how you change it over time. If you make a backwards-incompatible change to the schema without realizing it, you break. A likely response is to advocate better testing, but you need a special kind of testing to detect this problem. Plain old unit tests won't cut it because it's not about whether your parsing and rendering code at any given point in time is correct. It's about whether the parsing code from today's commit is compatible with the rendering code from the previously deployed commit! Furthermore, if you deploy incorrect code, it could add JSON blobs to the database with the new schema before it crashes on the old schema. Now you've got two incompatible versions of the JSON blob in the DB at the same time, so rolling back to the old code will still be broken! Software engineers deploying production apps have been dealing with these issues since we started using databases, but that doesn't mean that it's any easier or less error prone. It just means that we have to be more careful. And that care has a cost. This cost isn't unquestioned for larger systems. It's a big part of the motivation for append-only databases, for example. http://thesoftwarelife.blogspot.com/2010/12/append-only-databases.html http://thesoftwarelife.blogspot.com/2010/12/append-only-data...
tigershark 9y ago
If in your case is a global mutable state then most probably there is a problem. In my experience, most of the time, only a certain piece of code changes a certain table. If in your case every module can indiscriminately mutate every table I warmly suggest to mutate your design. In case of distributed applications in which you are mutating very frequently from multiple serves the same tables then don't forget to use transactions. In case you need to do it by design and you don't explicitly need transactions then use some in-memory cache backed by a db, with distributed locks when necessary. Someone already did the really hard work for you, no need to reinvent the wheel.
ilyagr 9y ago
More generally, every computer eventually has to interact with the outside world, which is global and mutable. Human mind have a much easier time dealing with things which are as immutable as possible. For instance, a physical law like the Newton's law of gravity is immutable. The variables within it are mutable, but there's only a few of them -- they would be local in a function that computed the force of gravity. Without such laws, it would be very difficult to reason about physics.
naasking 9y ago
> why is it unquestioned when building much larger, more complicated systems that we also need to reason about? It's not unquestioned at all. See for instance, CQRS and event sourcing. Mutable state is generally a problem, but undelimited mutable state is a serious headache.

JadeNB 9y ago

> Isn't a database global mutable state? Or a filesystem? Yes, hence file (and database) locking!

bsears 9y ago

Global, mutable state is not necessarily a bad thing, it just needs to be managed very carefully (like through a database!) so all your mutations are routed through a single source of truth.

vikiomega9 9y ago

There are patterns around this. For example, persistent data structures and application patterns such as event sourcing. Design concepts like bounded contexts and microservices also count. I think at a larger scale it becomes much harder to try and transform the system around immutable state. At the end of the day if most one needs to do is store CRUD items the easiest way forward is persist schema to a DB.

keymone 9y ago

database is sufficiently isolated, provides all sorts of safe mechanics to deal with state and people still mess it up. filesystem is basically a database with simpler interface, less guarantees and more ways to mess up. internal global mutable state within your program is just a wild west. especially in multi-threaded environments.

inglor 9y ago

A database is only global and mutable if any part of your code can create it. If you isolate the database access to one module and then force other modules to interact with it through instances of that module in a controlled way - it's not global (but certainly mutable). The same goes to your filesystem, the key thing is: global as global access vs. global as "there is one of it". The same goes for the singleton pattern (which are terrible) vs. just having one of something.

adrianratnapala 9y ago
I don't get this. Once you mutate the database, then the behaviour of any code anywhere that uses the DB, whether directly or through a module is potentially affected by the mutation. Modularisation is great and all, but it doesn't make concurrency and cache-coherency problems go away. In fact it sometimes makes those things worse (or at least more opaque).
- wiz21c 9y ago
  The database (at least the relational ones (I don't know the nosql thing)) is actually a very well behaved global state. It gives you guarantees about its mutability which you often don't have in your own code (well, in mine at least :-)). Moreover, the transactional nature of those DB actually percolates in many places in the code and makes it more reliable. So I'd say the database is a very special mutable thing, it's not as general as the usual proposal of GMS and therefore, it's much less dangerous.
  - deleted 9y ago
    [deleted]
- inglor 9y ago
  I'll try to elaborate, global _app_ state is different from global state "in the wild". The internet is "global state" but you wouldn't call any code that makes HTTP requests global state because the "globality" is isolated inside your app. Global can mean several things, my point was only that "globality" inside your app can (and should) be very constrainted while acknowledging some things are indeed global from your app's point of view. A good example of this is having a global "db" object vs. a DB instance passed to places. This is more about whether or not your code should care about where it gets data or not. I think this (now classic) talk is a nice explanation about why your components should not "look for things" in the global but instead should be explicit about dependencies any why it's easier to reason about: https://www.youtube.com/watch?v=RlfLCWKxHJ0 https://www.youtube.com/watch?v=RlfLCWKxHJ0

adrianratnapala 9y ago

Yes such things are global mutable state. Worse yet, for big systems "global" means "global to an earth-wide network", not just to a single process. That's why the design discussions about how to do stuff on such networks always centre on how to manage this global, distributed, mutable state. It really is hard stuff. The nice thing, is that once you have done that design work, and are programming "in the small" to implement it, the individual processes can be stateless.

bcherny 9y ago

Database state is not necessarily global or mutable. See for example Rich Hickey's Datomic [0]. [0] https://www.infoq.com/presentations/Datomic-Database-Value https://www.infoq.com/presentations/Datomic-Database-Value

lmm 9y ago

> Isn't a database global mutable state? Or a filesystem? Yes. > If global, mutable state is considered problematic when programming in the small (i.e. single program), why is it unquestioned when building much larger, more complicated systems that we also need to reason about? It is, and should be, considered problematic. The filesystem can mostly be avoided. The database should probably be rebuilt into something that's easier to reason about. See e.g. https://www.confluent.io/blog/turning-the-database-inside-out-with-apache-samza/ https://www.confluent.io/blog/turning-the-database-inside-ou...

novembermike 9y ago

Reality is global mutable state. You can't get away from it entirely, you can only isolate it.

mightybyte 9y ago

Yes, databases and filesystems are global mutable state (at least if you do anything other than append to them). And they also require vastly more care. For instance, if you store a JSON blob in your database, you have to be VERY careful with how you change it over time. If you make a backwards-incompatible change to the schema without realizing it, you break. A likely response is to advocate better testing, but you need a special kind of testing to detect this problem. Plain old unit tests won't cut it because it's not about whether your parsing and rendering code at any given point in time is correct. It's about whether the parsing code from today's commit is compatible with the rendering code from the previously deployed commit! Furthermore, if you deploy incorrect code, it could add JSON blobs to the database with the new schema before it crashes on the old schema. Now you've got two incompatible versions of the JSON blob in the DB at the same time, so rolling back to the old code will still be broken! Software engineers deploying production apps have been dealing with these issues since we started using databases, but that doesn't mean that it's any easier or less error prone. It just means that we have to be more careful. And that care has a cost. This cost isn't unquestioned for larger systems. It's a big part of the motivation for append-only databases, for example. http://thesoftwarelife.blogspot.com/2010/12/append-only-databases.html http://thesoftwarelife.blogspot.com/2010/12/append-only-data...

tigershark 9y ago

If in your case is a global mutable state then most probably there is a problem. In my experience, most of the time, only a certain piece of code changes a certain table. If in your case every module can indiscriminately mutate every table I warmly suggest to mutate your design. In case of distributed applications in which you are mutating very frequently from multiple serves the same tables then don't forget to use transactions. In case you need to do it by design and you don't explicitly need transactions then use some in-memory cache backed by a db, with distributed locks when necessary. Someone already did the really hard work for you, no need to reinvent the wheel.

ilyagr 9y ago

More generally, every computer eventually has to interact with the outside world, which is global and mutable. Human mind have a much easier time dealing with things which are as immutable as possible. For instance, a physical law like the Newton's law of gravity is immutable. The variables within it are mutable, but there's only a few of them -- they would be local in a function that computed the force of gravity. Without such laws, it would be very difficult to reason about physics.

naasking 9y ago

> why is it unquestioned when building much larger, more complicated systems that we also need to reason about? It's not unquestioned at all. See for instance, CQRS and event sourcing. Mutable state is generally a problem, but undelimited mutable state is a serious headache.