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 to be orthogonal ?

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. Does that meant they are orthogonal ?

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

Answer 1

The term "orthogonal" comes from maths, where it has a synonym: "perpendicular". In this context, you could understand it as "the two things have nothing to do with each other."

When people compare FP and OO they often confuse two separate axes.

On the one hand you have functional programming versus imperative programming. Jonas gives a good comparison of the two. The one-sentence version says that "data flow versus control flow".

The other axis is data abstraction. Languages like Haskell use abstract data types to, well, abstract data. Smalltalk uses objects, which fuse the data and operations on that data into a single unit. William Cook explains better than I could in his paper On Understanding Data Abstraction, Revisited.

It's perfectly understandable that most people end up thinking that FP and OO are opposites: most OO languages are imperative, so if you compare, say, Haskell and Java, you have data flow + ADT versus control flow + object. But there are other possibilities! Matthias Felleisen explains how to happily marry FP and OO in his talk Functional Objects.

Answer 2

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 3

Orthogonal roughly means "independent."

So if FP and OO are orthogonal, that means that you can use immutability whether you use objects or not, and you can use objects whether they're immutable or not.

Answer 4

*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 to be orthogonal ?

Wikipedia quote: "Orthogonality guarantees that modifying the technical effect produced by a component of a system neither creates nor propagates side effects to other components of the system."

Simply, it just means that the change to one system does not, and cannot affect a change in the other system.

For example, a car has orthogonal components and controls (e.g. accelerating the vehicle does not influence anything else but the components involved exclusively with the acceleration function. It does not affect radio for example (although I'm not sure whether it affect CD playing, since mine does skip sometimes)).

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. Does that meant they are orthogonal ?

Kinda. The problem is that none of these concepts are really rock hard defined. But yes, you got the gist of it.