5 ms·

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

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.
      - kazagistar 13y ago
        Isn't that an effect, not neccesarily a side effect?
        mturmon 13y ago
        "Function with side effect" is a term of art in functional programming. It's a function which (like all other functions) takes in arguments and puts out arguments (that's the "effect", if you like). But also, with a "side effect" -- the simplest example being, display something on the monitor. I.e., (display "hello world") returns whatever it returns (we throw it away), but also puts that string on the monitor. The latter action is not just computing a function (in the sense of FP) of the inputs. For more, see http://www.eecs.berkeley.edu/~bh/ssch20/io.html http://www.eecs.berkeley.edu/~bh/ssch20/io.html (search for "side effect").
    - Sssnake 13y ago
      Yes true. Running a program with no side effects is a no-op. All side effect free programs are identical, and do nothing. This is one of the most common misconceptions people afraid to learn haskell bring up, because people keep saying "functional programming is having no side effects".
      - pera 13y ago
        It's funny: "not having side effects" was the main reason for me to start learning Haskell just because that idea didn't make much sense hah
      - nbouscal 13y ago
        So you're saying that a library that has no side effects but performs a complicated data transformation "doesn't do anything"?
        Sssnake 13y ago
        A library is not a program.
        nbouscal 13y ago
        Your claim was "Without side effects you couldn't do anything." I was rebutting that claim. Again, unless you want to claim that libraries "don't do anything." The more specific claim that you need side effects for a program to do anything is also false. You can prove mathematical theorems with programs that have no side effects. Of course now you'll say that that only works because of the compiler, which does have side effects, but that's really just moving the target so you can be "right" (as you did with this post). Even if theorem proving isn't good enough, since the entire purpose for having the term "side effects" is to be able to usefully discuss referential transparency, the other poster who noted that IO can be an effect and not necessarily a side effect was correct. If IO is isolated, it is not a side effect, it is just an effect. A good example of this is the execution of the main action in a Haskell program.
        13y ago
codygman 13y ago
I would argue that FP is also about avoiding mutable state.

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.
    - kazagistar 13y ago
      Isn't that an effect, not neccesarily a side effect?
      - mturmon 13y ago
        "Function with side effect" is a term of art in functional programming. It's a function which (like all other functions) takes in arguments and puts out arguments (that's the "effect", if you like). But also, with a "side effect" -- the simplest example being, display something on the monitor. I.e., (display "hello world") returns whatever it returns (we throw it away), but also puts that string on the monitor. The latter action is not just computing a function (in the sense of FP) of the inputs. For more, see http://www.eecs.berkeley.edu/~bh/ssch20/io.html http://www.eecs.berkeley.edu/~bh/ssch20/io.html (search for "side effect").
  - Sssnake 13y ago
    Yes true. Running a program with no side effects is a no-op. All side effect free programs are identical, and do nothing. This is one of the most common misconceptions people afraid to learn haskell bring up, because people keep saying "functional programming is having no side effects".
    - pera 13y ago
      It's funny: "not having side effects" was the main reason for me to start learning Haskell just because that idea didn't make much sense hah
    - nbouscal 13y ago
      So you're saying that a library that has no side effects but performs a complicated data transformation "doesn't do anything"?
      - Sssnake 13y ago
        A library is not a program.
        nbouscal 13y ago
        Your claim was "Without side effects you couldn't do anything." I was rebutting that claim. Again, unless you want to claim that libraries "don't do anything." The more specific claim that you need side effects for a program to do anything is also false. You can prove mathematical theorems with programs that have no side effects. Of course now you'll say that that only works because of the compiler, which does have side effects, but that's really just moving the target so you can be "right" (as you did with this post). Even if theorem proving isn't good enough, since the entire purpose for having the term "side effects" is to be able to usefully discuss referential transparency, the other poster who noted that IO can be an effect and not necessarily a side effect was correct. If IO is isolated, it is not a side effect, it is just an effect. A good example of this is the execution of the main action in a Haskell program.
        13y ago

codygman 13y ago

I would argue that FP is also about avoiding mutable state.