6 ms·

I'm a bit confused. I always thought that FP and OO were orthogonal concepts and never considered them mutually exclusive. To me, the antitheses of FP would be

I'm a bit confused. I always thought that FP and OO were orthogonal concepts and never considered them mutually exclusive. To me, the antitheses of FP would be imperative programming. Maybe I'm missing something? CLOS, OCaml, Scala, I can think of many examples of languages that include components of both FP and OO. Or maybe we're simply considering that OO means this special paradigm used in C++/C#/Java (that really only claims to be the true and only OOP by the commercial entities backing these languages)? PS: I googled around a bit, this Clojure article [1] seems relevant. [1]: http://clojure.org/state http://clojure.org/state

fogus 13y ago
> never considered them mutually exclusive. I never implied mutual exclusion.
- pr0filer__ 13y ago
  I'de say versus implies mutual exclusion
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.
- 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
asdasf 13y ago
The antithesis of FP is imperative. And OOP is imperative. Imperative programming encompasses both procedural and object oriented programming. Those are simply two different ways to structure an imperative program.
- cygx 13y ago
  I'd hesitate to call imperative the antithesis of FP: It's imperative vs declarative - FP is on a different level of abstraction, as a sibling to, let's say, logic programming.
  - asdasf 13y ago
    >It's imperative vs declarative Good point, I think the common tendency to refer to procedural programming as either procedural or imperative interchangeably got me doing the same thing with functional and declarative.
  - bad_user 13y ago
    I'd hesitate to say that FP is on the same level as logic programming, or to say that it is declarative. It really depends on what you mean by FP. If you refer to lambda-calculus or to say, the head/tail decomposition so common in FP, then those are inherently sequential and not really declarative. If you refer to functors / monads, then you're on to something, but then again, OOP doesn't really imply imperative.

fogus 13y ago

> never considered them mutually exclusive. I never implied mutual exclusion.

pr0filer__ 13y ago
I'de say versus implies mutual exclusion

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

asdasf 13y ago

The antithesis of FP is imperative. And OOP is imperative. Imperative programming encompasses both procedural and object oriented programming. Those are simply two different ways to structure an imperative program.

cygx 13y ago
I'd hesitate to call imperative the antithesis of FP: It's imperative vs declarative - FP is on a different level of abstraction, as a sibling to, let's say, logic programming.
- asdasf 13y ago
  >It's imperative vs declarative Good point, I think the common tendency to refer to procedural programming as either procedural or imperative interchangeably got me doing the same thing with functional and declarative.
- bad_user 13y ago
  I'd hesitate to say that FP is on the same level as logic programming, or to say that it is declarative. It really depends on what you mean by FP. If you refer to lambda-calculus or to say, the head/tail decomposition so common in FP, then those are inherently sequential and not really declarative. If you refer to functors / monads, then you're on to something, but then again, OOP doesn't really imply imperative.