I'm from the haskell universe. It's more than just side effects. A common design issue people hit is that midway through a projects lifetime they hit a feature

I'm from the haskell universe. It's more than just side effects. A common design issue people hit is that midway through a projects lifetime they hit a feature request that is basically a slight permutation of an existing feature. They realize that they cannot reuse the code because of the way they "designed" the program. Ideally you want to reuse existing code, or if no function specifically supports this feature you can encapsulate a relevant line of code into some sort of container so that it can be reused in multiple places. This is a way of decomposing your code, or aka: dividing a function into multiple pieces so components can be deployed in multitudes of other location thereby maximizing code re-use. What happens is that most people realize that no matter how much they plan out a design they cannot execute the decomposition procedure above. A design choice made at the inception of the project fixes the shape of the code and limits flexibility. Thus they do code duplication as a workaround hack. I am saying that this problem is actually caused by mutability. What is seemingly a structural problem only occurs because you have a mutable variable. You can cut your code and divide a primitive into a thousand possible pieces if you wanted too but the minute you have a mutable variable in your code the division cannot be done. Think about it. To surgically remove a mutable variable out of a piece of code you must not just cut out the variable but you must also bring every function or procedure that mutates that variable along for the ride. If your function has an entire network of functions mutating procedures than that function cannot be divided into smaller functions. An immutable function can be cut into a thousand pieces and rebuilt in a different way. This is the best known solution for program design and organization.