Out of the Tar Pit ⚡️
Last updated
Last updated
Link to the paper: Out of the Tar Pit
Complex systems are hard to understand and take up huge costs to make any meaningful change. Complexity by state is a particularly interesting one and is solved by any functional language(Clojure, Scala).
The argument against state is it never tells you anything about the behaviour of the same system in a different state. This makes the system incredibly hard to reason about as there it becomes harder to understand each possible state we add.
Now imagine a simple function that makes a map taking a few inputs; as the state of each input changes, it'll be incredibly hard to understand what to expect from the function. The number of results increases with each additional input and thus make the system complex.
Understanding a system "from the inside" for the developer will become harder with each additional state. It can leak into almost stateless components, making the system prone to bugs that are hard to find.
The Ideal way to design is to start asking "what is unavoidable?" The answer to this is decided by the requirement and everything else is accidental.
A visual representation of a system should show the following:
A self-contained state with no reference called essential state
Business rules or logic that only refers to the essential state called essential logic
Finally, the accidental complexities that should be kept separate from essential components and take reference from them.
Functional programming makes it easy to write such code, as it makes it harder to spawn state everywhere in the system.
