Hacker News Reader

Comment by smitty1e | Hacker News Reader

We love to hate state, but isn't caching data the key to performance at scale?

> We love to hate state, but isn't caching data the key to performance at scale?

It seems you're mixing things up. "State" in this context doesn't mean caching results. "State" in this case means that your code has internal state that you can't control, thus your components behave unpredictably depending on factors you can't control.

Picking up your caching example, what would you say if your HTTP cache either returned your main page or some random noise in an apparently random way, even though you're always requesting the exact same URL?

You may be correct vis-a-vis OP, but I'll stick to my guns as far as 'state' being any piece of information that has to managed.

If I'm not writing pure functions, then there is some piece of information whose lifecycle suddenly requires care and feeding, especially if there are environmental factors making that state more 'interesting' than the code in view.

The advice is that state is hard to deal with, so you should try to isolate it from the rest of your program. You can even organize stateful components like a cache to isolate the stateful components.

- Make your stateful components "dumb". The cache should just have dumb put,get,delete methods.

- Make your "smart" components stateless. Your component deciding which items to cache or remove or invalidate should be passed all the state they need to make their decisions as immutable parameters. This will make your lifecycle management code much easier to test or log.

- Keep the part gluing the dumb state and the smart functions small

In the end you still have a stateful component, but as a whole it should be easier to work with. For example, it's much easier to test time-based lifecycle decisions if you pass in the current time than if the component grabs the current time from your system clock.

Programming maxims inevitably get compromised by the real world. We just try to do our best.

Using a cache (short of the language tools doing automatic memoization, or memoization hints on a function or procedure maybe) before making the code correct but slow is one of the greatest hallmarks of premature optimization. Remember Knuth said "less than 4 percent of a program typically accounts for more than half of its running time".

Write some simple code that does the thing. Then debug it. Then profile it. Then swap out for some more efficient algorithms if necessary in the hotspots. Then look at microoptimizations. In any case, don't spend more time optimizing that it will save in runtime across the lifecycle of the code.

Typically caching is not supposed to affect correctness, 'only' performance behavior.

hey seriously, i've been grappling with this: what better candidate to be a global variable than a shared cache that otherwise has to be passed through dozens of function calls (which imo adds cognitive load at many places through the stack).

I don't think passing state through functions calls add cognitive load: it just make it visible. Global state has the same cognitive load, except hidden.

If a state is passed through dozens of function calls, this may indicate that it is shared by too many parts of the code, or that it is managed at the wrong layer of the architecture. When using global state, these potential problems are difficult to spot.

> (...) which imo adds cognitive load (...)

Choosing to ignore input data does not reduce cognitive load. You are not supposed to ignore the core function of your work, and call it a good practice.

It's also famously one of the hard problems.

Reply on news.ycombinator.com