←back to thread

296 points gyre007 | 1 comments | | HN request time: 0.252s | source
Show context
onion2k ◴[] No.21280617[source]
JavaScript isn't a functional language itself, but you can use a functional library like lodash/fp (https://github.com/lodash/lodash/wiki/FP-Guide) on top of it to get all that lovely functional goodness in your frontend and node code. Using lodash/fp has made my frontend state management code a lot nicer, and I'm really only just starting out with it.
replies(4): >>21280640 #>>21280696 #>>21280761 #>>21281273 #
mikekchar ◴[] No.21280761[source]
Personally, I think JS is a fine functional language. Like you say, it doesn't have a good FP style system library, but it doesn't have a good anything style system library ;-) My main complaint is that currying is awkward. One thing I have discovered, though, is that closures are relatively slow (that is, unoptimised) in most implementations. In several implementations, they can also leak memory in certain circumstances. There is a very old outstanding bug in V8 that gives a lot of details about this... unfortunately I'm not in a position at the moment to go spelunking for it (I wish I'd saved a link...)

Anyway, I've done quite a few fairly large katas in JS using only an FP style of coding without any dependencies and I really enjoyed it.

replies(1): >>21281534 #
verttii ◴[] No.21281534[source]
Personally I find functional style awkward in js. Mostly because data is not immutable, there are no functional operators (composition, application etc.) and no algebraic data types + pattern matching.

But most importantly, prototypal inheritance, in other words invoking the object's own methods as if they were pure functions is what really puts me off.

replies(2): >>21283523 #>>21287300 #
mikekchar ◴[] No.21287300[source]
A lot of that stuff is pretty modern in terms of FP, though. It's definitely not a pure functional language, though quite a lot of the data is actually immutable. It was really surprising to me that strings are immutable (but as the other commenter pointed out, they don't throw if you try to mutate them, so it's not that convenient). "Objects" and arrays are mutable, but it's pretty easy to avoid mutating them if you want to.

It probably wasn't clear, but the reason I didn't use any dependencies is because I was avoiding JS's built in inheritance mechanism, which I don't think is very compatible with FP. You can build objects out of closures and build your own object oriented mechanisms if you want. Unfortunately you run into the limitations of the implementations I mentioned.

I always hesitate to link to my own "fun" code, but just so you understand that I was not looking for code quality in this: https://gitlab.com/mikekchar/testy But it shows how I was using an FP style in JS to implement an alternative OO system. I really had fun writing this code and would have continued if there weren't problems with using closures in JS.

Edit: If you look at this, it's probably best to start here: https://gitlab.com/mikekchar/testy/blob/master/design.md

I really should link that in the README...

replies(1): >>21289135 #
1. Roboprog ◴[] No.21289135[source]
Look into Ramda.js if you haven’t yet. It adds partial function application / currying capabilities, as well as composition support.

E.g.

https://ramdajs.com/docs/#partial

https://ramdajs.com/docs/#pipe