5 ms·

Not even the most fanatical functional programming zealots would claim that programs can be 100% functional. By definition, a program requires inputs and output

Not even the most fanatical functional programming zealots would claim that programs can be 100% functional. By definition, a program requires inputs and outputs, otherwise there is literally no reason to run it. Functional programming simply says: separate the IO from the computation. > Pretty much anything I've written over the last 30 years, the main purpose was to do I/O, it doesn't matter whether it's disk, network, or display. Every useful program ever written takes inputs and produces outputs. The interesting part is what you actually do in the middle to transforms inputs -> outputs. And that can be entirely functional.

markus_zhang 2y ago
> separate the IO from the computation. Can you please elaborate on this point? I read it as this web page (https://wiki.c2.com/?SeparateIoFromCalculation https://wiki.c2.com/?SeparateIoFromCalculation) describes, but I fail to see why it is a functional programming concept.
- mrkeen 2y ago
  > I fail to see why it is a functional programming concept. Excellent! You will encounter 0 friction in using an FP then. To the extent that programmers find friction using Haskell, it's usually because their computations unintentionally update the state of the world, and the compiler tells them off for it.
- AstroBen 2y ago
  Think about this: if a function calls another function that produces a side effect, both functions become impure (non-functional). Simply separating them isn't enough. That's the difference when thinking of it in functional terms Normally what functional programmers will do is pull their state and side effects up as high as they can so that most of their program is functional
- teddyh 2y ago
  Having functions which do nothing but computation is core functional programming. I/O should be delegated to the edges of your program, where it is necessary.
- bmacho 2y ago
  > but I fail to see why it is a functional programming concept. "Functional programming" means that you primarily use functions (not C functions, but mathematical pure functions) to solve your problems. This means you won't do IO in your computation because you can't do that. It also means you won't modify data, because you can't do that either. Also you might have access to first class functions, and can pass them around as values. If you do procedural programming in C++ but your functions don't do IO or modify (not local) values, then congrats, you're doing functional programming.
  - markus_zhang 2y ago
    Thanks. I now see why it makes sense to me. I work in DE so in most of our cases we do streaming (IO) without any transformation (computation), and then we do transformation in a total different pipeline. We never transform anything we consumed, always keep the original copy, even if it's bad.
DeathArrow 2y ago
>Not even the most fanatical functional programming zealots would claim that programs can be 100% functional. By definition, a program requires inputs and outputs, otherwise there is literally no reason to run it. So a program it's a function that transforms the input to the output.
DeathArrow 2y ago
>separate the IO from the computation. What about managing state? I think that is an important part and it's easy to mess it.
- roxolotl 2y ago
  Each step calculates the next state and returns it. You can then compose those state calculators. If you need to save the state that’s IO and you have a bit specifically for it.
- skydhash 2y ago
  It takes a bit of discipline, but generally all state additions should be scoped to the current context. Meaning, when you enter a subcontext, it has become input and treated as holy, and when you leave to the parent context, only the result matters. But that particular context has become inpure and decried as such in the documentation, so that carefulness is increased when interacting with it.
whatnow37373 2y ago
> The interesting part is what you actually do in the middle to transforms inputs -> outputs. Can you actually name something? The only thing I can come up with is working with interesting algorithms or datastructures, but that kind of fundamental work is very rare in my experience. Even if you do, it's quite often a very small part of the entire project.
- skydhash 2y ago
  A whole web app. The IO are generally user facing network connections (request and response), IPC and RPC (databases, other services), and files interaction. Anything else is logic. An FP programs is a collection of pipes, and IO are the endpoints. With FP the blob of data passes cleanly from one section to another while in imperative, some of it sticks. In OOP, there’s a lot of blob, that flings stuff at each other and in the process create more blobs.
  - whatnow37373 2y ago
    A general "web app"'s germane parts are: - The part that receives the connection - The part that sends back a response - Interacting with other unspecified systems through IPC, RPC or whatever (databases mainly) The shit in between, calculating a derivative or setting up a fancy data structure of some kind or something, is interesting but how much of that do we actually do as programmers? I'm not being obtuse - intentionally anyway - I'm actually curious what interesting things functional programmers do because I'm not seeing much of it. Edit: my point is, you say "Anything else is logic." to which I respond "What's left?"
    - williamcotton 2y ago
      There's lots left! "When a customer in our East Coast location makes this purchase then we apply this rate, blah blah blah". "When someone with >X karma visits HN they get downvote buttons on comments, blah blah blah".
      - skydhash 2y ago
sync13298 2y ago
> Every useful program ever written takes inputs and produces outputs. The interesting part is what you actually do in the middle to transforms inputs -> outputs. And that can be entirely functional. My work needs pseudorandom numbers throughout the big middle, for example, drawing samples from probability distributions and running randomized algorithms. That's pretty messy in a FP setting, particularly when the PRNGs get generated within deeply nested libraries.
- zelphirkalt 2y ago
  At what point does this get messy?
  - sync13298 2y ago
    When deeply nested libraries generate PRNGs, all that layering becomes impure and must be treated like any other stateful or IO code. In Haskell, that typically means living with a monad transformer or effect system managing the whole stack, and relatively little pure code remains. The messiness gets worse when libraries use different conventions to manage their PRNG statefulness. This is a non-issue in most languages but a mess in a 100% pure setting.
    - creata 2y ago
      It's not that bad if you're using a splittable RNG, is it? Any function that (transitively) depends on an RNG needs an extra input, but that's it.
    - zelphirkalt 2y ago
      What I don't understand about your comment is: Where do these "deeply nested libraries" come from? I use one library or even std library and pass the RNG along in function arguments or as a parameter. Why would there be "deeply nested" libraries? Is it like that in Haskell or something? Perhaps we are using different definitions of "library"?

markus_zhang 2y ago

> separate the IO from the computation. Can you please elaborate on this point? I read it as this web page (https://wiki.c2.com/?SeparateIoFromCalculation https://wiki.c2.com/?SeparateIoFromCalculation) describes, but I fail to see why it is a functional programming concept.

mrkeen 2y ago
> I fail to see why it is a functional programming concept. Excellent! You will encounter 0 friction in using an FP then. To the extent that programmers find friction using Haskell, it's usually because their computations unintentionally update the state of the world, and the compiler tells them off for it.
AstroBen 2y ago
Think about this: if a function calls another function that produces a side effect, both functions become impure (non-functional). Simply separating them isn't enough. That's the difference when thinking of it in functional terms Normally what functional programmers will do is pull their state and side effects up as high as they can so that most of their program is functional
teddyh 2y ago
Having functions which do nothing but computation is core functional programming. I/O should be delegated to the edges of your program, where it is necessary.
bmacho 2y ago
> but I fail to see why it is a functional programming concept. "Functional programming" means that you primarily use functions (not C functions, but mathematical pure functions) to solve your problems. This means you won't do IO in your computation because you can't do that. It also means you won't modify data, because you can't do that either. Also you might have access to first class functions, and can pass them around as values. If you do procedural programming in C++ but your functions don't do IO or modify (not local) values, then congrats, you're doing functional programming.
- markus_zhang 2y ago
  Thanks. I now see why it makes sense to me. I work in DE so in most of our cases we do streaming (IO) without any transformation (computation), and then we do transformation in a total different pipeline. We never transform anything we consumed, always keep the original copy, even if it's bad.

DeathArrow 2y ago

>Not even the most fanatical functional programming zealots would claim that programs can be 100% functional. By definition, a program requires inputs and outputs, otherwise there is literally no reason to run it. So a program it's a function that transforms the input to the output.

DeathArrow 2y ago

>separate the IO from the computation. What about managing state? I think that is an important part and it's easy to mess it.

roxolotl 2y ago
Each step calculates the next state and returns it. You can then compose those state calculators. If you need to save the state that’s IO and you have a bit specifically for it.
skydhash 2y ago
It takes a bit of discipline, but generally all state additions should be scoped to the current context. Meaning, when you enter a subcontext, it has become input and treated as holy, and when you leave to the parent context, only the result matters. But that particular context has become inpure and decried as such in the documentation, so that carefulness is increased when interacting with it.

whatnow37373 2y ago

> The interesting part is what you actually do in the middle to transforms inputs -> outputs. Can you actually name something? The only thing I can come up with is working with interesting algorithms or datastructures, but that kind of fundamental work is very rare in my experience. Even if you do, it's quite often a very small part of the entire project.

skydhash 2y ago
A whole web app. The IO are generally user facing network connections (request and response), IPC and RPC (databases, other services), and files interaction. Anything else is logic. An FP programs is a collection of pipes, and IO are the endpoints. With FP the blob of data passes cleanly from one section to another while in imperative, some of it sticks. In OOP, there’s a lot of blob, that flings stuff at each other and in the process create more blobs.
- whatnow37373 2y ago
  A general "web app"'s germane parts are: - The part that receives the connection - The part that sends back a response - Interacting with other unspecified systems through IPC, RPC or whatever (databases mainly) The shit in between, calculating a derivative or setting up a fancy data structure of some kind or something, is interesting but how much of that do we actually do as programmers? I'm not being obtuse - intentionally anyway - I'm actually curious what interesting things functional programmers do because I'm not seeing much of it. Edit: my point is, you say "Anything else is logic." to which I respond "What's left?"
  - williamcotton 2y ago
    There's lots left! "When a customer in our East Coast location makes this purchase then we apply this rate, blah blah blah". "When someone with >X karma visits HN they get downvote buttons on comments, blah blah blah".
    - skydhash 2y ago

sync13298 2y ago

> Every useful program ever written takes inputs and produces outputs. The interesting part is what you actually do in the middle to transforms inputs -> outputs. And that can be entirely functional. My work needs pseudorandom numbers throughout the big middle, for example, drawing samples from probability distributions and running randomized algorithms. That's pretty messy in a FP setting, particularly when the PRNGs get generated within deeply nested libraries.

zelphirkalt 2y ago
At what point does this get messy?
- sync13298 2y ago
  When deeply nested libraries generate PRNGs, all that layering becomes impure and must be treated like any other stateful or IO code. In Haskell, that typically means living with a monad transformer or effect system managing the whole stack, and relatively little pure code remains. The messiness gets worse when libraries use different conventions to manage their PRNG statefulness. This is a non-issue in most languages but a mess in a 100% pure setting.
  - creata 2y ago
    It's not that bad if you're using a splittable RNG, is it? Any function that (transitively) depends on an RNG needs an extra input, but that's it.
  - zelphirkalt 2y ago
    What I don't understand about your comment is: Where do these "deeply nested libraries" come from? I use one library or even std library and pass the RNG along in function arguments or as a parameter. Why would there be "deeply nested" libraries? Is it like that in Haskell or something? Perhaps we are using different definitions of "library"?