I could go on for a week but here’s some copypasta that mirrors why I wrote this (sorry not to write an essay in my own words). Honestly, there’s a lot more than listed here (like the inherent ability to parallelize any functional code basically out of the box) but let us take a stab at comparing them:
The functional programming paradigm was explicitly created to support a pure functional approach to problem solving. Functional programming is a form of declarative programming. In contrast, most mainstream languages, including object-oriented programming (OOP) languages such as C#, Visual Basic, C++, and Java, were designed to primarily support imperative (procedural) programming.
With an imperative approach, a developer writes code that specifies the steps that the computer must take to accomplish the goal. This is sometimes referred to as algorithmic programming. In contrast, a functional approach involves composing the problem as a set of functions to be executed. You define carefully the input to each function, and what each function returns.
Advantages of pure functions
The primary reason to implement functional transformations as pure functions is that pure functions are composable: that is, self-contained and stateless. These characteristics bring a number of benefits, including the following:
Increased readability and maintainability. This is because each function is designed to accomplish a specific task given its arguments. The function doesn't rely on any external state.
Easier reiterative development. Because the code is easier to refactor, changes to design are often easier to implement. For example, suppose you write a complicated transformation, and then realize that some code is repeated several times in the transformation. If you refactor through a pure method, you can call your pure method at will without worrying about side effects.
Easier testing and debugging. Because pure functions can more easily be tested in isolation, you can write test code that calls the pure function with typical values, valid edge cases, and invalid edge cases.
I edited my comment to talk about imperative vs FP rather than OO vs FP because FP can actually be OO. What I meant was imperative.
Anyway, in most functional implementations, state is usually handled by a minimal top layer. Functional paradigms are helpful in keeping the complexity to a minimum.
I like to use the functional core, imperative wrapper design style.
I could go on for a week but here’s some copypasta that mirrors why I wrote this (sorry not to write an essay in my own words). Honestly, there’s a lot more than listed here (like the inherent ability to parallelize any functional code basically out of the box) but let us take a stab at comparing them:
The functional programming paradigm was explicitly created to support a pure functional approach to problem solving. Functional programming is a form of declarative programming. In contrast, most mainstream languages, including object-oriented programming (OOP) languages such as C#, Visual Basic, C++, and Java, were designed to primarily support imperative (procedural) programming. With an imperative approach, a developer writes code that specifies the steps that the computer must take to accomplish the goal. This is sometimes referred to as algorithmic programming. In contrast, a functional approach involves composing the problem as a set of functions to be executed. You define carefully the input to each function, and what each function returns.
Advantages of pure functions
The primary reason to implement functional transformations as pure functions is that pure functions are composable: that is, self-contained and stateless. These characteristics bring a number of benefits, including the following:
Increased readability and maintainability. This is because each function is designed to accomplish a specific task given its arguments. The function doesn't rely on any external state.
Easier reiterative development. Because the code is easier to refactor, changes to design are often easier to implement. For example, suppose you write a complicated transformation, and then realize that some code is repeated several times in the transformation. If you refactor through a pure method, you can call your pure method at will without worrying about side effects.
Easier testing and debugging. Because pure functions can more easily be tested in isolation, you can write test code that calls the pure function with typical values, valid edge cases, and invalid edge cases.
What stops you writing pure functions in OO? Like linq in C#
And where does your state go? How would a list of products be represented in FP?
Do you have some examples of full applications written functionally?
I edited my comment to talk about imperative vs FP rather than OO vs FP because FP can actually be OO. What I meant was imperative.
Anyway, in most functional implementations, state is usually handled by a minimal top layer. Functional paradigms are helpful in keeping the complexity to a minimum.
I like to use the functional core, imperative wrapper design style.
Right yeah.
Many OO languages lean into FP heavily as well.