4 ms·
> People complain about stale data issues in immutable programming styles not because they're more prevalent, but because they can rule out so many other classe
by sigmaml 11y ago
> People complain about stale data issues in immutable programming styles not because they're more prevalent, but because they can rule out so many other classes of bugs immediately.
This generalisation is too broad (as with almost any generalisation).
In any case, I want to mention one interesting experience -- a very large financial portfolio management system that I worked on, over a decade-and-a-half ago.
The system had multiple in-coming tickers, feeding huge amounts of data. The central data structures of the computational pipeline system were immutable. Initially, there was a very haphazard system for determining when a particular piece of data was to be deemed stale. In time, formal definitions were established. However, the software was not amenable to those definitions, since shared data was not `seen' updating instantaneously.
The core was too big to be changed in any non-trivial manner, without risking the entire business.
We ended up introducing an explicit notion of time into every pipeline processor to ameliorate (not entirely solve) the situation.
Every major design decision has its own trade-offs that are specific to the problem on hand. But, those built into the foundations of the system should be made pragmatically, not by adhering to a philosophy!
- rtpg 11y agoI agree that things need to be pragmatic. But there are classes of bugs ruled out absolutely by things like immutable structures and referential transparency. Now, the thing is that there's always a way to model state, but at least I can rule out things like the term "x" to mean different things depending on how many times f was called beforehand for the most part.
- taeric 11y agoThe problem I have with this line, is it ignores the dealing with mutable state you already do on a daily basis. Are you confused that the listing on hackernews changes depending on time of day? Why would you be confused that a call to "incrementCounter" changes the value of the counter? Or that a call to "printf" adds to the output? I agree that having a large function where the value of something changes at the top and at the bottom can be confusing. But so can a function where you have two variables of type String because you had to sanitize the input and assign it to a new variable. Are there ways to avoid that particular error. Certainly. Yet I have encountered that about as many times lately as I have encountered "mutable" based errors.