4 ms·

Functional programming is not some sort of mythical effect-free beast… All functional languages I know (including Haskell and Clojure) do side effects just fine

by epgui 3y ago

Functional programming is not some sort of mythical effect-free beast… All functional languages I know (including Haskell and Clojure) do side effects just fine, and there are plenty of different approaches for performing effectful computation sensibly within FP.

sdenton4 3y ago
Calling I/o side effects makes FP seem hopelessly academic. Everything having to do with the world is seemingly a corner case - the core of the programming philosophy is only concerned with the part where we push bits around uselessly. To be sure, I don't think this is a correct interpretation, but I do think it may play a role in the difficulty of getting people onboard with FP.
- hgsgm 3y ago
  A side effect is anything not modeled that can affect the computation. Input is an obvious example, as it's impossible to predict the value of an input. Output is less obvious, but there is uncertainty like whether the filesystem is full. The original Haskell style was to have a World object that was an input to every non-pure function.
  - jibe 3y ago
    Input is an obvious example, as it's impossible to predict the value of an input. Do you mean this more abstractly or literally? In the example of PacMan, for every frame, the only possible input is nothing, left, right, up, or down. So you are be able to predict it is going to be one of those five, though not which one.
    - mrkeen 3y ago
      > Do you mean this more abstractly or literally? >> Input is an obvious example, as it's impossible to predict the value of an input. > though not which one Literally.
      - jibe 3y ago
        I’m asking as someone not familiar with function programming, so trying to learn, not be pedantic, btw! So because the possible input is not just a single value, it is not predictable. It doesn’t matter if the input was limited to a set of two values, or infinite, it is literally not predictable so therefore we don’t know the future state of the program?
        epgui 3y ago
        That’s right! You can consider the user input a source of randomness even if it can only take two values, like heads or tails.
    - TuringTest 3y ago
      That is unpredictable, but not a side effect. Side effects are changes that are not declared as part of the function parameters. If you model the controller input as a function parameter, that's just a state argument, and FP can handle it declaratively just fine without having side effects.
- zdragnar 3y ago
  Regardless of language, you can structure your program as a pure, functional core and an imperative shell. All of the io happens at the boundaries, i.e. the shell, but the application itself consists of functional, side-effect-free code. Some languages make this easier to model than others, and some make doing so in a pure style easier, eliding real-world side effects like RAM access, GPU, etc. Once you are comfortable with this concept, functional languages make a lot more sense, if you don't get lost in symbol soup. Edit: a simple Google search for "functional core imperative shell" brings up many writings on the concept.
  - freedomben 3y ago
    Yes, this is the philosophy behind which I structure my programs. Elixir has been great for this model.
- Quekid5 3y ago
  It's a bit odd that people often call these side-effects. They're just "effects". Side effects are things you don't want to happen, i.e. accidental/incidental effects... which is exactly what a pure language like Haskell aims to prevent.
  - NoThisIsMe 3y ago
    That's not how the term is used in programming. Side effects may be intentional. "Effects" (without the "side") usually means the effect is modeled as a type/value that is returned by the function.
  - dahfizz 3y ago
    That's not what "side effect" means in this context. Side effects are the opposite of pure functions. A function with side effects will mutate global state, a function without side effects will not (it will simply return a value). https://en.m.wikipedia.org/wiki/Side_effect_(computer_science) https://en.m.wikipedia.org/wiki/Side_effect_(computer_scienc...
    - epgui 3y ago
      This is true and correct, but I would add that sometimes in FP books and papers you do see authors merely writing "effects" as well. I think either would be acceptable.
      - consilient 3y ago
        "Effects" in an FP context generally refer to effects explicitly modeled as values in the program, whereas "side effects" are implicit. `Either` is an effect, throwing an exception is a side effect.
- jabradoodle 3y ago
  > the core of the programming philosophy is only concerned with the part where we push bits around uselessly. It's the opposite, for FP, OOP, imperative, that is the part of the program which is easiest. FP is about managing the difficult parts, and so is OOP. They just have different approaches, and note, many mainstream languages are incorporating FP concepts quite readily now.
  - c_crank 3y ago
    Mainstream languages incorporating FP concepts don't do so with the intent of encouraging totally pure stateless programs. What they do allow is calling the occasional anonymous function or using Map() instead of ForEach() or for().
    - jabradoodle 3y ago
      Totally pure stateless programs are not the norm in functional programming. E.g. the functional core imperative shell pattern. It's also not just a syntax difference, mainstream languages are embracing immutability more and more, often as a default. The point is that calling FP academic is a tired trope and even if it is far from the dominant paradigm, there is clearly practical lessons to be learned whatever paradigm you program in.
      - c_crank 3y ago
        The only time I hear about a mainstream language being immutable by default is from Rust people telling me that Rust is a mainstream language now. A Haskell program covered in piles of monads to abstract all state away still follows the functional core imperative shell pattern, because the runtime is the imperative shell. This doesn't make such a thing desirable for other languages. The practical lesson I learned from dabbling with functional programming in academia is that functional programming is often impractical and does not offer any of the purported benefits of better code.
        TuringTest 3y ago
- finnthehuman 3y ago
  > Calling I/o side effects makes FP seem hopelessly academic. But "imperative" has such bad mouthfeel that I had to swear it off altogether.

by epgui 3y ago

sdenton4 3y ago

Calling I/o side effects makes FP seem hopelessly academic. Everything having to do with the world is seemingly a corner case - the core of the programming philosophy is only concerned with the part where we push bits around uselessly. To be sure, I don't think this is a correct interpretation, but I do think it may play a role in the difficulty of getting people onboard with FP.

hgsgm 3y ago
A side effect is anything not modeled that can affect the computation. Input is an obvious example, as it's impossible to predict the value of an input. Output is less obvious, but there is uncertainty like whether the filesystem is full. The original Haskell style was to have a World object that was an input to every non-pure function.
- jibe 3y ago
  Input is an obvious example, as it's impossible to predict the value of an input. Do you mean this more abstractly or literally? In the example of PacMan, for every frame, the only possible input is nothing, left, right, up, or down. So you are be able to predict it is going to be one of those five, though not which one.
  - mrkeen 3y ago
    > Do you mean this more abstractly or literally? >> Input is an obvious example, as it's impossible to predict the value of an input. > though not which one Literally.
    - jibe 3y ago
      I’m asking as someone not familiar with function programming, so trying to learn, not be pedantic, btw! So because the possible input is not just a single value, it is not predictable. It doesn’t matter if the input was limited to a set of two values, or infinite, it is literally not predictable so therefore we don’t know the future state of the program?
      - epgui 3y ago
        That’s right! You can consider the user input a source of randomness even if it can only take two values, like heads or tails.
  - TuringTest 3y ago
    That is unpredictable, but not a side effect. Side effects are changes that are not declared as part of the function parameters. If you model the controller input as a function parameter, that's just a state argument, and FP can handle it declaratively just fine without having side effects.
zdragnar 3y ago
Regardless of language, you can structure your program as a pure, functional core and an imperative shell. All of the io happens at the boundaries, i.e. the shell, but the application itself consists of functional, side-effect-free code. Some languages make this easier to model than others, and some make doing so in a pure style easier, eliding real-world side effects like RAM access, GPU, etc. Once you are comfortable with this concept, functional languages make a lot more sense, if you don't get lost in symbol soup. Edit: a simple Google search for "functional core imperative shell" brings up many writings on the concept.
- freedomben 3y ago
  Yes, this is the philosophy behind which I structure my programs. Elixir has been great for this model.
Quekid5 3y ago
It's a bit odd that people often call these side-effects. They're just "effects". Side effects are things you don't want to happen, i.e. accidental/incidental effects... which is exactly what a pure language like Haskell aims to prevent.
- NoThisIsMe 3y ago
  That's not how the term is used in programming. Side effects may be intentional. "Effects" (without the "side") usually means the effect is modeled as a type/value that is returned by the function.
- dahfizz 3y ago
  That's not what "side effect" means in this context. Side effects are the opposite of pure functions. A function with side effects will mutate global state, a function without side effects will not (it will simply return a value). https://en.m.wikipedia.org/wiki/Side_effect_(computer_science) https://en.m.wikipedia.org/wiki/Side_effect_(computer_scienc...
  - epgui 3y ago
    This is true and correct, but I would add that sometimes in FP books and papers you do see authors merely writing "effects" as well. I think either would be acceptable.
    - consilient 3y ago
      "Effects" in an FP context generally refer to effects explicitly modeled as values in the program, whereas "side effects" are implicit. `Either` is an effect, throwing an exception is a side effect.
jabradoodle 3y ago
> the core of the programming philosophy is only concerned with the part where we push bits around uselessly. It's the opposite, for FP, OOP, imperative, that is the part of the program which is easiest. FP is about managing the difficult parts, and so is OOP. They just have different approaches, and note, many mainstream languages are incorporating FP concepts quite readily now.
- c_crank 3y ago
  Mainstream languages incorporating FP concepts don't do so with the intent of encouraging totally pure stateless programs. What they do allow is calling the occasional anonymous function or using Map() instead of ForEach() or for().
  - jabradoodle 3y ago
    Totally pure stateless programs are not the norm in functional programming. E.g. the functional core imperative shell pattern. It's also not just a syntax difference, mainstream languages are embracing immutability more and more, often as a default. The point is that calling FP academic is a tired trope and even if it is far from the dominant paradigm, there is clearly practical lessons to be learned whatever paradigm you program in.
    - c_crank 3y ago
      The only time I hear about a mainstream language being immutable by default is from Rust people telling me that Rust is a mainstream language now. A Haskell program covered in piles of monads to abstract all state away still follows the functional core imperative shell pattern, because the runtime is the imperative shell. This doesn't make such a thing desirable for other languages. The practical lesson I learned from dabbling with functional programming in academia is that functional programming is often impractical and does not offer any of the purported benefits of better code.
      - TuringTest 3y ago
finnthehuman 3y ago
> Calling I/o side effects makes FP seem hopelessly academic. But "imperative" has such bad mouthfeel that I had to swear it off altogether.