Two Years of Functional Programming in JavaScript: Lessons Learned
1–8 of 8 posts
Re: Two Years of Functional Programming in JavaScript: Lessons Learned
#2Functional 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: Lessons Learned
#3Try PureScript(http://www.purescript.org/)
Re: Two Years of Functional Programming in JavaScript: Lessons Learned
#4Functional 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.
Do you have any data to show that this is a real concern with JS?
Re: Two Years of Functional Programming in JavaScript: Lessons Learned
#5Try PureScript( http://www.purescript.org/ )
That was mentioned at the end.
Re: Two Years of Functional Programming in JavaScript: Lessons Learned
#6Functional 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.
Do you have any data to show that this is a real concern with JS?
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.
Re: Two Years of Functional Programming in JavaScript: Lessons Learned
#7 // Instead of
const format = (actual, expected) => {
const variants = expected.join(‘, ‘);
return `Value ${actual} is not expected here. Possible
variants are: ${variants}`;
}
Re: Two Years of Functional Programming in JavaScript: Lessons Learned
#8As 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.