Daniel Sobral writes about ”Bugs, TDD and Functional Programming”. Hey says that debugging a shelve is easier than debugging software because for the physical shelve you can look at each part separately. For software, this is usually more difficult. But:
I see both TDD and functional programming as ways to change that. For TDD, […] If some bug shows up (in the test), then it must be related to the change you just made. Since changes are supposed to be small if you do it right, then the code path you must follow to find the bug should be quite restricted.
The same holds for functional programming […]. A program in functional programming is supposed to be a composition of functions, and each function should be referentially transparent — side-effect free.
Add both together, and software starts looking a lot more like building an airplane or a bridge.
Since using TDD, I often observed that I tend to write code in a more functional style. It is natural to implement the requirements of an isolated test by writing production code without outside dependencies a.k.a. side-effect free code.
One more reason to get familiar with functional programming.