Are FP and OO orthogonal?

Question

I have heard this time and again, and I am trying to understand and validate the idea that FP and OO are orthogonal.

First of all, what does it mean for 2 concepts t

Answer 1

You can implement functions as objects and objects as collections of functions, so there is clearly some relationship between the two concepts.

FP encourages immutability and purity as much as possible

You are talking about purely functional programming.

while OO seems built for state and mutation

There is no requirement for objects to be mutable. I would say that objects and mutation were orthogonal concepts. For example, the OCaml programming language provides a syntax for purely functional object update.

A language like Scala makes it easy to do OO and FP both

Not really. The lack of tail call optimization means that the majority of idiomatic purely functional code will stack overflow in Scala because it leaks stack frames. For example, continuation passing style (CPS) and all of the techniques described in the paper That about wraps it up by Bruce McAdam. There is no easy way to fix that because the JVM itself is incapable of tail call optimization.

Regarding the orthogonality of purely functional programming and object oriented programming, I would say that they are at least close to being orthogonal simply because purely functional programming deals only with programs in the small (e.g. higher order functions) whereas object oriented programming deals with the large-scale structuring of programs. This is why functional programming languages usually provide some other mechanism for large-scale structuring, e.g. the higher-order module systems of Standard ML and OCaml, or CLOS for Common Lisp or typeclasses for Haskell.

Answer 2

One thing that helped me understand the relationship between FP and OO was the SICP book, particularly the section "Modularity of Functional Programs and Modularity of Objects" If you are thinking about these issues and you have a spare weekend, it might be worth reading through the first three chapters, its pretty eye opening.

Answer 3

Like all classifications, the division of programming languages into functional, object-oriented, procedural, etc. is fictional. But we do need classifications, and in programming languages we classify by a set of language features and the philosophical approach of those who use the language (where the later is influenced by the former).

So sometimes "object-oriented" languages can have success adopting the features and philosophies of "functional" programming languages and vice-versa. But certainly not all programming language features and philosophies are compatible.

For example, a functional language like OCaml accomplishes encapsulation through lexical scoping and closures, whereas a object-oriented languages use public/private access modifiers. These are not incompatible mechanisms per-se, but they are redundant, and a language like F# (a mostly functional language which seeks to live in harmony with the decidedly object-oriented .NET library and language stack) has to go to lengths to bridge the gap.

As another example, OCaml uses a structural type system for object-orientation, whereas most object-oriented languages use a nominal type system. These are pretty-much incompatible, and interestingly represent incompatibility within the realm of object-oriented languages.

Answer 4

First of all, what does it mean for 2 concepts to be orthogonal ?

It means that the two concepts do not have contrasting ideas or are not incompatible with each other.

FP encourages immutability and purity as much as possible. and OO seems like something that is built for state and mutation(a slightly organized version of imperative programming?). And I do realize that objects can be immutable. But OO seems to imply state/change to me.

They seem like opposites. How does it affect their orthogonality ?

A language like Scala makes it easy to do OO and FP both, does this affect the orthogonality of the 2 methods ?

OO is about encapsulation, object composition, data abstraction, polymorphism via subtyping, and controlled mutation when necessary (immutability is encouraged in OO as well). FP is about function composition, control abstraction, and constrained polymorphism (aka parametric polymorphism). Thus the two ideas are not contradictory. They both provide you with different kinds of powers and abstraction mechanisms, which are certainly possible to have in one language. In fact, this is the thesis on which Scala was built!

In his Scala Experiment talk at Google, Martin Odersky explains it very well how he believes the two concepts - OO and FP - are orthogonal to each other and how Scala unifies the two paradigms elegantly and seamlessly into a new paradigm popularly known in Scala community as object-functional paradigm. Must watch talk for you. :-)

---

Other examples of object-functional languages: OCaml, F#, Nemerle.

Answer 5

Orthogonal. It sounds good. If you got an education you can band it about a bit and pretend. Its a bit like paradigm.

It all depends in which circles you travel in and what each type of programming technique will give you. I have read a few posts on SS and most who come from a functional programming language usual persist on the fact that you can only go functional and anything else goes against the thinking and the mind set.

Object Oriented programming is mainly about capturing state and keeping this state as localised as possible as not to be affected by anything that is not part of the object that you manage the state with. On the other hand, functional programming looks at the problem of state from a different perspective and tries to separate state from the system and reduce it down to functions. Yes you can use both techniques in your code but they both are looking at the design of software from different angles.

There has been a great deal of interest in the techniques of Functional Programming, mainly because of the management required of state when dealing with multi-core chips and parallel programming. It seems at this point in time that functional programming does have the upper hand in dealing with this however you can achieve the same effect using Objects. You just think of the problem differently. Instead of scratching you head, trying to get rid of state as much as possible, you look at objects in the design and see how you can pair them down to what the core of what they are expected to do, using design patterns, CRC and Object Analysis. Where Objects do come into there own though, and where functional programming is a lot more difficult is in analysing the real world and mapping it to an understandable computerised system. In OO for example, a person object would be an encapsulation of state with methods that act upon the persons state. In Functional programming, a person would be broken down into data parts and functions that act upon the person data, with the added proviso that data should be created once and only once and be immutable.

I must admit though coming from an OO background, that in most OO languages when dealing with Multi-core chips, I have gone the functional route, mainly by core programming design structures (such as threads and delegates) and pass pseudo data objects around. This has led me to question the techniques of OO programming as it does not seem to map well to this threaded design.

Answer 6

I’ve just found a wonderful explanation of the orthogonality of OOP and FP.

The basic idea is as follows. Imagine we are working with ASTs of math expressions. So we have different types of nouns (constant, addition, multiplication) and different verbs (eval, toString).

Let’s say, the expression is (1 + 2) * 3. Then the AST would be:

       multiplication
         /        \
     addition      3
      /    \
     1      2

To implement a verb, we have to provide its implementation for every type of noun. We can represent it as a table:

                +---------------------+-------------------------------------+
                | eval                | toString                            |
+---------------+---------------------+-------------------------------------+
| constant      | value               | value.toString                      |
+---------------+---------------------+-------------------------------------+
| addition      | lhs.eval + rhs.eval | lhs.toString + " + " + rhs.toString |
+---------------+---------------------+-------------------------------------+
| mutiplication | lhs.eval * rhs.eval | lhs.toString + " * " + rhs.toString |
+---------------+---------------------+-------------------------------------+

The “orthogonality” comes from the fact, than in OOP we will be implementing this table by rows: we will represent every noun as a class, which will have to implement every method.

In FP, on the other hand, we will implement this table by columns — we will write a function for every verb, and this function will react differently to arguments of different types (using pattern matching probably).