Hacker News Reader

Comment by yogthos | Hacker News Reader

Meanwhile, using persistent data structures instead of objects avoids the problem space entirely.

Yes but with persistent data structures each operation implies a cost, more or less big. For example most of times you do something with an persistent array you end up with fully cloning it. What's the point? I know the advantages of immutability, but I think that perform impure operations into pure functions, in a safe contest, is not so bad. My function can help with this...we could perform those faster impure operations (modifiyng local objects and arrays) and then create full, deeply cloned entities to pass around.

So my day job is working with Clojure/Script that defaults to immutability, and my team builds fairly large apps, here's a talk describing one of them https://www.youtube.com/watch?v=aXBe6hoi-Mw

In almost a decade of using Clojure, I've never seen persistent data structures become the bottleneck. The difference in cost is O(1) for in place mutation vs O(log 32 n) for revisioning. Note that the large exponent means the tree ends up being very flat, so updates end up being quite cheap in practice. Most times when I do something to a persistent data structure, I only change a small portion of the overall data structure. In fact, I think it's quite rare that you'd end up cloning the whole thing.

Personally, I view mutability as an optimization, and I think it should be used in cases where you actually need the performance beyond what persistent data structures can offer. My experience is that such cases are far and few between.

There's a big difference though: persistent data structure libs are heavy to send over the network. What we need is immutable data structures in the platform.

what are those data structures you use instead of objects?

Persistent data structures work the same way version control works on files. When you make a change, you're not copying the entire data structure over. Instead, you track deltas in changes between the original data and new data.

From user perspective, you're effectively making a copy each time you make a change, but you're not paying the price of a full copy. Instead, the cost of updates tends to be o( log n) vs o(1), which turns out to be fast enough for vast majority of cases. You can read about this in more detail here: https://en.wikipedia.org/wiki/Persistent_data_structure

JavaScript has a number of libraries that implement these data structures, underscore.js and immutable.js are examples. However, these libraries still require a lot of programmer discipline to use. For example, nothing stops you from putting a mutable object into an immutable data structure. At that point all bets are off.

There are also languages that are built around the idea of immutability. For example, I work with ClojureScript, and all data there is immutable by default. Data structure syntax in ClojureScript is actually quite similar to JSON, and it makes it easy to move between the two.

this article is specifically about deep cloning an object. i’m not quite sure how immutability fits in here and how it overcomes the need to create a clone of an object with no references to the original values. i’m not saying you are wrong about immutability overall, i just don’t understand how you perform this specific operation given your explanation

The idea is not to use objects. You can do everything you do with objects using plain data and working on it using functional style. Seeing how Js objects are already effectively maps with keys on them, it's not as big a jump as it may seem.

what is plain data and how is it structured?

edit: seems like you updated as i posted. i’m just trying to understand how you do this without using an object. you mention use of a map, but that is also an object. also, by copying a map i still access the original values, which is specifically what this article is implemented to avoid? i may be over my head here, i’m just trying to understand the “correct” way of doing this in javascript.

JSON is an example of plain data. You structure it by nesting maps and lists of items. For example, I work with medical data and here's an example of a structured patient resource in JSON format https://www.hl7.org/fhir/patient-example.json.html

if i parse that in javascript it becomes an object. if i want to copy that object it copies the reference to the object and references to the same properties. if i modify it, it then it modifies the original. the best i can do is to create a new object and copy the references over or use it as a prototype, both of which would be considered immutable. nested objects would need to be dealt with in the same way. as i understand, that’s what this lib is doing?

You wouldn't parse the data into objects. Instead, the immutable data structure libraries have their own implementation of maps, lists, and so on. These are the data structures you'd be using. And of course, if you're using a language like ClojureScript then it's just how things work out of the box.

i appreciate what you are saying about these immutable data libs, but i wasn’t aware they parsed and manipulated json directly. it sounds horrendously inneficient to me, but i’ll do some further investigation. thanks for the heads up

That's not what I was suggesting these libs do. You receive JSON as text over the wire. Instead of parsing it into native Js objects, it's instead parsed into alternative implementations of immutable data structures. There's nothing inefficient about it.

thanks. i hadn’t looked into the detail of these libs and had made some incorrect assumptions. will definitely look at their usage for a project historically suffering with side effects on the data.

Reply on news.ycombinator.com