I've heard a lot of talk about using functional languages such as Haskell as of late. What are some of the big differences, pros and cons of functional programming vs. object-oriented programming?
-
28One does not reject another.– mbqCommented Oct 5, 2010 at 19:27
-
1@mbq i understand that they aren't mutually exclusive, but I just wanted to try to get a better understanding of the difference of the two approaches.– GStoCommented Oct 5, 2010 at 19:52
-
Great question. I've been wondering about this too.– JohnFxCommented Oct 5, 2010 at 20:57
-
Functional programming and object-oriented programming are orthogonal to each other. You can have both in the same language. Examples: Scala, F#, OCaml etc. Maybe you meant functional vs imperative, as Jonas suggested?– missingfaktorCommented Oct 16, 2010 at 9:22
-
4The real answer is - theres's no "versus" between them. Check out this question at StackOverflow.– missingfaktorCommented Oct 18, 2010 at 3:03
5 Answers
I would say that it is more Functional Programming vs Imperative Programming.
The biggest difference is that Imperative programming is about Control flow while Functional programming is about Data flow. Another way to say it is that functional programming only uses expressions while in imperative programming both expressions and statements are used.
For example, in imperative programming variables and loops are common when handling state, while in functional programming the state is handled via parameter passing, which avoids side-effects and assignments.
Imperative pseudo-code for a function for calculate the sum of a list (the sum is kept in a variable):
int sumList(List<int> list) {
int sum = 0;
for(int n = 0; n < list.size(); n++) {
sum = sum + list.get(n);
}
return sum;
}
Functional pseudo-code for the same function (the sum is passed as a parameter):
fun sumList([], sum) = sum
| sumList(v::lst, sum) = sumList(lst, v+sum)
I recommend the presentation Taming Effects with Functional Programming by Simon Peyton-Jones for a good introduction to functional concepts.
-
13You should mention that the functional version is tail-recursive and thus optimized to avoid stack overflows. (Some people might see the recursion and think that functional programming is bad because of it) Commented Oct 5, 2010 at 22:36
-
3+1 for describing the most important aspect of imperative vs. functional: control flow vs data flow. One thing I have to add is that functional paradigm and OO paradigm is not mutually exclusive; you can use OO paradigm to model how object (data) interacts, and functional paradigm to transform (manipulate) that object.– Lie RyanCommented Oct 6, 2010 at 10:19
-
1Interestingly, you can model data-as-control and control-as-data as well to intermix. FP can use Arrows and first order functions to pass control flow around and manipulate it like data. OOP uses various design patterns to use objects for altering control flow. Commented Nov 1, 2010 at 15:05
-
I think it's also worth noting that the main difference isn't that you write the same program but you make your loops tail-recursive method calls. it's way larger than that– saraCommented May 1, 2016 at 18:33
-
Your functional example makes use of parameter pattern-matching. That isn't exclusive to functional programming, similarly functional programs can use monads and even imperative-like constructs without necessarily needing to formulate every iterative algorithm as a recursive algorithm.– DaiCommented Oct 5, 2017 at 9:38
Functional programming is based on a declarative model and has its roots from lambda calculus. It offers a lot of great concepts which can be borrowed from more imperative languages like C++ and C#.
Some examples include referential transparency, lambda functions, first class functions, lazy and eager evaluation, and immutability.
If for nothing else learning functional programming is useful for the concepts that it contains. It will change the way you do programming and think about programming. And I would guess that in the future functional programming will be just as important as object oriented programming has been.
To get started you can chose to use a pure functional language such as Haskell, or you can use a hybrid one like F#.
Most good universities will cover functional programming and if you go to school I'd highly suggest you take that course.
What are some of the big differences, pros and cons of functional programming vs. object-oriented programming?
Well object oriented programming is nice because it allows you to model your complex problem into hierarchies so you can simplify the problem. But it becomes very hard when you start to consider multi threaded programming while using mutable objects. In such cases you need to use heavy use of synchronization objects and it's near impossible to perfect a large application.
That's where functional programming comes in. Because of things like immutability functional programming really simplifies multi threaded programs. It makes it almost trivially easy to parallelize something when you know that given input X to a function it will always output Y. Also you know that a variable (or value in functional programming) can't change mid use from another thread.
-
2To be clear, Scheme is by no means a pure functional language. Commented Oct 6, 2010 at 1:11
-
5Your second last paragraph is completely bs. OO doesn't pose any problems in multithreading, mutability does. You seem to be confusing imperative programming with object-oriented programming. Is that the case? Commented Oct 16, 2010 at 15:02
-
5@missingfaktor: No I am not confusing the concepts. An object typically has accessors, modifiers, data members and member functions. Yes not all objects need to have modifiers and you can implement them as immutable. But if you look at any arbitrary OO program, it will almost certainly have several objects which have modifiers and yet are still used by multi threads. I.e. in an OOP paradigm it's pretty rare to have everything immutable. Commented Oct 16, 2010 at 22:24
-
You should read the answers to this question: stackoverflow.com/questions/3949618/fp-and-oo-orthogonal/… Commented Oct 17, 2010 at 4:28
-
Also check Frank Shearar's answer here: programmers.stackexchange.com/questions/12423/… Commented Oct 17, 2010 at 4:57
(This answer is adapted from an answer to a closed question at StackOverflow.)
One of the big differences between functional programming and object-oriented programming is that each one is better at a different kind of software evolution:
Object-oriented languages are good when you have a fixed set of operations on things, and as your code evolves, you primarily add new things. This can be accomplished by adding new classes which implement existing methods, and the existing classes are left alone.
Functional languages are good when you have a fixed set of things, and as your code evolves, you primarily add new operations on existing things. This can be accomplished by adding new functions which compute with existing data types, and the existing functions are left alone.
When evolution goes the wrong way, you have problems:
Adding a new operation to an object-oriented program may require editing many class definitions to add a new method.
Adding a new kind of thing to a functional program may require editing many function definitions to add a new case.
This problem has been well known for many years; in 1998, Phil Wadler dubbed it the "expression problem". Although some researchers think that the expression problem can be addressed with such language features as mixins, a widely accepted solution has yet to hit the mainstream.
-
I love your answer, word of wisdoms here. I met it a few months ago and just spent 30 minutes specifically looking for it as I didn't bookmark it. Just the best explanation on OOP vs FP for those who understand the advantage of understanding concepts rather than techniques. The paper about the expression problem is also fantastic. Thanks a lot for sharing your insight, your answer is very underrated in my opinion. Commented Jan 15, 2016 at 20:48
There is no real versus. They can be perfectly complementary. There are FP languages, which support OOP. But the communities differ in the way they handle modularity.
Users of FP languages tend to achieve modularity through mathematical laws. And prefer proofs to show compliance with their laws.
In imperative OOP users tend to capture the behaviour of the object in test-cases, which can be rerun if the object has changed and achieve in this way modularity.
It is just a small aspect, but I think it is worth mentioning.
An analogy:
You're handed a job application. You fill in your name, contact information, and work history. When you're finished you no longer have a blank application.
Now imagine instead that before writing you overlay it with a clear sheet of cellophane. You write your name. You add another sheet of cellophane. You write your contact information. More cellophane. You write your work history. When you're finished you still have the blank application untouched. You also have three sheets of cellophane each having captured the effect of a single, discrete change.
The former (OOP) embraces the idea of changing things in place while the latter (FP) shuns it. Both are state management paradigms. Both can, using different strategies, capture the effect of completing a job application. OOP changes the starting instrument directly, while FP overlays what came before to effect the appearance of change.
-
beautiful analogy, thx !! would you mind (if possible) extending this analogy with pros and cons in these two approaches. Commented Nov 5, 2018 at 9:44