Functional Programming in C#: Classic Programming Techniques for Modern Projects

CHANGE IS GOOD — NOT!

The idea behind persistent data structures is simple. For a particular purpose — perhaps a thread of execution, a process, a function, a single algorithm implementation, in other words, any unit of work (in the literal, not the Martin Fowler sense of the term) — it would be useful to know that the data used by that unit of work couldn’t change. That means it couldn’t change from the perspective of that unit of work. It might appear to have changed when looked at from a different angle; that’s fine. But the unit of work should be able to perform its task from beginning to end with no concern for potential changes to the data it works with. If data structures guarantee that behavior, they are called persistent.

A style of programming that uses only persistent data structures has a lot of practical advantages. To begin with, code is easier to write if no provision has to be made for the case where unexpected things happen in the middle of an algorithm. Simpler code structures result in fewer programming errors, better maintainability, stronger encapsulation, and easier and more error-proof debugging and testing. The whole idea of side-effect free programming, as favored by functional programming in general, is brilliantly supported by the idea of immutable data, and as a result, functions that use immutable data and persistent data structures exclusively are a pleasure to parallelize and modularize without any concern for execution order, locking, and similar ...