3 ms·

That's because essentially, "state" and "caching" are the same thing on some level. And the problem with state is that you have to make sure all your state tra

by anyfoo 6y ago

That's because essentially, "state" and "caching" are the same thing on some level. And the problem with state is that you have to make sure all your state transitions don't cause bugs. What we know as a "cache" is essentially creating new state representing existing state, with all new transitions...

bin_bash 6y ago
Cache is a type of state but not necessarily the other way around
- anyfoo 6y ago
  In the efficient implementation of a pure functional language (say Haskell without MVars), what really is the difference between state and cache? I know this is overly philosophical, and in practical scenarios we readily (although not always unambiguously) differentiate between "cache" and "state", but the point about transitions and that being a major source of bugs still stands.
  - eru 6y ago
    > In the efficient implementation of a pure functional language (say Haskell without MVars), what really is the difference between state and cache? If you want to unify state and cache, you might want to go down a different route: Think of log based filesystems (or a log based data base). Instead of defining your operations in terms of state, you define them as pure functions of the log. So your log is full of operations. Writing just means appending a symbolic operation like `write(key, value)` to your log. And you define the result of `read(key)`: scan backwards through the log until you hit the last instance of `write(x, value)` and the return that `value`. Now state means: compact your log by replacing a swath of `write` log entries with one big `snapshot` operation that encompasses many key/value pairs. Alternatively, you can also define state to mean caching your `read` operations. In this approach, it's no coincidence that the log is a data structure that has a linear shape: the evolution of state over time is also linear. (With some cleverness you can replace the linear structure with eg a DAG; and then also think about how you merge divergent states.)
branko_d 6y ago
I like to look at caching as a form of denormalization - introducing redundancy to improve performance. And whenever we have redundancy, we have to make sure all our copies are synchronized, which can be tricky, especially in a concurrent environment. On the other hand, the whole point of normalization in databases is to avoid redundancy and have "single source of truth". I find the concepts of normalization and denormalization applicable and helpful outside databases as well, though a different terminology is often used.
- adolph 6y ago
  In that light, a cache is a form of partition, so it can be available xor consistent with its source. https://en.wikipedia.org/wiki/CAP_theorem https://en.wikipedia.org/wiki/CAP_theorem

by anyfoo 6y ago

bin_bash 6y ago

Cache is a type of state but not necessarily the other way around

anyfoo 6y ago
In the efficient implementation of a pure functional language (say Haskell without MVars), what really is the difference between state and cache? I know this is overly philosophical, and in practical scenarios we readily (although not always unambiguously) differentiate between "cache" and "state", but the point about transitions and that being a major source of bugs still stands.
- eru 6y ago
  > In the efficient implementation of a pure functional language (say Haskell without MVars), what really is the difference between state and cache? If you want to unify state and cache, you might want to go down a different route: Think of log based filesystems (or a log based data base). Instead of defining your operations in terms of state, you define them as pure functions of the log. So your log is full of operations. Writing just means appending a symbolic operation like `write(key, value)` to your log. And you define the result of `read(key)`: scan backwards through the log until you hit the last instance of `write(x, value)` and the return that `value`. Now state means: compact your log by replacing a swath of `write` log entries with one big `snapshot` operation that encompasses many key/value pairs. Alternatively, you can also define state to mean caching your `read` operations. In this approach, it's no coincidence that the log is a data structure that has a linear shape: the evolution of state over time is also linear. (With some cleverness you can replace the linear structure with eg a DAG; and then also think about how you merge divergent states.)

branko_d 6y ago

I like to look at caching as a form of denormalization - introducing redundancy to improve performance. And whenever we have redundancy, we have to make sure all our copies are synchronized, which can be tricky, especially in a concurrent environment. On the other hand, the whole point of normalization in databases is to avoid redundancy and have "single source of truth". I find the concepts of normalization and denormalization applicable and helpful outside databases as well, though a different terminology is often used.

adolph 6y ago
In that light, a cache is a form of partition, so it can be available xor consistent with its source. https://en.wikipedia.org/wiki/CAP_theorem https://en.wikipedia.org/wiki/CAP_theorem