5 ms·

You still have state, it is just the problem has been reduced to one of the very minumum amount of state you need to represent desired functionality. e.g. curre

You still have state, it is just the problem has been reduced to one of the very minumum amount of state you need to represent desired functionality. e.g. current time. Not all problems reduce this far, just because one does it does not mean they all do. There are really only two ways of describing the world around us, by state or by function, and not all problems can be either. In tis casse the state (time) is applied to a function. This is good for some things and not neccesarily so good for others. If you think that there is some future of computing with universal stateless code you are delusional.

dtagames 4y ago
It's impossible to eliminate state, but the goal of functional programming is to have as little as possible. The original article does a great job of explaining how to do it and why that's an advantage in this case.
- FpUser 4y ago
  >"but the goal of functional programming is to have as little as possible." The goal is to produce optimal software not to serve particular paradigm.
  - dtagames 4y ago
    Indeed. If the goals of functional programming help out in a particular instance and that style works for you, then use it.
  - mrguyorama 4y ago
    Everything I have seen about "pure functional" programming has cared more about ideology than practicality.
    - dtagames 4y ago
      I had the opportunity to meet John Backus, the inventor of functional programming, when I worked at IBM. I definitely didn't "get it" the first time. Indeed, not until many years later. I wrote this article, Functional Programming in TS[0] which has a lot of good background info and explanations. At least I think so, lol! And it's been pretty popular. See what you think: [0] https://medium.com/gitconnected/functional-programming-in-typescript-18ac096bb551 https://medium.com/gitconnected/functional-programming-in-ty...
      - FpUser 4y ago
        Every concept is good when applied in the right place for the right cause. But programmers often tend to idolize particular tech to the degree that anything else is anathema.
- klibertp 4y ago
  To add to the sibling commenter - in my experience FP is not about having as little state as possible. It's about explicitly representing and tracking all state. OOP hides all state in private properties, FP displays the state as function arguments. In the end, you want a healthy mixture of both approaches. Sometimes state is better off hidden, and then in FP you need closures - might as well use an object then, instead of emulating it by creating a closure that "responds" to "messages" by manually dispatching arguments in a giant switch. I think OCaml, Scala, and Clojure got it right, on a language level, but then the problems float up into design - ie. where to use a mutable record and where to use a functional stream, etc. I don't think I saw a compelling set of guidelines how to mix the approaches in the most effective way.
catapart 4y ago
To be even more specific - you can only ever describe something by a function, and you have to supply a state in order to get a singular result. In physical space, the state we provide to get a result of any particular "object" is time. More simply: you can't describe any specific table with any meaningful properties without specifying the time in which you're observing the description. Every "thing" is just a transient state of being for at least one, if not millions, of variously interactive processes. Of course, none of that is relevant to how useful it is to be able to reduce "state" down to the singular (and mostly "invisible") property of "time". It's just that while you are technically correct that the article did not 'remove state', it's only as technically correct as saying a banana is a "berry". In the vast majority of use cases, including teaching people the value of something, the specification is a difference without a distinction.
MuffinFlavored 4y ago
> There are really only two ways of describing the world around us, by state or by function Hilariously, my girlfriend always yells at me "I'm not a block of code! I'm not 0 or 1! I'm not just on or off! Humans have feelings and emotions in the gray!" when I try to boil down "if this, then that" logic to real world problems.
Asooka 4y ago
An important difference is that you are not modifying the state, though it is still there. There is one problem - time is limited to the range of values the given type can contain and since it's often a floating point type, the farther from zero you go, the less precision you have. Depending on how exactly you use the time variable, the loss of precision can become catastrophic long before the ulps get larger than a nanosecond.

dtagames 4y ago

It's impossible to eliminate state, but the goal of functional programming is to have as little as possible. The original article does a great job of explaining how to do it and why that's an advantage in this case.

FpUser 4y ago
>"but the goal of functional programming is to have as little as possible." The goal is to produce optimal software not to serve particular paradigm.
- dtagames 4y ago
  Indeed. If the goals of functional programming help out in a particular instance and that style works for you, then use it.
- mrguyorama 4y ago
  Everything I have seen about "pure functional" programming has cared more about ideology than practicality.
  - dtagames 4y ago
    I had the opportunity to meet John Backus, the inventor of functional programming, when I worked at IBM. I definitely didn't "get it" the first time. Indeed, not until many years later. I wrote this article, Functional Programming in TS[0] which has a lot of good background info and explanations. At least I think so, lol! And it's been pretty popular. See what you think: [0] https://medium.com/gitconnected/functional-programming-in-typescript-18ac096bb551 https://medium.com/gitconnected/functional-programming-in-ty...
    - FpUser 4y ago
      Every concept is good when applied in the right place for the right cause. But programmers often tend to idolize particular tech to the degree that anything else is anathema.
klibertp 4y ago
To add to the sibling commenter - in my experience FP is not about having as little state as possible. It's about explicitly representing and tracking all state. OOP hides all state in private properties, FP displays the state as function arguments. In the end, you want a healthy mixture of both approaches. Sometimes state is better off hidden, and then in FP you need closures - might as well use an object then, instead of emulating it by creating a closure that "responds" to "messages" by manually dispatching arguments in a giant switch. I think OCaml, Scala, and Clojure got it right, on a language level, but then the problems float up into design - ie. where to use a mutable record and where to use a functional stream, etc. I don't think I saw a compelling set of guidelines how to mix the approaches in the most effective way.

catapart 4y ago

To be even more specific - you can only ever describe something by a function, and you have to supply a state in order to get a singular result. In physical space, the state we provide to get a result of any particular "object" is time. More simply: you can't describe any specific table with any meaningful properties without specifying the time in which you're observing the description. Every "thing" is just a transient state of being for at least one, if not millions, of variously interactive processes. Of course, none of that is relevant to how useful it is to be able to reduce "state" down to the singular (and mostly "invisible") property of "time". It's just that while you are technically correct that the article did not 'remove state', it's only as technically correct as saying a banana is a "berry". In the vast majority of use cases, including teaching people the value of something, the specification is a difference without a distinction.

MuffinFlavored 4y ago

> There are really only two ways of describing the world around us, by state or by function Hilariously, my girlfriend always yells at me "I'm not a block of code! I'm not 0 or 1! I'm not just on or off! Humans have feelings and emotions in the gray!" when I try to boil down "if this, then that" logic to real world problems.

Asooka 4y ago

An important difference is that you are not modifying the state, though it is still there. There is one problem - time is limited to the range of values the given type can contain and since it's often a floating point type, the farther from zero you go, the less precision you have. Depending on how exactly you use the time variable, the loss of precision can become catastrophic long before the ulps get larger than a nanosecond.