4 ms·

Some truth to this possibly. This sort of concern would be addressed by the library ecosystem rather than "the language", which might not be for everyone. I mea

Some truth to this possibly. This sort of concern would be addressed by the library ecosystem rather than "the language", which might not be for everyone. I mean PS arrays/records map to JS arrays/objects as far as passing/return them, but for those few cases where you really need to mutate inside-a-(no-longer-pure)-func, it's JS-FFI-hackery or (more likely often) a readily-available 3rd-party package offering the persistent or mutable data structure to serve the need at hand. Might not want to write your WebGL 3D game's game loop or a very mathy 2/3/x-dimensional "big array" re-calculation entirely in PS perhaps, sure enough. Depends on what apps you have in mind I guess. Typically in JS what's become more common recently is to map over the structure, extract the small sub-set you actually want to process (reduce/filter) and in the end these copies often turn out small and not so scary. But as always, "it depends". Truly the PureScript/Haskell/Elm family makes mutation harder than all other languages --- with the flip-side that they make immutable purely-functional expression vastly more ergonomic IMHO =)

christophilus 9y ago
I guess I'm thinking more along the lines of Clojure(Script) which has efficient immutable lists, vectors, and maps. It doesn't do a full copy every time you do a cons or assoc. It seems to me that PureScript would really benefit from having something similar baked in.
- wereHamster 9y ago
  It does have efficient maps (purescript-maps) and listss (purescript-lists). Couldn't find any package which provides a Vector type that is not optimised specifically for math operations which always operate on the whole vector (multiply, add, dot product etc).
  - christophilus 9y ago
    Ah. Right. My impression was that most PureScript code just uses plain JS objects / arrays, though. Is that not correct? If the ecosystem isn't built around the efficient immutable data types, much of the advantage disappears.
lewisl9029 9y ago
> This sort of concern would be addressed by the library ecosystem rather than "the language", which might not be for everyone. The JS world has this in Immutable.js, which provides a set of persistent data structures that are excellent by any measure. However, since it's not the default data structures provided by the language, practically no third party library actually consumes/emits them as input/output directly. What this means in practice is that most of the performance benefits of structural sharing through Immutable.js ends up being outright negated many-times fold by the necessity to recursively convert to and from JS native collections at the edges of your system that inevitably needs to call out to/consume data from third party libraries. Not to mention that the developer ergonomics of working with Immutable.js pales in comparison with that of native JS collections, since you're limited to the traversal and manipulation APIs provided by the library, and have to forgo excellent functional utility libraries like Ramda [1], and handy language features like destructuring and spread. This is why even in systems that embrace immutability like Redux, the prospect of using Immutable.js comes with a huge list of caveats that are well documented [2], driving most developers to end up choosing JS native collections and doing naive copy-on-write without structural sharing across the board. [1] http://ramdajs.com/ http://ramdajs.com/ [2] http://redux.js.org/docs/recipes/UsingImmutableJS.html http://redux.js.org/docs/recipes/UsingImmutableJS.html In contrast, in the ClojureScript ecosystem, everything uses the default persistent collections, and so this is never a problem.
- hellofunk 9y ago
  I thought that Reason implicitly used Immutable-Re and Bucklescript implicity used Immutable, similar to how Clojurescript implicitly uses its own library from these structures. That is, if you write wholly within the language, you get the benefits of these structures without thinking about it. Is that not true?
  - lewisl9029 9y ago
    GP was talking about PureScript, not Reason. To be honest, I have very little experience with either, but I just wanted to chime in re: the persistent data structures as a library topic with an anecdote from the JS side.

christophilus 9y ago

I guess I'm thinking more along the lines of Clojure(Script) which has efficient immutable lists, vectors, and maps. It doesn't do a full copy every time you do a cons or assoc. It seems to me that PureScript would really benefit from having something similar baked in.

wereHamster 9y ago
It does have efficient maps (purescript-maps) and listss (purescript-lists). Couldn't find any package which provides a Vector type that is not optimised specifically for math operations which always operate on the whole vector (multiply, add, dot product etc).
- christophilus 9y ago
  Ah. Right. My impression was that most PureScript code just uses plain JS objects / arrays, though. Is that not correct? If the ecosystem isn't built around the efficient immutable data types, much of the advantage disappears.

lewisl9029 9y ago

> This sort of concern would be addressed by the library ecosystem rather than "the language", which might not be for everyone. The JS world has this in Immutable.js, which provides a set of persistent data structures that are excellent by any measure. However, since it's not the default data structures provided by the language, practically no third party library actually consumes/emits them as input/output directly. What this means in practice is that most of the performance benefits of structural sharing through Immutable.js ends up being outright negated many-times fold by the necessity to recursively convert to and from JS native collections at the edges of your system that inevitably needs to call out to/consume data from third party libraries. Not to mention that the developer ergonomics of working with Immutable.js pales in comparison with that of native JS collections, since you're limited to the traversal and manipulation APIs provided by the library, and have to forgo excellent functional utility libraries like Ramda [1], and handy language features like destructuring and spread. This is why even in systems that embrace immutability like Redux, the prospect of using Immutable.js comes with a huge list of caveats that are well documented [2], driving most developers to end up choosing JS native collections and doing naive copy-on-write without structural sharing across the board. [1] http://ramdajs.com/ http://ramdajs.com/ [2] http://redux.js.org/docs/recipes/UsingImmutableJS.html http://redux.js.org/docs/recipes/UsingImmutableJS.html In contrast, in the ClojureScript ecosystem, everything uses the default persistent collections, and so this is never a problem.

hellofunk 9y ago
I thought that Reason implicitly used Immutable-Re and Bucklescript implicity used Immutable, similar to how Clojurescript implicitly uses its own library from these structures. That is, if you write wholly within the language, you get the benefits of these structures without thinking about it. Is that not true?
- lewisl9029 9y ago
  GP was talking about PureScript, not Reason. To be honest, I have very little experience with either, but I just wanted to chime in re: the persistent data structures as a library topic with an anecdote from the JS side.