Code is a mess. This is a universal truth, akin to the notion that this is not ever the Cub's year or that a single man in possession of a good fortune must be in want of a wife. Much ink and many pixels have been spilled in the rather futile and sometimes desperate attempt to make this not the case. But decade into the programing revolution, any code more complicated that "Hello World" appears to tend toward maximum entropy, a convoluted mess of chop logic and spaghetti. It is enough to make a grown person cry, or latch onto a supposed solution. Vikram Chandra is the latest in a distinguished line of thinkers who believes he has the solution. Chandra's point is well written, well reasoned and wrong.
Chandra's point is that the need to keep state, the need to keep track of what changes have been made and what shape the acted upon data is currently in, causes needless complications in code. This is undoubtedly true, based on my own experience. Keeping track of state means storage, timing, and access controls becomes critical parts of the system. Unfortunately, those three items, especially the last, can be complicated to implement and often come with complicated if not contradictory business rules that also need to be implemented. Chandra's solution is something called event sourcing:
That is, you reconstitute the state of an object by creating a new object and then “replaying” events over it. Ted now has the most current version of invoice 56847, conjured up through a kind of temporally shifted rerun of events that have already happened. In this new system, history is never lost; when Ted adds a line item, a “LineItemAdded” event will be generated, and when he deletes one, a “LineItemDeleted” event will be stored.
If, at some point in the future, you wanted to know what the invoice looked like on Wednesday morning, you would just fire off your “Replay” routine and tell it to cease replaying events once it got past 9 a.m. on Wednesday morning.
The above is mostly true as far as it goes. But it doesn't go very far. Notice that state is still a pat of this system: it just happens to be part of the central system. Any system that to enforce conditional business rules has to be able to determine the state of the system. In even sourcing, that state isn't stored in a moment in time, but rather can be reconstructed via time-stamped series of captured events. The part of the system that has to enforce conditional business rules must replay the entirety of the event history to determine if a rule should be followed. This isn't intrinsically cheaper in processing power, storage costs or code complexity. It could be argued that this is merely shifting the location of the complexity. It also doesn't work for all use cases: imagine when someone sends time working on data thinking they are making progress only to have the central system reject the changes. Keeping state can often provide a better user experience.
The point is not that event sourcing is bad. Far form it, actually: I like event sourcing and there are use cases where it makes perfect sense. But code is complex because we don't have programing languages that mirror human thought and because programs are asked to implement complicated rules. Programming is still a craft, as much art as it is science. Doing complicated things, such as mirroring simple to humans rules, often results in complicated code. Combine that with the inevitable pressures of costs and deadlines, and you are almost guaranteed to have complicated code. You can mitigate this effect, but no one mode of programming is going to prevent it.