4 ms·

Actually, FP and OO are mutually exclusive to some degree: OO comes from the imperative end of the spectrum (after all, objects are an abstraction over mutable

by cygx 13y ago

Actually, FP and OO are mutually exclusive to some degree: OO comes from the imperative end of the spectrum (after all, objects are an abstraction over mutable state), whereas FP comes from the declarative end (a pure function is a relation between sets and mutability is a foreign concept). However, most programming languages are impure and support both paradigms, so you can get away with thinking about OO and FP as orthogonal ways to reason about and structure your code; language syntax and semantics may of course favour one concept over the other...

bad_user 13y ago
OOP is not about hiding / dealing with mutable state, although it can be used that way, but that's a perverted idea of what OOP is. OOP is about subtype polymorphism [1] by means of runtime single-dispatch [2] and modularity, as in abstract modules or components that help with decoupling, a notion supported explicitly by SML, or exemplified beautifully in the Cake-pattern used in Scala. [1] https://en.wikipedia.org/wiki/Subtyping https://en.wikipedia.org/wiki/Subtyping [2] https://en.wikipedia.org/wiki/Single_dispatch https://en.wikipedia.org/wiki/Single_dispatch
- cygx 13y ago
  For me, OO means stateful objects communicating by message passing, and same as asdasf, I consider it a way to structure imperative code. I don't consider this a perversion - it goes back to Kay. Your definition is of course an equally valid one that might be more appropriate in certain contexts - it just doesn't fit my mental model of computation equally well.
  - chipsy 13y ago
    I've developed the opinion, based in large oart on Kay's thinking, that the biggest wins of OO are better represented as a form of protocol design. The point of impedance comes in when you discover that not all protocols map cleanly to OO systems - some are synchronous and others asynchronous, some require more polymorphism than others, etc. Async message passing happens to be one of the more flexible mechanisms for protocol design, but it's only been relatively recently that industry languages have been considering it more carefully, and then it's framed as "concurrency" and not a general architectural consideration. Likewise I see FP as a reactionary mechanism to write fewer and simpler protocols, because when the data is immutable the problem can usually be greatly simplified.
- munificent 13y ago
  > OOP is about subtype polymorphism [1] by means of runtime single-dispatch I believe CLOS would beg to differ.
  - cgore 13y ago
    Other than that I would agree with him though. Subtype polymorphism + runtime (single or multiple) dispatch. Multiple dispatch is one of the things I really miss about Common Lisp. I do like OOP, but often the most intuitive way to think about something is multiple dispatch, and trying to shove it into a single dispatch model can produce some really ugly code. I'm pretty sure that is the main reason there are so many anti-OOP zealots in the world. Also, I didn't realize Dylan had multiple dispatch. I should take a look at it sometime.
    - andrewflnr 13y ago
      Clojure does, too.
- seanmcdirmid 13y ago
  OOP is most definitely defined by encapsulation of state into objects that have identities. There are many points to deal with messaging, on the other hand, as well as polymorphism, which are all compatible with what OO is from a design perspective. Otherwise, the anthropomorphic properties of the object are no longer sustainable, and it's noun-ness disappears. The cake pattern has as much to do with encapsulation as it does crosscut composition.
andolanra 13y ago
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.
- shadowfox 13y ago
  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.
  - silentOpen 13y ago

by cygx 13y ago

bad_user 13y ago

OOP is not about hiding / dealing with mutable state, although it can be used that way, but that's a perverted idea of what OOP is. OOP is about subtype polymorphism [1] by means of runtime single-dispatch [2] and modularity, as in abstract modules or components that help with decoupling, a notion supported explicitly by SML, or exemplified beautifully in the Cake-pattern used in Scala. [1] https://en.wikipedia.org/wiki/Subtyping https://en.wikipedia.org/wiki/Subtyping [2] https://en.wikipedia.org/wiki/Single_dispatch https://en.wikipedia.org/wiki/Single_dispatch

cygx 13y ago
For me, OO means stateful objects communicating by message passing, and same as asdasf, I consider it a way to structure imperative code. I don't consider this a perversion - it goes back to Kay. Your definition is of course an equally valid one that might be more appropriate in certain contexts - it just doesn't fit my mental model of computation equally well.
- chipsy 13y ago
  I've developed the opinion, based in large oart on Kay's thinking, that the biggest wins of OO are better represented as a form of protocol design. The point of impedance comes in when you discover that not all protocols map cleanly to OO systems - some are synchronous and others asynchronous, some require more polymorphism than others, etc. Async message passing happens to be one of the more flexible mechanisms for protocol design, but it's only been relatively recently that industry languages have been considering it more carefully, and then it's framed as "concurrency" and not a general architectural consideration. Likewise I see FP as a reactionary mechanism to write fewer and simpler protocols, because when the data is immutable the problem can usually be greatly simplified.
munificent 13y ago
> OOP is about subtype polymorphism [1] by means of runtime single-dispatch I believe CLOS would beg to differ.
- cgore 13y ago
  Other than that I would agree with him though. Subtype polymorphism + runtime (single or multiple) dispatch. Multiple dispatch is one of the things I really miss about Common Lisp. I do like OOP, but often the most intuitive way to think about something is multiple dispatch, and trying to shove it into a single dispatch model can produce some really ugly code. I'm pretty sure that is the main reason there are so many anti-OOP zealots in the world. Also, I didn't realize Dylan had multiple dispatch. I should take a look at it sometime.
  - andrewflnr 13y ago
    Clojure does, too.
seanmcdirmid 13y ago
OOP is most definitely defined by encapsulation of state into objects that have identities. There are many points to deal with messaging, on the other hand, as well as polymorphism, which are all compatible with what OO is from a design perspective. Otherwise, the anthropomorphic properties of the object are no longer sustainable, and it's noun-ness disappears. The cake pattern has as much to do with encapsulation as it does crosscut composition.

andolanra 13y ago

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.

shadowfox 13y ago
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.
- silentOpen 13y ago