Immutable.js – Immutable Data Collections • Hacker News Board

Re: Immutable.js – Immutable Data Collections

#31

Post by leebyron » Sat, Nov 01, 2014, 3:46 AM UTC

jypie wrote: post #5

What is the benefit of having immutable variables that are just fake-built at runtime? At compile time, knowing some variables are constant and will not change would give the interpreter/compiler a lot of optimization chances but does this apply the same at runtime as well? the website says "efficiency" because immutable variables wouldn't need to be deep copied but would the deep copy operations be that frequent in…

I think there are two concepts being confused here - this is not the same as `var` vs. `const`/`let`.

Immutable.js implements persistent data structures, which are entirely runtime concepts.

---

Deep copying isn't very common because it's usually a pretty obvious flag that performance might suffer, however it's the only other way to implement this same concept and that pattern is definitely found in applications which desire persistent data. You might here this referred to as "defensive copying".

Re: Immutable.js – Immutable Data Collections

#32

Post by possibilistic » Sat, Nov 01, 2014, 3:55 AM UTC

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…

I wholeheartedly agree. Methods associated with mutation should raise exceptions. If errors aren't eagerly generated, assumptions about behaviour might be made. Not to mention this will make testing harder.

Readability is impacted as well. Building a mutable copy from an immutable should be explicit. These calls should have a very prominent call signature that is easily read, not skimmed over.

Very cool library, but I can sense lots of confusion and debugging resulting from accidental misuse.

Guava's immutables are pretty solid and serve as a great reference.

Re: Immutable.js – Immutable Data Collections

#33

Post by brentburgoyne » Sat, Nov 01, 2014, 4:18 AM UTC

skrebbel wrote: post #18

I've been using this (v2, though) rather extensively the last few months so I figured I'd share some experiences. First off, it works great. The TypeScript definition file also works fine as an API documentation of sorts, although it would be nice if some web site with a clickable TOC could be generated from it. I was a little confused at the beginning how the "Sequence" base class (changed name to Iterable in v3) wa…

I generated docs for Immutable.js using TypeDoc. It can be found here:

http://brentburg.github.io/immutable-docs/api/

Re: Immutable.js – Immutable Data Collections

#34

Post by apendleton » Sat, Nov 01, 2014, 4:27 AM UTC

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…

Agreed. Related: "Methods which return new arrays like slice or concat instead return new immutable collections" seems odd to me, at least for slice. Isn't one of the advantages of immutable arrays that you can operate on slices without copying because of the guarantee that the underlying representation won't change?

Re: Immutable.js – Immutable Data Collections

#35

Post by adam23 » Sat, Nov 01, 2014, 5:03 AM UTC

？？？

Re: Immutable.js – Immutable Data Collections

#36

Post by thatswrong0 » Sat, Nov 01, 2014, 5:07 AM UTC

mcav wrote: post #23

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…

That's silly. All of the methods are side-effect-free. It'd be useless and confusing to suffix some methods and not others.

Not to mention that if you see the assignment, you know that it's returning something, so you wouldn't (shouldn't) assume that the method is necessarily mutating the object. Plus I like the idea of moving towards immutable by default and calling methods that by name are explicit about mutation.

Re: Immutable.js – Immutable Data Collections

#37

Post by etrinh » Sat, Nov 01, 2014, 5:26 AM UTC

I've been using this library for a project, and here are my thoughts on it:

1. Immutable data structures are a huge win. I can't count the number of times I've been bitten by a bug caused by some subtle mutation that happened in a part of my code that I wasn't expecting.

2. Using this library for data structures everywhere, as a replacement for native JS arrays and objects, requires you to have discipline in naming your variables so that you can infer their types. Things can get pretty frustrating when you try to map over a Set, thinking it's a Map, for example.

3. The most annoying thing might be the documentation, which consists of a type definitions file and liberal comments. It's ok, but hardly a great interface for exploring the API.

Overall, liking the library so far. I think with good, searchable docs (with examples of API usage) this could be something really great.

Re: Immutable.js – Immutable Data Collections

#38

Post by leebyron » Sat, Nov 01, 2014, 5:26 AM UTC

apendleton wrote: post #34

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…

Agreed. Related: "Methods which return new arrays like slice or concat instead return new immutable collections" seems odd to me, at least for slice. Isn't one of the advantages of immutable arrays that you can operate on slices without copying because of the guarantee that the underlying representation won't change?

Slice is done in O(logN) with very little copying. This works via structural sharing with the original List.

Re: Immutable.js – Immutable Data Collections

#39

Post by yawaramin » Sat, Nov 01, 2014, 5:56 AM UTC

etrinh wrote: post #37

I've been using this library for a project, and here are my thoughts on it: 1. Immutable data structures are a huge win. I can't count the number of times I've been bitten by a bug caused by some subtle mutation that happened in a part of my code that I wasn't expecting. 2. Using this library for data structures everywhere, as a replacement for native JS arrays and objects, requires you to have discipline in naming y…

Apparently they support TypeScript, which would give you types without the pain of a naming scheme....

Re: Immutable.js – Immutable Data Collections

#40

Post by etrinh » Sat, Nov 01, 2014, 5:58 AM UTC

brentburgoyne wrote: post #33

skrebbel wrote: post #18

I've been using this (v2, though) rather extensively the last few months so I figured I'd share some experiences. First off, it works great. The TypeScript definition file also works fine as an API documentation of sorts, although it would be nice if some web site with a clickable TOC could be generated from it. I was a little confused at the beginning how the "Sequence" base class (changed name to Iterable in v3) wa…

I generated docs for Immutable.js using TypeDoc. It can be found here: http://brentburg.github.io/immutable-docs/api/

I used these docs when I was exploring the Immutable.js API! Very helpful, but Immutable just updated to v3 (your docs are v2), which introduces some breaking changes (for example, Vector is now called List). Would you mind updating your docs?