You can have pure objects, depending on how you define 'object'. If your conception of object-oriented programming involves mutable objects changing state in response to messages... then yes, FP and OO are strongly at odds. However, if your conception of object-oriented programming involves information hiding via packaging functionality into units called 'objects' that expose public operations which are written in terms of some manner of implicit or explicit 'self' parameter... why not? That's what OCaml has, after all, and there was even an O'Haskell at one point[1].
Unfortunately, discussions on the merits of FP versus OOP tend to be asinine just because every participant has their own personal definition of both 'functional programming' and 'object-oriented programming', often based on implementations in a particular language. How does Haskell's idea of FP compare to Java's idea of OOP? What about Agda versus Python? Erlang versus Smalltalk? Does FP require purity, or types, or pattern matching?[2] Does OOP require inheritance, or private members, or classes? Without knowing these details, who can even tell what schools are being advocated or why?
[1]: In OCaml, objects can contain mutable values but they must be explicitly marked as such. An object with no mutable values is effectively a pure object, and there are many good reasons to use such an object—analogous objects are useful even in other languages not traditionally considered functional, e.g. new PureObject().someMethod().otherMethod() creates a series of objects which themselves needn't expose a stateful interface at all.
[2]: I'm not asserting that FP requires these things, but I have seen discussions where people clarify that languages can't be functional without function composition or algebraic data types or typeclasses or what-have-you, usually working off an informal definition of 'functional language' based on their language of first exposure.
Now you have made me curious. Do you have any pointers to some source material about "pure objects"?
I find it especially interesting because under normal circumstances an object with no mutable state is no different from a collection of methods (which can be encapsulated in different ways of course; say as an OCaml module).
So I am curious as to what advantage an object system that allows only pure objects provide.
The William Cook paper 'On Understanding Data Abstraction' gives a basic formulation of pure objects. Crucially, an 'object' needn't be what the language itself calls an object, e.g. I could write up a 'set object' in Haskell, which does not have objects:
data Set elem = Set { contains :: elem -> Bool }
insert :: (Eq elem) => elem -> Set elem -> Set elem
insert key set = Set { contains = c }
where c key' = if key == key' then True else contains set key
union :: (Eq elem) => Set elem -> Set elem -> Set elem
union set1 set2 = Set { contains = c }
where c key = contains set1 key || contains set2 key
emptySet :: Set elem
emptySet = Set { contains = (\ _ -> False) }
-- mySet corresponds to {1,2,3}
mySet :: Set Int
mySet = insert 3 (insert 2 (insert 1 emptySet))
-- myVal is True
myVal :: Bool
myVal = contains mySet 2
Depending on your definition of object-oriented programming, this could be considered an object or something else. William Cook argues that it's an object because access depends only on a public interface, i.e. I could add another implementation
fromList :: (Eq elem) => [elem] -> Set elem
fromList list = Set { contains = c}
where c key = key `elem` list
which uses a different representation underneath the surface, but the previous implementations of union and insert will work with it because it exposes the same interface... which is not the case with ML/OCaml modules, which must select a single implementation. This is a simplified version of the example Cook himself uses, so I urge you to read the paper if you want to understand more. (On the other hand, people in the Smalltalk/Ruby/&c camp will say, "No, of course that's not object-oriented—you're not sending messages!" So... it's a complicated debate.)
If you have only pure objects, you can still perform open recursion and leverage structural polymorphism (including row variables). Additionally, your objects are just values and, because they aren't mutable, can be held for backtracking.
For instance:
```ocaml
class virtual biggable x = object val x = x method x : int = x method virtual embiggen : biggable end
let o = object (self) inherit biggable 0 method embiggen = {< x = x + 1 >} end
let q f o = object (self) val x = o#x method x = x method embiggen = f {< x = x * 2 >} end
let a = q (q (fun x -> object inherit biggable x#x method embiggen = {< >} end)) o#embiggen
;;
# a#x;;
- : int = 1
# a#embiggen#x;;
- : int = 2
# a#embiggen#embiggen#x;;
- : int = 4
# a#embiggen#embiggen#embiggen#x;;
- : int = 4
```
> In OCaml, objects can contain mutable values but they must be explicitly marked as such.
Or in Scala, you have to mark object's variables either as `val` (immutable) or `var` (mutable).
Like /u/Fishkins said, the Scala course in Coursera gives some examples of the use of immutable objects ( https://www.coursera.org/course/progfun ). I am sure they are used in a lot of places in Scala code, not only in Odersky's course.
Unfortunately, discussions on the merits of FP versus OOP tend to be asinine just because every participant has their own personal definition of both 'functional programming' and 'object-oriented programming', often based on implementations in a particular language. How does Haskell's idea of FP compare to Java's idea of OOP? What about Agda versus Python? Erlang versus Smalltalk? Does FP require purity, or types, or pattern matching?[2] Does OOP require inheritance, or private members, or classes? Without knowing these details, who can even tell what schools are being advocated or why?
[1]: In OCaml, objects can contain mutable values but they must be explicitly marked as such. An object with no mutable values is effectively a pure object, and there are many good reasons to use such an object—analogous objects are useful even in other languages not traditionally considered functional, e.g. new PureObject().someMethod().otherMethod() creates a series of objects which themselves needn't expose a stateful interface at all.
[2]: I'm not asserting that FP requires these things, but I have seen discussions where people clarify that languages can't be functional without function composition or algebraic data types or typeclasses or what-have-you, usually working off an informal definition of 'functional language' based on their language of first exposure.