I'm an Object Oriented programmer looking forward to learning a functional language. My questions are:

  • When do you choose functional programming over object oriented ?
  • What are the typical problem definitions where functional programming is a better choice?
share|improve this question
2  
Sounds like a good candidate for a community wiki... – Jason Down Jan 16 '10 at 21:37
1  
I'm not sure on the wiki idea. This seems like a good thread for a "better answer" that olivier could choose. There could, as far as I know (which isn't much!), also be a "right" answer. Either way though, it's a great question. – Todd Main Jan 16 '10 at 21:41
1  
Whatever, it's a wiki now ;) – Olivier Lalonde Jan 16 '10 at 21:42
okay, i guess it's a wiki now. edit away everyone! – Todd Main Jan 16 '10 at 21:46
Duplicate: stackoverflow.com/questions/552336/… – gnovice Jan 16 '10 at 22:23
feedback

closed as not constructive by Daniel Fischer, Robert Harvey Dec 1 '12 at 16:43

As it currently stands, this question is not a good fit for our Q&A; format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.

5 Answers

up vote 105 down vote accepted

When do you choose functional programming over object oriented?

When you anticipate 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.

What are the typical problem definitions where functional programming is a better choice?

Functional languages excel at manipulating symbolic data in tree form. A favorite example is compilers, where source and intermediate languages change seldom (mostly the same things), but compiler writers are always adding new translations and code improvements or optimizations (new operations on things). Compilation and translation more generally are "killer apps" for functional languages.

share|improve this answer
10  
Can I upvote 10 times? – kizzx2 Sep 8 '11 at 10:09
Seriously, thank you for the this. I think I am now one step closer to The Understanding. – Jonathan Wilson Jun 26 '12 at 10:30
This really is a fantastic answer. – Scott Aug 19 '12 at 6:32
feedback

You don't necessarily have to choose between the two paradigms. You can write software with an OO architecture using many functional concepts. FP and OOP are orthogonal in nature.

Take for example C#. You could say it's mostly OOP, but there are many FP concepts and constructs. If you consider Linq, the most important constructs that permit Linq to exist are functional in nature: lambda expressions.

Another example, F#. You could say it's mostly FP, but there are many OOP concepts and constructs available. You can define classes, abstract classes, interfaces, deal with inheritance. You can even use mutability when it makes your code clearer or when it dramatically increases performance.

Many modern languages are multi-paradigm.

Recommended readings

As I'm in the same boat (OOP background, learning FP), I'd suggest you some readings I've really appreciated:

share|improve this answer
7  
Python can leverage both as well, and you don't even need two languages to do it. Java's JVM supports both OO in Java and FP in Scala .NET isn't the source of all power. – duffymo Jan 16 '10 at 22:04
3  
@duffymo: your comment, the way you put it, is mostly pointless. No one wants a comparison of languages, virtual machines or platforms, thank you. – Bruno Reis Jan 16 '10 at 22:08
1  
@Bruno - a response to "power of .NET". Relax. – duffymo Jan 16 '10 at 22:14
1  
Funny, I don't see you chiding Dykam about his pointless comment. Were you nominated as a moderator while I wasn't looking? Nobody's flaming here except you. I'll say it again - relax. – duffymo Jan 16 '10 at 22:18
2  
Heh, sorry if I started some flaming. I didn't mean to say other platforms are less powerfull, just that .NET doesn't only support OOP. For example it has tail call optimization. – Dykam Jan 16 '10 at 22:26
show 3 more comments
feedback
  1. If you're in a heavily concurrent environment, then pure functional programming is useful. The lack of mutable state makes concurrency almost trivial. See Erlang.

  2. In a multiparadigm language, you may want to model some things functionally if the existence of mutable state is must an implementation detail, and thus FP is a good model for the problem domain. For example, see list comprehensions in Python or std.range in the D programming language. These are inspired by functional programming.

share|improve this answer
feedback

Object Oriented Programming offers:

  1. Encapsulation, to
    • control mutation of internal state
    • limit coupling to internal representation
  2. Subtyping, allowing:
    • substitution of compatible types (polymorphism)
    • a crude means of sharing implementation between classes (implementation inheritance)

Functional Programming, in Haskell or even in Scala, can allow substitution through more general mechanism of type classes. Mutable internal state is either discouraged or forbidden. Encapsulation of internal representation can also be achieved. See Haskell vs OOP for a good comparison.

Norman's assertion that "Adding a new kind of thing to a functional program may require editing many function definitions to add a new case." depends on how well the functional code has employed type classes. If Pattern Matching on a particular Abstract Data Type is spread throughout a codebase, you will indeed suffer from this problem, but it is perhaps a poor design to start with.

EDITED Removed reference to implicit conversions when discussing type classes. In Scala, type classes are encoded with implicit parameters, not conversions, although implicit conversions are another means to acheiving substitution of compatible types.

share|improve this answer
1  
Typeclasses are not a mechanism for implicit conversion to other types. They're a description of a set of functions defined for a type so as to provide a form of polymorphism. The closest thing from Java-style OOP would be interfaces, though Haskell typeclasses have some important differences. – Zak Feb 18 '10 at 8:48
feedback

How you define your object oriented character in development? Is there any case that you are already using FP principles without knowing? Can you tell? If you found something that looks like more fp than oop then that's your answer. Look eval, lambdas, closures, pattern matching and many many more. Do you use any of these concepts? Then, that's where fp code fits in.

share|improve this answer
feedback

Not the answer you're looking for? Browse other questions tagged or ask your own question.