Re:Two Years of Functional Programming in JavaScript: Lesson...
by andriesm on Tuesday April 17, 2018 @04:05AM
(#16856426)
As an FP Novice I find the resources the article links fantastic.
I have to be honest that I am still not fully convinced that FP is not a sham! It looks like it makes many everyday code problems cognitively harder to come up with (harder to write code) so that the end result may be code that is simpler and apparently easier to read by other FP afficionados.
I've taken several stabs at learning FP, and since I do a lot of JS (and use underscore), I will certainly work through these guides and look for ways that FP can potentially make me productive.
The bar is high, because my imperative coding skillset is really strong. A lot of the time the code I write works the first time, and my code is "self debugging" via my own spin on robust programming (RP).
I find a noxe mix of procedural code and OOP (not doing pure anything) works quite well, and being able to do things like mix-ins and passing functions around takes care of the few tricky bits.
Re:Two Years of Functional Programming in JavaScript: Lesson...
by ricksnyke on Thursday April 12, 2018 @10:56PM
(#16826838)
Functional in JavaScript never made sense to me, we don't have immutability in the language. While V8 has made optimisations for short lived objects this doesn't hold true across the board so perf can be quite terrible with "pure" style FP.
Theoretically "pure" code is beautiful, in practice it tends to perform badly especially in languages that don't have value types and copy mechanisms.
Re:Two Years of Functional Programming in JavaScript: Lesson...
by tracker1 on Friday April 13, 2018 @10:09AM
(#16830111)
It may depend on the context, and with some VERY large data models, something like even Redux would be less efficient. TBH though, I find that practicing FP in JS even in a less pure form isn't so bad. I tend to prefer shallow clones as responses in favor over mutations. Though I will mutate an object, when it's exclusively inside a function/module and sealed from the outside so that such mutations are at least in isolation.
I have to be honest that I am still not fully convinced that FP is not a sham! It looks like it makes many everyday code problems cognitively harder to come up with (harder to write code) so that the end result may be code that is simpler and apparently easier to read by other FP afficionados.
I've taken several stabs at learning FP, and since I do a lot of JS (and use underscore), I will certainly work through these guides and look for ways that FP can potentially make me productive.
The bar is high, because my imperative coding skillset is really strong. A lot of the time the code I write works the first time, and my code is "self debugging" via my own spin on robust programming (RP).
I find a noxe mix of procedural code and OOP (not doing pure anything) works quite well, and being able to do things like mix-ins and passing functions around takes care of the few tricky bits.
Theoretically "pure" code is beautiful, in practice it tends to perform badly especially in languages that don't have value types and copy mechanisms.