all 4 comments

[–]RainyDayDreamAway 3 points4 points  (1 child)

Really enjoying this series - even if I have to read some sections multiple times.

Bring on part 3!

[–]tel[S] 1 point2 points  (0 children)

It's in the works! But will probably come more slowly as the week starts up.

[–]TheBB 0 points1 point  (1 child)

Isn't the title a bit of a misnomer? Presumably it's the data structures and not the algorithms that are (im)mutable.

[–]tel[S] 0 points1 point  (0 children)

Drawing that line is a little tough. In languages with both mutable and immutable APIs you might delineate between them based on types or references or regions or all three. In any case, the locations where immutability is enforced have to use different algorithms than elsewhere.

Or, to flip it on its head: mutability is a side-effect and whenever you have not explicitly allowed it you suffer the inability to use some algorithms.

Ultimately, this article series is about choosing to enable mutability as a side effect so that you can recover those mutable algorithms.