Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Immutable.js – Immutable Data Collections

facebook.github.io

Post reply on HN
Print view View original

51–60 of 86 posts

Re: Immutable.js – Immutable Data Collections

#51

Post by swannodette »

gcanti wrote: post #50

What do you think about vanilla `Object.freeze`? Any drawbacks? Here my considerations at the moment: Pros: - you can use native data structures instead of continually wrap / unwrap - you can use native methods on them (map, filter, ...) - hence (almost) no interoperability problems with other libraries - overall your coding style doesn't change so much - (possible perf gains since the js engine knows the object is f…

Lack of update is a show stopper. In general I would expect Immutable JS to trounce anything via Object.freeze with respect to performance. Real hash maps and sets are useful to organize programs - the semantics of Object.freeze on ES6 Map and Set are unclear and still suffer from above problems. Again Immutable JS has a big advantage.

In the context of building real applications with immutable data structures and a library like React that makes them easy to integrate - many of your concerns don't apply at all.

Re: Immutable.js – Immutable Data Collections

#52

Post by swannodette »

It's great to see more implementations of persistent data structures. I think over time people will begin to see that they allow us to radically rethink how we organize very complex programs that we have long believed are better constructed on stateful objects - user interfaces. It's been thrilling to see people discard many long held assumptions - the ClojureScript community has been running with UIs constructed on persistent data structure via Om (a layer over React) to startling effect - I highly recommend watching this recent demo from CircleCI https://m.youtube.com/watch?v=5yHFTN-_mOo.

Re: Immutable.js – Immutable Data Collections

#54

Post by gcanti »

swannodette wrote: post #51
gcanti wrote: post #50

What do you think about vanilla `Object.freeze`? Any drawbacks? Here my considerations at the moment: Pros: - you can use native data structures instead of continually wrap / unwrap - you can use native methods on them (map, filter, ...) - hence (almost) no interoperability problems with other libraries - overall your coding style doesn't change so much - (possible perf gains since the js engine knows the object is f…

Lack of update is a show stopper. In general I would expect Immutable JS to trounce anything via Object.freeze with respect to performance. Real hash maps and sets are useful to organize programs - the semantics of Object.freeze on ES6 Map and Set are unclear and still suffer from above problems. Again Immutable JS has a big advantage. In the context of building real applications with immutable data structures and a…

> Lack of update is a show stopper

Well, it's quite easy to write something like Facebook Immutability Helpers [1]. As you correctly stated, it really depends on your own use case and performance issues.

I'll try some perf experiment with [1] or something similar to see what comes out.

[1]: http://facebook.github.io/react/docs/update.html

Re: Immutable.js – Immutable Data Collections

#55

Post by rakoo »

rtfeldman wrote: post #28
franciscop wrote: post #27

I think I'm getting the example wrong. Wouldn't this: var map = Immutable.Map({a:1, b:2, c:3}); map = map.set('b', 20); map.get('b'); // 20 Give 2 instead of 20, since b is inmutable?

Only the map variable points to an immutable object. The second line reassigns that variable to a new (also immutable) Map instance, which is an exact copy of the original except that b has been changed. Does that make sense?

Put further, Rich Hickey had a talk about this, I don't remember which one. Most languages (unfortunately those we usually start with) conflate _identity_ and _value_, even though they're completely different notions. It was ok with mutable structures, but immutability puts the problem on the front.

A map is a value; it never changes. When you add something to a map, the old map doesn't change, only the new one does (in that it is created). We have as many values as there are transformations. Of course libraries and GCs will make sure that we use physical resources as efficiently as possible.

An identity, on the other hand, links a _label_ to a _value_ at a certain point in _time_:

- the label 'mymap' is first associated with the value '{"a":true}', then with the value '{"a":false}'

- the label 'Tim's Birthday' is associated with the value '1970/01/13' forever (people's birthday rarely change)

- the label 'President of the US' is associated with the value 'Barack Obama' for the moment, it was different a few years ago, and will be different in a few years.

Going back to the example, we have a single identity, with label 'map', that takes 2 different values over time.

Re: Immutable.js – Immutable Data Collections

#56

Post by gcanti »

swannodette wrote: post #52

It's great to see more implementations of persistent data structures. I think over time people will begin to see that they allow us to radically rethink how we organize very complex programs that we have long believed are better constructed on stateful objects - user interfaces. It's been thrilling to see people discard many long held assumptions - the ClojureScript community has been running with UIs constructed on…

Om is an amazing and inspiring project! thanks for writing it.

Re: Immutable.js – Immutable Data Collections

#57

Post by Too »

ScottBurson wrote: post #4

> The difference for the immutable collections is that methods which would mutate the collection, like 'push', 'set', 'unshift' or 'splice' instead return a new immutable collection. I think this is an unfortunate design decision which should be reconsidered. Functional operations should have different names than side-effecting operations. In general, I think that while side-effecting operations are commonly verbs, f…

Good point. One solution to this is loud warnings in the IDE about "unused return value". But since this is javascript it could in many cases be hard for the IDE to know what type you are calling the method on. (And technically all functions in javascript return something, undefined, which by some people might be considered a feature)

Depending on other API designs these warnings could also drown in false positives because some functions BOTH mutate the object and return it and you very rarely store the return value somewhere else, it's just there "for convenience" when chaining calls, such as foobar.add(123).multiply(456).subtract(789). Worse offenders are those that just randomly return something for the sake of it, take memcpy/memmove/etc in C for example, it accepts destination as a parameter and it also returns the very same destination for no good reason, i have never found a reason to use that return value.

An api should be designed so that unused return values in the majority of cases can be considered an error, unless explicitly ignored by casting it to (void) or something, most cases of unused return values you find are just people that are too lazy to check return codes which is about as smart as wrapping every statement in try/catch with an empty catch block.

Re: Immutable.js – Immutable Data Collections

#58

Post by killercup »

leebyron wrote: post #26
Havvy wrote: post #12

So, how does this compare to Clojurescript's Mori?

Performance: comparable Data-structure techniques: nearly the same API: do you like point-free functions (mori) or methods (immutable.js) mori is a direct compile of clojurescript's excellent data structures and functional tools (written in clojurescript, of course) to javascript. It favors a clojure-style API. immutable.js is entirely written in JavaScript and favors Idiomatic JS style API.

An important factor may also be: It's smaller in download size (15kB vs. 38kB for .min.gz).

Re: Immutable.js – Immutable Data Collections

#59

Post by Too »

gcanti wrote: post #50

What do you think about vanilla `Object.freeze`? Any drawbacks? Here my considerations at the moment: Pros: - you can use native data structures instead of continually wrap / unwrap - you can use native methods on them (map, filter, ...) - hence (almost) no interoperability problems with other libraries - overall your coding style doesn't change so much - (possible perf gains since the js engine knows the object is f…

Last time i checked Object.freeze actually made things slower, alot slower. Sounds counter intuitive and it might eventually change but that's the current state in most popular browsers.

Re: Immutable.js – Immutable Data Collections

#60

Post by taeric »

leebyron wrote: post #29
taeric wrote: post #13

Earlier quoted context omitted.

This doesn't necessarily work. Consider scenarios where you do one edit and then effectively undo it before the redraw. Or, more realistically, two rapidly successive edits effectively undo each other. Also, one could just as easily keep a dirty bit oneself.

Of course there's no way to know in O(1) time if you've done two edits that just so happen to sum to no-op, regardless of if you're using Immutable.js or not. However, depending on how to implement undo, you might be in good shape with Immutable.js. For example: you might keep a stack of the last few changed data around, and an undo could just pop off the stack in which case you can know if your oldData === newData i…

If you are doing a stack, that trick works fairly easily with a mutable stack, as well.

Regardless, I was not trying to toss out immutable structures with the bathwater. They are both incredibly cool and useful. Usually fairly memory intensive, though that is less of a deal today than it was in days past. Also, fairly cache unfriendly. For many applications, this is not a main concern. (32 way branching vectors, I'm looking at you.)

And yes, if you have a plethora of dirty bits, that could be difficult. If you have a plethora of immutable collections, that will lead to the same trouble. Consider, the optimization at stake here is essentially adding a single "isDirty" method to existing collections that is only set true on modifications and has a "clear" method. (There are other ways this can be done, just going for the easy way.) Far from difficult to encapsulate and get the O(1) dirty checking for cheap.

And I agree that applications with many dirty bits to check are difficult. You don't exactly dodge this with immutable collections. That is, in my experience, larger applications that have a lot of immutable collections tend to create a lot of management over old/new collections. Not shockingly, the trouble seems to be when you expand the scope of what you are doing wider and wider. Not necessarily how you are keeping track of modified collections.

Post reply on HN