3 ms·

seamless doesn't implement the "persistent" part of immutable persistent data structures. The persistent part means you can create a cheap modification of the

seamless doesn't implement the "persistent" part of immutable persistent data structures. The persistent part means you can create a cheap modification of the data structure, with structural sharing between "copies".

Waterluvian 10y ago
Aye. I found its interface to be simpler but it quickly became clear that it was fundamentally useless since I lost the performance gains of partial mutations that left unmutated parts of the structure with the same reference.
Illniyar 10y ago
What do you mean? I'm pretty sure it only clones the minimal necessary. I.E. if I have {a:{aa:"1"},b:"cc"} and I change b, then {aa:"1"} will not be deep copied. Are you talking about something like keeping a reference to the parent and sending lookups up the chain (with a prototype or some such?)
- moon_priestess 10y ago
  The person you are replying to is talking about things like maps implemented with persistent trees. Updating a value in such a map generally only involves copying O(log N) nodes in the tree: It's not necessary to shallow copy the entire tree itself.
  - Illniyar 10y ago
    And immutable.jsdoes that?
    - undershirt 10y ago
      Oops, didn't realize that seamless does its own shallow copying strategy with `merge`, `set`, `setIn`. I can't speak to how this compares to persistent data structures implemented by immutable.js, clojure, elm, etc. But it looks like the seamless author said the following about it: > Persistent data structures are different, as their performance improvements are passive. Although seamless-immutable does not (and cannot, while maintaining its backwards compatibility with vanilla JS collections) use things like VLists under the hood, its cloning functions—such as merge—only bother to make shallow copies, as shallow and deep copies of immutable values are equivalent. In practice, this simple passive optimization has been sufficient; we have yet to encounter a performance problem that Bagwell-style persistent data structures would have solved. from: http://tech.noredink.com/post/107617838018/switching-from-immutablejs-to-seamless-immutable#performance http://tech.noredink.com/post/107617838018/switching-from-im...
- Tarean 10y ago
  The simplest example would be a persistent list. Think you first create a list [c,d,e]. You can safely share references to that. Then you attach a to one version and b to another: a \ c-d-e b / The memory for the original list is still shared! You can generalize that to trees and use that to implement, say, persistent hashmaps that can share data. This is also awesome for parallelization where you want to share data but don't need synchronization!
Illniyar 10y ago
The main benefit I derive from immutability in js is identity comparison (I.E. react's shouldComponentUpdate), I don't find the small performance hit of cloning to make a difference.

Waterluvian 10y ago

Aye. I found its interface to be simpler but it quickly became clear that it was fundamentally useless since I lost the performance gains of partial mutations that left unmutated parts of the structure with the same reference.

Illniyar 10y ago

What do you mean? I'm pretty sure it only clones the minimal necessary. I.E. if I have {a:{aa:"1"},b:"cc"} and I change b, then {aa:"1"} will not be deep copied. Are you talking about something like keeping a reference to the parent and sending lookups up the chain (with a prototype or some such?)

moon_priestess 10y ago
The person you are replying to is talking about things like maps implemented with persistent trees. Updating a value in such a map generally only involves copying O(log N) nodes in the tree: It's not necessary to shallow copy the entire tree itself.
- Illniyar 10y ago
  And immutable.jsdoes that?
  - undershirt 10y ago
    Oops, didn't realize that seamless does its own shallow copying strategy with `merge`, `set`, `setIn`. I can't speak to how this compares to persistent data structures implemented by immutable.js, clojure, elm, etc. But it looks like the seamless author said the following about it: > Persistent data structures are different, as their performance improvements are passive. Although seamless-immutable does not (and cannot, while maintaining its backwards compatibility with vanilla JS collections) use things like VLists under the hood, its cloning functions—such as merge—only bother to make shallow copies, as shallow and deep copies of immutable values are equivalent. In practice, this simple passive optimization has been sufficient; we have yet to encounter a performance problem that Bagwell-style persistent data structures would have solved. from: http://tech.noredink.com/post/107617838018/switching-from-immutablejs-to-seamless-immutable#performance http://tech.noredink.com/post/107617838018/switching-from-im...
Tarean 10y ago
The simplest example would be a persistent list. Think you first create a list [c,d,e]. You can safely share references to that. Then you attach a to one version and b to another: a \ c-d-e b / The memory for the original list is still shared! You can generalize that to trees and use that to implement, say, persistent hashmaps that can share data. This is also awesome for parallelization where you want to share data but don't need synchronization!

Illniyar 10y ago

The main benefit I derive from immutability in js is identity comparison (I.E. react's shouldComponentUpdate), I don't find the small performance hit of cloning to make a difference.