4 ms·

Functional programming is not for back-end web programming or front-end web programming. That's like asking if calculus is for making better nails or for making

by Retra 11y ago

Functional programming is not for back-end web programming or front-end web programming. That's like asking if calculus is for making better nails or for making better screws. Or if a 68K processor is for doing taxes or for doing word processing. It has nothing to do at all with what kind of thing you are building, it is a general means of expressing common patterns in programs. Much of the reason people like FP is because it provides a high degree of code reuse in standardized forms, and it does so with a good bit of terseness and flexibility. Just about everything else in the FP world is about optimizing safety, performance, and reliability without giving up these benefits. When someone says "FP is good," it's analogous to saying "well-commented code is good." As in, it's good everywhere you have the time to do it correctly. (There just happens to be a lot of debate about how to do it correctly.)

edvinbesic 11y ago
For those of us non-yet enlightened, I keep reading these kind of comments and walk away more confused. Sure, I get what it is but what I don't get is how I would use it in my world of mutating data and side-effects.
- monknomo 11y ago
  I have only tried FP a little bit, but I personally found value in non mutating data and removing side effects, even in the portions of my code that are OO. It's refreshing getting rid of the whole class of bugs caused by developers using harmless sounding method names that subtly alter their data. It did require substantial rewriting of the basic units of the program I tried it in, so there is that...
- kwhitefoot 11y ago
  If your world of mutating data and side effects is anything like mine taking a functional view should let you get rid of a lot of those side effects and mutating data. The functional program will be easier to debug. Unfortunately it might also be slower but this can be mitigated by memoization or caching.
- Retra 11y ago
  One of the reasons FP has gotten so popular over the last 15 years is because we've figured out how to handle mutating data and side effects in a way that is compatible with standard FP plumbing. (Though there are probably a few roadblocks here and there that need work.)
- Lazare 11y ago
  So...don't write code that mutates data and has side-effects? It is, again, like saying "I don't see how this helps me in my world of uncommented code". You could just comment your code, right? (Or if that's too much work, or it's a shared code base and you can't get buy-in, just start going forward?)
  - edvinbesic 11y ago
    I belive database operations are considered a side-effect, so how would you propose I do away with those?
    - Retra 11y ago
      Database operations are just state transformers, which are pure functions. It is the state you have to worry about, and you can wrap that state in a number of FP constructs.
      - edvinbesic 11y ago
        Not trying to be snarky, but what is the difference between a state-transformer and a general side-effect. The book in question gives the following explanation for what a side-effect is: "We'll be referring to effect as anything that occurs in our computation besides the calculation of a result." This is in chapter 3, and they provide the following list for what is a possible side-effect: - changing the file system - inserting a record into a database - making an http call - mutations - printing to the screen / logging - obtaining user input - querying the DOM - accessing system state With that in mind, there is not much I can do in my code and have a functional app without side-effects.
        codygman 11y ago
        > With that in mind, there is not much I can do in my code and have a functional app without side-effects. Not quite. Let's take one of those side effects as an example... say accessing system state. You probably aren't just accessing system state. You probably want to update it in some way right? Your function to update it could easily be pure. Take obtaining user input for example. Getting the user input is usually the most boring part of the program isn't it? The majority of what you do with that user input could very likely be pure functions.
- agumonkey 11y ago
  So far I believe side-effects as we think of them are unavoidable[1]. But they can be reduce to a minimum (the maximum being writing programs as a big set of global variables, and jumping GOTOs between mutations). Using functional style avoid a lot of nasty side effects like unnecessary temporaries, uninitialized values and their modification afterward (local assignments or across procedures). This is a thing one can do in C, whereas in FP languages, you're constrained to write this way, giving a culture of combinators and patterns (tree rec, map, fold, streams, monads, ..) hugely solid and tiny, thus reusable. I understand what you mean, because even though I love FP a lot, I still struggle to conceive whole systems (other than simple map-filter dataflow ones) this way. So far I keep the FP principles for small pieces, hoping later on I'll find a way to close the gaps. [1] John Backus tried to design purely functional languages a long time ago and he hit the IO wall (he mentions it in some article). Haskellers had issues at first and found that Monads were a nice functional way to express IO-like logic. It's still something weird, a lot less clean than purely functional expressions to be evaluated.
  - edvinbesic 11y ago
    The 'IO wall' as you put it is the main thing I have not been able to wrap my head around. Most of the examples I have seen of FP-implementation-of-X leave this bit out, or at best is a passing mention left as a 'reader exercise'. Most of us probably already follow best practices in terms of small functions, no global state, promises, composability etc. But at the end of every chain I have a db query and most of those mutate some data or other. Hopefully some day it clicks.
    - codygman 11y ago
      > Hopefully some day it clicks. While you wait for that, try writing useful code despite not fully understanding it. Tell me what you think of the following code examples: > sum . take 2 $ [1,2,3,4,5] 3 > -- now lets pretend we have a list of numbers we got from the DB > let mockDBResponse = return [1,2,3,4,5] :: IO [Int] > -- first lets try the exact same code as above > sum . take 2 $ [1,2,3,4,5] 3 > sum . take 2 $ mockDBResponse <interactive>:46:16: Couldn't match expected type ‘[c]’ with actual type ‘IO [Int]’ Relevant bindings include it :: c (bound at <interactive>:46:1) In the second argument of ‘($)’, namely ‘mockDBResponse’ In the expression: sum . take 2 $ mockDBResponse > -- what to do? Use <$> > import Control.Applicative ((<$>)) > sum . take 2 <$> mockDBResponse 3 1) Applying pure functions to pure functions sum . take 2 $ [1,2,3,4,5] 2) Applying pure functions to monadic functions that implement fmap of the Functor typeclass sum . take 2 <$> [1,2,3,4,5] When I noticed that adding brackets around $ allowed me to apply pure functions to monadic ones a lot more made sense to me.
joe_the_user 11y ago
This just seems like fogging the issue. Calculus is not for economics but there are guides to calculus for economics majors. A given language isn't word processing but a "guide to writing a word process in Pascal" is not unimaginable. The parent asked for a guide to using functional programming for the web back end. I'm not sure why sure a thing couldn't exist.

by Retra 11y ago

edvinbesic 11y ago

For those of us non-yet enlightened, I keep reading these kind of comments and walk away more confused. Sure, I get what it is but what I don't get is how I would use it in my world of mutating data and side-effects.

monknomo 11y ago
I have only tried FP a little bit, but I personally found value in non mutating data and removing side effects, even in the portions of my code that are OO. It's refreshing getting rid of the whole class of bugs caused by developers using harmless sounding method names that subtly alter their data. It did require substantial rewriting of the basic units of the program I tried it in, so there is that...
kwhitefoot 11y ago
If your world of mutating data and side effects is anything like mine taking a functional view should let you get rid of a lot of those side effects and mutating data. The functional program will be easier to debug. Unfortunately it might also be slower but this can be mitigated by memoization or caching.
Retra 11y ago
One of the reasons FP has gotten so popular over the last 15 years is because we've figured out how to handle mutating data and side effects in a way that is compatible with standard FP plumbing. (Though there are probably a few roadblocks here and there that need work.)
Lazare 11y ago
So...don't write code that mutates data and has side-effects? It is, again, like saying "I don't see how this helps me in my world of uncommented code". You could just comment your code, right? (Or if that's too much work, or it's a shared code base and you can't get buy-in, just start going forward?)
- edvinbesic 11y ago
  I belive database operations are considered a side-effect, so how would you propose I do away with those?
  - Retra 11y ago
    Database operations are just state transformers, which are pure functions. It is the state you have to worry about, and you can wrap that state in a number of FP constructs.
    - edvinbesic 11y ago
      Not trying to be snarky, but what is the difference between a state-transformer and a general side-effect. The book in question gives the following explanation for what a side-effect is: "We'll be referring to effect as anything that occurs in our computation besides the calculation of a result." This is in chapter 3, and they provide the following list for what is a possible side-effect: - changing the file system - inserting a record into a database - making an http call - mutations - printing to the screen / logging - obtaining user input - querying the DOM - accessing system state With that in mind, there is not much I can do in my code and have a functional app without side-effects.
      - codygman 11y ago
        > With that in mind, there is not much I can do in my code and have a functional app without side-effects. Not quite. Let's take one of those side effects as an example... say accessing system state. You probably aren't just accessing system state. You probably want to update it in some way right? Your function to update it could easily be pure. Take obtaining user input for example. Getting the user input is usually the most boring part of the program isn't it? The majority of what you do with that user input could very likely be pure functions.
agumonkey 11y ago
So far I believe side-effects as we think of them are unavoidable[1]. But they can be reduce to a minimum (the maximum being writing programs as a big set of global variables, and jumping GOTOs between mutations). Using functional style avoid a lot of nasty side effects like unnecessary temporaries, uninitialized values and their modification afterward (local assignments or across procedures). This is a thing one can do in C, whereas in FP languages, you're constrained to write this way, giving a culture of combinators and patterns (tree rec, map, fold, streams, monads, ..) hugely solid and tiny, thus reusable. I understand what you mean, because even though I love FP a lot, I still struggle to conceive whole systems (other than simple map-filter dataflow ones) this way. So far I keep the FP principles for small pieces, hoping later on I'll find a way to close the gaps. [1] John Backus tried to design purely functional languages a long time ago and he hit the IO wall (he mentions it in some article). Haskellers had issues at first and found that Monads were a nice functional way to express IO-like logic. It's still something weird, a lot less clean than purely functional expressions to be evaluated.
- edvinbesic 11y ago
  The 'IO wall' as you put it is the main thing I have not been able to wrap my head around. Most of the examples I have seen of FP-implementation-of-X leave this bit out, or at best is a passing mention left as a 'reader exercise'. Most of us probably already follow best practices in terms of small functions, no global state, promises, composability etc. But at the end of every chain I have a db query and most of those mutate some data or other. Hopefully some day it clicks.
  - codygman 11y ago
    > Hopefully some day it clicks. While you wait for that, try writing useful code despite not fully understanding it. Tell me what you think of the following code examples: > sum . take 2 $ [1,2,3,4,5] 3 > -- now lets pretend we have a list of numbers we got from the DB > let mockDBResponse = return [1,2,3,4,5] :: IO [Int] > -- first lets try the exact same code as above > sum . take 2 $ [1,2,3,4,5] 3 > sum . take 2 $ mockDBResponse <interactive>:46:16: Couldn't match expected type ‘[c]’ with actual type ‘IO [Int]’ Relevant bindings include it :: c (bound at <interactive>:46:1) In the second argument of ‘($)’, namely ‘mockDBResponse’ In the expression: sum . take 2 $ mockDBResponse > -- what to do? Use <$> > import Control.Applicative ((<$>)) > sum . take 2 <$> mockDBResponse 3 1) Applying pure functions to pure functions sum . take 2 $ [1,2,3,4,5] 2) Applying pure functions to monadic functions that implement fmap of the Functor typeclass sum . take 2 <$> [1,2,3,4,5] When I noticed that adding brackets around $ allowed me to apply pure functions to monadic ones a lot more made sense to me.

joe_the_user 11y ago

This just seems like fogging the issue. Calculus is not for economics but there are guides to calculus for economics majors. A given language isn't word processing but a "guide to writing a word process in Pascal" is not unimaginable. The parent asked for a guide to using functional programming for the web back end. I'm not sure why sure a thing couldn't exist.