You make a very good point about Ramda. This generally isn't a problem in Haskell (one of the inspirations for Ramda) because of static typing, which enforces that a function like set takes a lens, source object, and target value in the correct argument order (else it simply won't compile). Then, the fact that set is curried allows for a lot of seamless interop and versatile usage patterns with other higher-order functions. In JS however, the lack of HS-style flexible/powerful static typing means you have more opportunities to make mistakes, passing the wrong object into the wrong argument position. Ramda still provides some very flexible usage patterns due to currying, but I don't demonstrate or highlight those techniques in this article as they fit into a much wider topic of FP approaches.
Likewise, I agree with you about the problems of "stringly-typed" APIs. Again in Haskell this isn't an issue for lenses for a variety of reasons, including the fact that lenses can be auto-generated from record field names and composed using the vanilla function composition operator (.) so you end up with lines like friends . first . pet . name which is 100% typed, non-string code.
The moral may be that trying to emulate Haskell in JavaScript can look almost as nice in a purely syntactic sense, but lose so many of the real benefits that it becomes correspondingly harder to justify the exercise.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You make a very good point about Ramda. This generally isn't a problem in Haskell (one of the inspirations for Ramda) because of static typing, which enforces that a function like
settakes a lens, source object, and target value in the correct argument order (else it simply won't compile). Then, the fact thatsetis curried allows for a lot of seamless interop and versatile usage patterns with other higher-order functions. In JS however, the lack of HS-style flexible/powerful static typing means you have more opportunities to make mistakes, passing the wrong object into the wrong argument position. Ramda still provides some very flexible usage patterns due to currying, but I don't demonstrate or highlight those techniques in this article as they fit into a much wider topic of FP approaches.Likewise, I agree with you about the problems of "stringly-typed" APIs. Again in Haskell this isn't an issue for lenses for a variety of reasons, including the fact that lenses can be auto-generated from record field names and composed using the vanilla function composition operator (
.) so you end up with lines likefriends . first . pet . namewhich is 100% typed, non-string code.The moral may be that trying to emulate Haskell in JavaScript can look almost as nice in a purely syntactic sense, but lose so many of the real benefits that it becomes correspondingly harder to justify the exercise.