4 ms·

Can you elaborate on the rough seams between JavaScript and "full on functional"? I'm not a believer in the FP vs. OO religion, and have historically been skep

by wycats 11y ago

Can you elaborate on the rough seams between JavaScript and "full on functional"? I'm not a believer in the FP vs. OO religion, and have historically been skeptical of the bind operator. That said, I think that both composition via objects and composition via functions have their place. The pipeline operator attempts to make composition via functions more readable (left-to-right instead of right-to-left) and unless you think composition via functions is a bad idea in JS in all cases, I'm not sure what "full-on functional" has to do with it.

dustingetz 11y ago
js objects are mutable; utliliy libraries like underscore, lodash, jquery, do not provide purity guarantees, they export impure functions that mutate objects (e.g. https://lodash.com/docs#merge https://lodash.com/docs#merge). When we start leaning heavily on function composition to build our abstractions, we simply must have purity guarantees for everyday utilities or everything falls apart. So to go "full-on functional" in javascript means we need to fork and rewrite the entire ecosystem. And if you're going to do that, there isn't much value in keeping javascript.
- lisivka 11y ago
  So we need an (a) method to freeze object and it children, (b) to indicate that function will accept and/or return only read-only objects. Reserved "const" keyword is perfect for that.
  - dustingetz 11y ago
    That's unfortunately not what es6 const does - const is about re-assignment, not about immutability. (Though you can implement immutability in terms of non-re-assinment if it is const-all-the-way-down, which javascript objects aren't.) And you still need to re-write all the ecosystem to work with immutable objects.
- k__ 11y ago
  Are purity checks that hard to implement? I don't know much about this... Check that the function only writes on local variables and only reads closure variables and only calls other pure functions.
gotchange 11y ago
I think maybe he means that it is not idiomatic. It doesn't feel like JS with the proposed Ruby-like new bind syntax and now with this Unix-flavored pipeline operator, the language is taking on a new identity that some may not like.
tragic 11y ago
Briefly, you can look at it through the prism of equality. In javascript, 1 === 1, and "foo" === "foo". However, [] !== [] and {} !== {}. This is because in Javascript, like in Java, there is a distinction between value types (essentially, simple primitive values like numbers and strings) and reference types (collections - arrays and objects). When you assign an array to a variable, you are actually pointing the variable to a reference to the array. As a mutable data structure, its identity is more important than its value: it is expected that you shall be calling push, etc, and thus changing its value in place. In Clojure (for example), (= 1 1) and (= "foo" "foo") and (= [] []) and (= {} {}). Because Clojure's data structures are immutable, the idea of checking for identity is almost meaningless (although you can, with the identical? function). In an FP style, with generic but immutable data structures, we are more interested in value equality, since we are not concerned so much with objects with a long lifecycle over which the values of their fields may change. Javascript is in an odd position - it has enough features for both traditional OO and functional programming styles to be possible, but the two do not easily co-exist. Compromises are necessary. So, if our program is composed of mostly pure functions operating on generic data structures, we must do a lot of defensive copying, and use library functions for deep equality, because the data structures are not designed for this usage. This is not to say it's infeasible to program in this way in Javascript: it is, and I try to. But a language designed from the ground up for functional programming will point you more enthusiastically in that direction than JS does. On topic: like the syntax!
- dustingetz 11y ago
  (you're replying to the guy who wrote Ember.js)
  - tragic 11y ago
    I totally didn't see that. Usernames are too small on this damn website.

by wycats 11y ago

dustingetz 11y ago

js objects are mutable; utliliy libraries like underscore, lodash, jquery, do not provide purity guarantees, they export impure functions that mutate objects (e.g. https://lodash.com/docs#merge https://lodash.com/docs#merge). When we start leaning heavily on function composition to build our abstractions, we simply must have purity guarantees for everyday utilities or everything falls apart. So to go "full-on functional" in javascript means we need to fork and rewrite the entire ecosystem. And if you're going to do that, there isn't much value in keeping javascript.

lisivka 11y ago
So we need an (a) method to freeze object and it children, (b) to indicate that function will accept and/or return only read-only objects. Reserved "const" keyword is perfect for that.
- dustingetz 11y ago
  That's unfortunately not what es6 const does - const is about re-assignment, not about immutability. (Though you can implement immutability in terms of non-re-assinment if it is const-all-the-way-down, which javascript objects aren't.) And you still need to re-write all the ecosystem to work with immutable objects.
k__ 11y ago
Are purity checks that hard to implement? I don't know much about this... Check that the function only writes on local variables and only reads closure variables and only calls other pure functions.

gotchange 11y ago

I think maybe he means that it is not idiomatic. It doesn't feel like JS with the proposed Ruby-like new bind syntax and now with this Unix-flavored pipeline operator, the language is taking on a new identity that some may not like.

tragic 11y ago

Briefly, you can look at it through the prism of equality. In javascript, 1 === 1, and "foo" === "foo". However, [] !== [] and {} !== {}. This is because in Javascript, like in Java, there is a distinction between value types (essentially, simple primitive values like numbers and strings) and reference types (collections - arrays and objects). When you assign an array to a variable, you are actually pointing the variable to a reference to the array. As a mutable data structure, its identity is more important than its value: it is expected that you shall be calling push, etc, and thus changing its value in place. In Clojure (for example), (= 1 1) and (= "foo" "foo") and (= [] []) and (= {} {}). Because Clojure's data structures are immutable, the idea of checking for identity is almost meaningless (although you can, with the identical? function). In an FP style, with generic but immutable data structures, we are more interested in value equality, since we are not concerned so much with objects with a long lifecycle over which the values of their fields may change. Javascript is in an odd position - it has enough features for both traditional OO and functional programming styles to be possible, but the two do not easily co-exist. Compromises are necessary. So, if our program is composed of mostly pure functions operating on generic data structures, we must do a lot of defensive copying, and use library functions for deep equality, because the data structures are not designed for this usage. This is not to say it's infeasible to program in this way in Javascript: it is, and I try to. But a language designed from the ground up for functional programming will point you more enthusiastically in that direction than JS does. On topic: like the syntax!

dustingetz 11y ago
(you're replying to the guy who wrote Ember.js)
- tragic 11y ago
  I totally didn't see that. Usernames are too small on this damn website.