Pure functional programming<\/a> views all programs as collections of functions that accept arguments and return values. Unlike imperative and object-oriented programming<\/a>, it allows no side effects and uses recursion instead of loops for iteration. The functions in a functional program are very much like mathematical functions because they do not change the state of the program. In the simplest terms, once a value is assigned to an identifier it never changes, functions do not alter parameter values, and the results that functions return are completely new values. In typical underlying implementations, once a value is assigned to an area in memory, it does not change. To create results, functions copy values and then change the copies, leaving the original values free to be used by other functions and eventually be thrown away when no longer needed. (This is where the idea of garbage collection originated.)<\/p>\n The mathematical basis for pure functional programming<\/a> is elegant, and FP therefore provides beautiful, succinct solutions for many computing problems, but its stateless and recursive nature makes the other paradigms convenient for handling many common programming tasks. However, one of F#\u2019s great strengths is that you can use multiple paradigms and mix them to solve problems in the way you find most convenient.<\/p>\n When people think of functional programming, they often view its statelessness as a fatal flaw without considering its advantages. One could argue that since an imperative program<\/a> is often 90 percent assignment, and a functional program has no assignment, a functional program could be 90 percent shorter. However, not many people are convinced by such arguments or attracted to the ascetic world of stateless recursive programming, as John Hughes<\/a> pointed out in his classic paper \u201cWhy Functional Programming Matters.\u201d<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":"Why Is Functional Programming Important?<\/h4>\n