5 ms·

In my opinion, FP is one tool in the toolkit, and is best suited for expressing math-oriented things such as set operations, analytics pipelines, and other kind

In my opinion, FP is one tool in the toolkit, and is best suited for expressing math-oriented things such as set operations, analytics pipelines, and other kinds of data transformations. For any kind of I/O, though, FP is not even applicable in the pure sense of a function, as disk/network access is inherently a side effect. JS can of course mask much of this with its Promises. Any kind of business-oriented logic, especially handling of different kinds of data entities, is still good to encapsulate in classes in OOP fashion. Classes are a good impedance match for entity types, as instances are to entities. Sometimes, though, data transformations are still more clearly expressed in imperative style. At the very least they’re more accessible to juniors, unlike the innards of declarative transformation engines. Imperative, declarative, object-oriented, functional — these are all tools for different jobs.

valenterry 4y ago
Pure FP is most useful for IO. Without IO, the concept of pure FP doesn't make any sense.
- eurasiantiger 4y ago
  That doesn’t make sense. Any function doing I/O is not pure by definition, and while using an IO monad can shift the impureness a bit to make a function behave as if it was pure, it is not pure and cannot ever be pure. Can you explain?
  - valenterry 4y ago
    Yeah - I think from your explanation I can only deduce that you don't know the actual definition and concept of pure functional programming. Note that the term "functional programming" has been watered down over time and now pretty much means "use .map and .filter instead of a loop" etc. Historically the meaning was different though, see: https://en.wikipedia.org/wiki/Purely_functional_programming https://en.wikipedia.org/wiki/Purely_functional_programming With pure functional programming you essentially treat IO-effects as a first class concept and make them explicit in your code. You never "execute" IO directly but compose small "blueprints" for doing IO into bigger blueprints and so on until you end up with one big blueprint which is your application. You then pass it to the runtime ("main() { ...; return bigBlueprint; }") and then it gets executed. In other words, pure functional programming treats IO as more important compared to "regular programming" and without any IO there would be no need to even do so. But without any IO, a program wouldn't have any meaning, because you want at least expose the result of a computation to the outside world.
    - eurasiantiger 4y ago
      I do understand the concept of pureness in the appropriate context. However, it appears that you do not. This is a good example, since it ticks all the boxes: there is imperative code run as a side effect of executing the code output by the compiler based on declarations in functional style, including those impure IO-using functions. Slapping IO on your function is making it explicit that it is impure.
      - valenterry 4y ago
        The concept of pure functional programming is totally independent of what the compiler generates. Of course, in the end, there will always be something running that executes effects and that will be impure instructions. But for the context of pfp only the programming language matters since that is what we are working on. If you work with assembly directly then yeah, that is impure by all means. > Slapping IO on your function is making it explicit that it is impure. Not sure what "slapping IO in your function" even means here. To maybe some it up and get the discussion to an end: if you have an expression and can freely duplicate it and have it evaluated anywhere within your code (e.g. by assigning it to a variable) and it does not change the semantics of your program (so e.g. performance can be worse, that's okay) then the expression is referential transparent. If all expressions in your programm are referential transparent, you are doing pure functional programming. That is the simplified definition.
        eurasiantiger 4y ago
        “The IO monad does not make a function pure. It just makes it obvious that it’s impure.” — Martin Odersky https://alvinalexander.com/scala/fp-book/pure-functions-and-io-input-output/ https://alvinalexander.com/scala/fp-book/pure-functions-and-...
        valenterry 4y ago
        Turns out he was wrong. Already discussed/explained: > https://news.ycombinator.com/item?id=20744274 https://news.ycombinator.com/item?id=20744274
mrkeen 4y ago
> For any kind of I/O, though, FP is not even applicable in the pure sense of a function, as disk/network access is inherently a side effect. If you meant to do it, it's an effect, not a side-effect.
- eurasiantiger 4y ago
  That’s not what is meant with side effect in this context.

valenterry 4y ago

Pure FP is most useful for IO. Without IO, the concept of pure FP doesn't make any sense.

eurasiantiger 4y ago
That doesn’t make sense. Any function doing I/O is not pure by definition, and while using an IO monad can shift the impureness a bit to make a function behave as if it was pure, it is not pure and cannot ever be pure. Can you explain?
- valenterry 4y ago
  Yeah - I think from your explanation I can only deduce that you don't know the actual definition and concept of pure functional programming. Note that the term "functional programming" has been watered down over time and now pretty much means "use .map and .filter instead of a loop" etc. Historically the meaning was different though, see: https://en.wikipedia.org/wiki/Purely_functional_programming https://en.wikipedia.org/wiki/Purely_functional_programming With pure functional programming you essentially treat IO-effects as a first class concept and make them explicit in your code. You never "execute" IO directly but compose small "blueprints" for doing IO into bigger blueprints and so on until you end up with one big blueprint which is your application. You then pass it to the runtime ("main() { ...; return bigBlueprint; }") and then it gets executed. In other words, pure functional programming treats IO as more important compared to "regular programming" and without any IO there would be no need to even do so. But without any IO, a program wouldn't have any meaning, because you want at least expose the result of a computation to the outside world.
  - eurasiantiger 4y ago
    I do understand the concept of pureness in the appropriate context. However, it appears that you do not. This is a good example, since it ticks all the boxes: there is imperative code run as a side effect of executing the code output by the compiler based on declarations in functional style, including those impure IO-using functions. Slapping IO on your function is making it explicit that it is impure.
    - valenterry 4y ago
      The concept of pure functional programming is totally independent of what the compiler generates. Of course, in the end, there will always be something running that executes effects and that will be impure instructions. But for the context of pfp only the programming language matters since that is what we are working on. If you work with assembly directly then yeah, that is impure by all means. > Slapping IO on your function is making it explicit that it is impure. Not sure what "slapping IO in your function" even means here. To maybe some it up and get the discussion to an end: if you have an expression and can freely duplicate it and have it evaluated anywhere within your code (e.g. by assigning it to a variable) and it does not change the semantics of your program (so e.g. performance can be worse, that's okay) then the expression is referential transparent. If all expressions in your programm are referential transparent, you are doing pure functional programming. That is the simplified definition.
      - eurasiantiger 4y ago
        “The IO monad does not make a function pure. It just makes it obvious that it’s impure.” — Martin Odersky https://alvinalexander.com/scala/fp-book/pure-functions-and-io-input-output/ https://alvinalexander.com/scala/fp-book/pure-functions-and-...
        valenterry 4y ago
        Turns out he was wrong. Already discussed/explained: > https://news.ycombinator.com/item?id=20744274 https://news.ycombinator.com/item?id=20744274

mrkeen 4y ago

> For any kind of I/O, though, FP is not even applicable in the pure sense of a function, as disk/network access is inherently a side effect. If you meant to do it, it's an effect, not a side-effect.

eurasiantiger 4y ago
That’s not what is meant with side effect in this context.