3 ms·

FP assumes that every component works correctly for all input data. Even the example given in the OP, it assumes that the "+" operator will work correctly for a

FP assumes that every component works correctly for all input data. Even the example given in the OP, it assumes that the "+" operator will work correctly for all of the data entries. What if one of my inputs was an imaginary number? What if I want special treatment for specific entries? Not all problems generalize.

Jtsummers 4y ago
> FP assumes No, fools assume. FP assumes nothing, it's a non-thinking thing and consequently incapable of assuming. People assume, and we all know what assuming does. So don't. Sensible people validate. Be sensible, don't be a fool. > What if I want special treatment for specific entries? Then do it? What's the hold-up?
Eji1700 4y ago
> What if one of my inputs was an imaginary number? Then the code would call that out and not compile and run until you handled that case (at least in F#, i believe ocaml and haskell have strong typing as well for this reason but it's been awhile). One of the huge upsides of most FP is letting the compiler do a ton of the heavy lifting because it can better check the "sanity" of what you've told it to do. If it's possible to pass an imaginary number to that function, it will say "hey, you could pass an imaginary number to this, and you don't handle it, here's some red squiggly underlining until you deal with that". There's lots written about this. Designing to not represent error states and domain driven design being the two main topics i've come across that really hammer home how a strong typing system and a functional mindset can create extremely bullet proof code. It's trivial to debug (mostly because 90% of the time, if it compiles it runs) and it's trivial to adjust (because the compile errors light up everywhere you need to adjust and you just do that).
Jtsummers 4y ago
My original reply was just before heading to bed, but I have a real question for you: Do you think this is FP specific? > Even the example given in the OP, it assumes that the "+" operator will work correctly for all of the data entries. What if one of my inputs was an imaginary number? What if I want special treatment for specific entries? Do you really think only functional programming encounters the situation where the data may not all be valid? You think that this imperative style JS is going to work any better on heterogenous data: sum = 0 for(const item of data) sum = sum + data That's going to fail in the same way, and it's not functional, just imperative. So what is your argument about FP here?

Jtsummers 4y ago

> FP assumes No, fools assume. FP assumes nothing, it's a non-thinking thing and consequently incapable of assuming. People assume, and we all know what assuming does. So don't. Sensible people validate. Be sensible, don't be a fool. > What if I want special treatment for specific entries? Then do it? What's the hold-up?

Eji1700 4y ago

> What if one of my inputs was an imaginary number? Then the code would call that out and not compile and run until you handled that case (at least in F#, i believe ocaml and haskell have strong typing as well for this reason but it's been awhile). One of the huge upsides of most FP is letting the compiler do a ton of the heavy lifting because it can better check the "sanity" of what you've told it to do. If it's possible to pass an imaginary number to that function, it will say "hey, you could pass an imaginary number to this, and you don't handle it, here's some red squiggly underlining until you deal with that". There's lots written about this. Designing to not represent error states and domain driven design being the two main topics i've come across that really hammer home how a strong typing system and a functional mindset can create extremely bullet proof code. It's trivial to debug (mostly because 90% of the time, if it compiles it runs) and it's trivial to adjust (because the compile errors light up everywhere you need to adjust and you just do that).

Jtsummers 4y ago

My original reply was just before heading to bed, but I have a real question for you: Do you think this is FP specific? > Even the example given in the OP, it assumes that the "+" operator will work correctly for all of the data entries. What if one of my inputs was an imaginary number? What if I want special treatment for specific entries? Do you really think only functional programming encounters the situation where the data may not all be valid? You think that this imperative style JS is going to work any better on heterogenous data: sum = 0 for(const item of data) sum = sum + data That's going to fail in the same way, and it's not functional, just imperative. So what is your argument about FP here?