The commit that fixes this issue:
https://github.com/gitster/git/commit/684dd4c2b414bcf648505e...
(Surprise, the root cause is a cache)
https://github.com/gitster/git/commit/684dd4c2b414bcf648505e...
(Surprise, the root cause is a cache)
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...
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.
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.
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.)
> There are only two hard things in Computer Science...
three most difficult things in CS:
2) Naming Things
1) Cache Invalidation
4) off by one errors
3) Concurrency
There are only two hard problems in distributed systems:
2. Exactly-once delivery
1. Guaranteed order of messages
2. Exactly-once delivery
0) naming things
1) cache invalidation
42) asynchronous callbacks
2) off by one errors
I see it with HAND "have a nice day" too
I see that's wrong, but ignorance has made the internet seem just that little bit warmer all these years!
what that you?
on edit: I'm going to let that 'what that you' stand because one of the hardest things about HN posts is grammatical correctitude.
You write it on local media and kept it on-premises?
Cloud is the new thing, I hear.
1. Make it work
2. Make it right
3. Make it fast (make sure you need to) a.k.a. optimize
4. Make it scale
Along the same lines a lot of GPU programming tutorials warn of inconsistencies between threads and it has never been a problem since I just assume I cannot rely on consistency or order of execution, seeing each thread as separate and independent.
(1) cache invalidation
(2) off-by-one errors
1) naming
2) cache invalidation
...
3) off-by-one errors
1) naming
4) concurr2) cache invalidationency
...
3) off-by-one errors
0) Race consegmentation fault (core dumped)
(I know I was ninja’d but didn’t see until after)
Alas.
- a good name should be descriptive
- avoid being overly clever, call a spade a spade
- don't optimise for generalisation, naming things is a time to be specific
- aim for short but not at the expense of losing context
- avoid redundancy in naming of things nearby, leverage spatial context
- avoid qualifiers or type information where possible - type should be obvious from context and use, if it's not qualify or refactor
Anything else?
1) Those who number lists starting at 1.
1) Those who number lists starting at 0.
2.5) Stan Kelly-Bootle, who proposed a compromise.For the simplest example: compare the old C-style for loop vs a Python style for-each loop.
Oh, and slicing. I will never get Python slicing right the first time. The fact that the range is [begin, end) is just never the way I expect it to work.
In [0, len) ')' means less than. As in 0≤ x< len.
The formulation of this joke I tend to see is,
The two hardest problems in programming:
(1) cache invalidation
(2) appropriately naming things
(3) off-by-one errors
(Cache invalidation is essentially the same problem as managing mutable state -- "Out of the Tar Pit" frames mutable state as either essential or incidental, the latter being rederivable in principle from essential state. Incidental mutable state is no more and no less than a cache, and usually one with an informal and undocumented invalidation policy.)
(And naming things has a very real technical counterpart in addressing, which comes up obviously in networking, but you can also see its shadows in quite a lot of concerns around architecture and modularity.)
(1) cache invalidation
(3) off-by-one errors
(2) appropriately naming things
(4) parallel execution [leading to race conditions / ordering bugs]
1) Naming 3) Cache Invalidation 2) Off-by-one errors 3) In-order once-only delivery of distributed messages
And an almost fanatical devotion to the Pope
1) naming
4) concurr2) cache invalidation
ency
3) off-by-one errors
Couldn’t it just as well be attributed to improper file path normalization? If we had only lower case ASCII file systems it would not have caused a problem.