9 ms·

I think OO and FP can coexist peacefully. You just need to pick out their good parts and discard the rest, and use a programming language that allows this. Do

I think OO and FP can coexist peacefully. You just need to pick out their good parts and discard the rest, and use a programming language that allows this. Do put your object in classes, but don't put behaviors there. Use classes to allow static type checking so that functions taking them can guarantee certain field exist. Separate behaviors out into its own module. I'd avoid calling them classes here because there will be confusion. Interactions between objects can be implemented in FP style. This is where you get to use map and reduce. I've been learning about DCI (data context interaction) recently. I can't say I've fully grasped it yet, but it did opened my mind on how to do design differently.

weavejester 13y ago
So just use objects for type-checking? Isn't that just FP with types?
- jbooth 13y ago
  OO itself is just syntactical sugar for standard C structs with functions taking them as args. Substitute in "self" for an additional first argument and you've got FP with types and structs.
  - weavejester 13y ago
    The definition of OOP rather depends on who you ask, but I suspect Alan Kay would disagree with you there :)
    - jbooth 13y ago
      Take a look at some OOP C code sometime. Oh, C doesn't have objects? Sorry, I meant a my_struct{} and a bunch of my_struct_op(struct, otherargs) functions. You seem to be pretty emotionally invested in FP vs any other programming paradigm. I'm more of a "lots of tools in the box" kind of guy.
      - djur 13y ago
        Bundling a set of methods to a struct in C is not full OO. It lacks inheritance/delegation, encapsulation, polymorphism, and message passing, and I don't know of any definition of OO that doesn't insist on at least one of those. Alan Kay's summary is interesting: http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...
      - weavejester 13y ago
        I just meant that people have very different ideas about what OOP means. You seem to have an unusually broad definition, but others, particularly the guy who coined the phrase in the first place, have more specific definitions. In general, most people agree that OOP involves some form of information hiding, which you seem to disagree on. I also wouldn't say I'm particularly emotionally invested in FP, just that I'm very skeptical of OOP as a paradigm. OOP languages tend to promote hidden, mutable state, but visible, immutable values are far more useful.
        jbooth 13y ago
        Fair enough.. if you're talking about a giant class hierarchy with lots of mutable state, then I tend to agree that it doesn't usually lead to good software (although things like java's collections library and the outputstream hierarchy are good exceptions).
hernan604 13y ago
OO and FP coexist peacefully. FP is all about passing functions as parameters into other functions. Its exists on decent languages. Which in case allow OO also. ie. perl, allows all that, and has Moose which allows Class and Roles and Types. So you can build classes like lego, literally.
- nbouscal 13y ago
  > FP is all about passing functions as parameters into other functions. That's a common misconception. First-class functions and higher-order functions are definitely commonly used in functional programming, but they are not what makes it functional programming. As with any paradigm, there is no universally agreed-upon definition, but most functional programmers will likely agree that lack of mutable state and lack of side effects are much more central to functional programming than first-class and higher-order functions. The latter are really just useful and elegant tools to help accomplish the former.
  - Sssnake 13y ago
    Without side effects you couldn't do anything. Pure functional languages make side effects explicit, but it isn't about them being missing.
    - nbouscal 13y ago
      > Without side effects you couldn't do anything. Not true. > Pure functional languages make side effects explicit, but it isn't about them being missing. True. I should have been more clear about that.
      - mturmon 13y ago
        Not a downvoter, but I believe "Without side effects you couldn't do anything" means that any interesting program ultimately has a side effect. The rocket is launched, the form is printed, pi is displayed on the monitor, etc.
chongli 13y ago
Do put your object in classes, but don't put behaviors there. Use classes to allow static type checking so that functions taking them can guarantee certain field exist. Why not just use algebraic data types and modules? Classes are such a verbose, jumbled, complected mess compared to those simpler tools.
- lightblade 13y ago
  > ...algebraic data types and modules Sorry, I not familiar with that term. Can you explain that more?
  - chongli 13y ago
    I would, but I'm afraid my explanation would pale in comparison to the one on Wikipedia. Why not check it out?: http://en.wikipedia.org/wiki/Algebraic_data_type http://en.wikipedia.org/wiki/Algebraic_data_type

weavejester 13y ago

So just use objects for type-checking? Isn't that just FP with types?

jbooth 13y ago
OO itself is just syntactical sugar for standard C structs with functions taking them as args. Substitute in "self" for an additional first argument and you've got FP with types and structs.
- weavejester 13y ago
  The definition of OOP rather depends on who you ask, but I suspect Alan Kay would disagree with you there :)
  - jbooth 13y ago
    Take a look at some OOP C code sometime. Oh, C doesn't have objects? Sorry, I meant a my_struct{} and a bunch of my_struct_op(struct, otherargs) functions. You seem to be pretty emotionally invested in FP vs any other programming paradigm. I'm more of a "lots of tools in the box" kind of guy.
    - djur 13y ago
      Bundling a set of methods to a struct in C is not full OO. It lacks inheritance/delegation, encapsulation, polymorphism, and message passing, and I don't know of any definition of OO that doesn't insist on at least one of those. Alan Kay's summary is interesting: http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...
    - weavejester 13y ago
      I just meant that people have very different ideas about what OOP means. You seem to have an unusually broad definition, but others, particularly the guy who coined the phrase in the first place, have more specific definitions. In general, most people agree that OOP involves some form of information hiding, which you seem to disagree on. I also wouldn't say I'm particularly emotionally invested in FP, just that I'm very skeptical of OOP as a paradigm. OOP languages tend to promote hidden, mutable state, but visible, immutable values are far more useful.
      - jbooth 13y ago
        Fair enough.. if you're talking about a giant class hierarchy with lots of mutable state, then I tend to agree that it doesn't usually lead to good software (although things like java's collections library and the outputstream hierarchy are good exceptions).

hernan604 13y ago

OO and FP coexist peacefully. FP is all about passing functions as parameters into other functions. Its exists on decent languages. Which in case allow OO also. ie. perl, allows all that, and has Moose which allows Class and Roles and Types. So you can build classes like lego, literally.

nbouscal 13y ago
> FP is all about passing functions as parameters into other functions. That's a common misconception. First-class functions and higher-order functions are definitely commonly used in functional programming, but they are not what makes it functional programming. As with any paradigm, there is no universally agreed-upon definition, but most functional programmers will likely agree that lack of mutable state and lack of side effects are much more central to functional programming than first-class and higher-order functions. The latter are really just useful and elegant tools to help accomplish the former.
- Sssnake 13y ago
  Without side effects you couldn't do anything. Pure functional languages make side effects explicit, but it isn't about them being missing.
  - nbouscal 13y ago
    > Without side effects you couldn't do anything. Not true. > Pure functional languages make side effects explicit, but it isn't about them being missing. True. I should have been more clear about that.
    - mturmon 13y ago
      Not a downvoter, but I believe "Without side effects you couldn't do anything" means that any interesting program ultimately has a side effect. The rocket is launched, the form is printed, pi is displayed on the monitor, etc.

chongli 13y ago

Do put your object in classes, but don't put behaviors there. Use classes to allow static type checking so that functions taking them can guarantee certain field exist. Why not just use algebraic data types and modules? Classes are such a verbose, jumbled, complected mess compared to those simpler tools.

lightblade 13y ago
> ...algebraic data types and modules Sorry, I not familiar with that term. Can you explain that more?
- chongli 13y ago
  I would, but I'm afraid my explanation would pale in comparison to the one on Wikipedia. Why not check it out?: http://en.wikipedia.org/wiki/Algebraic_data_type http://en.wikipedia.org/wiki/Algebraic_data_type