Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 ?

share|improve this question
5  
Object-orientation doesn't require objects to manipulate its state. Methods can return new objects as results. The fact that one can, and often does, modify an object's state doesn't mean they have to or that it's a good idea. OO and FP are not opposites. –  Huperniketes Oct 16 '10 at 16:43
4  
Duplicate on stackoverflow: FP and OO orthogonal ? –  sepp2k Oct 16 '10 at 17:58

4 Answers 4

up vote 19 down vote accepted

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.

share|improve this answer
    
+1, great answer. Your answer misses on Haskell typeclasses though. –  missingfaktor Oct 17 '10 at 4:55
    
For sure. I've only just started actually learning Haskell. –  Frank Shearar Oct 17 '10 at 7:46
    
I wonder if there's any recording of that Functional Objects presentation... I'm really interested, but slides alone don't really do it justice. –  Rei Miyasaka Jul 6 '11 at 9:31

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.

share|improve this answer
1  
"Independent" is a good way to put it. It's not that they're opposites, but whether your code is a functional programming style or an object oriented programming style are two separate things. Think of them like the x and y axes on a graph -- you can move up and down one while staying fixed on the other. (In the mathematical sense, a vector in the x-direction and a vector in the y-direction are literally orthogonal -- the CS definition is related.) –  Tim Goodman Oct 16 '10 at 20:23

*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.

share|improve this answer

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.

share|improve this answer
1  
"It means that the two concepts do not have contrasting ideas or are not incompatible with each other." -- That's true, but I think I would say something like "distinct but not incompatible". For instance, if one was a subset of the other then they wouldn't be incompatible, but they also wouldn't be orthogonal. –  Tim Goodman Oct 16 '10 at 20:39
    
@Tim: That was my [maybe failed] attempt at defining the term. I am not an English guru you see. :-| –  missingfaktor Oct 17 '10 at 4:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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