Plain-language example of how a functional style makes parallel programming easier
I'm not sure functional programming does make parallel programming any easier, when taken in the round.
If you program in a &quot;functional style&quot; (including all so-called good practices), then converting certain steps of a serial program to parallel execution (and getting results that are equivalent to the serial execution) may not usually involve much further difficulty, but that is primarily because all the difficulty has already been imposed in drafting the program in a form where it doesn't matter whether many steps are executed serially or in parallel.
Moreover, functional programming does not claim to guarantee that a serialised execution of a program actually produces &quot;correct&quot; (i.e. intended) results for all inputs, only that parallelised execution will involve no additional error.
In general, business systems have an irreducible need to mutate state and shared data, so any benefit or guarantee that depends in theory on not mutating state at all, can be dismissed out of hand as almost worthless to real-world development.
If the point at which state is mutated is seen as a boundary across which the guarantees of functional programming cease to apply, then the vast majority of programs can get almost nothing done before having to cross a boundary and step outside such guarantees.
Many people seem to over-estimate how much error actually occurs in systems due to race conditions etc. involving unnecessary mutations, rather than errors which involve the necessary mutations of shared data that must occur equally in functional programs as in non-functional ones.
Arguably, a real benefit of functional programming is that it allows certain kinds of functionality (especially complex calculations) to be implemented more quickly or to a more complex extent, at the price of a higher initial learning curve.
In other words, it will allow the best programmers to work a little faster once experienced, or get a little further than before with the most complex systems, at the expense of requiring far more training and experience to begin with, and excluding third-rate programmers from getting anywhere at all.
This, however, is not the typical understanding people have of the word &quot;easier&quot;, or of a tool that &quot;makes things easy&quot;. I contend that functional programming may improve productivity in some cases, but it does so by increasing the threshold of difficulty in many respects.