Discussion on: Immutibilty

[Craig McIlwrath]

I'm not sure I follow your argument. You first claim that people use immutability when they don't understand the complexities mutability brings. Then, you state that immutability is more complicated?

Immutability isn't a "fundamental misunderstanding." It's a pattern that trades performance for an easier to understand program. There are times for immutable data structures and times for mutable data structures. I strongly disagree with "It's more simple to just change the values, and to understand what is being done." Let's look at an example:

function findRoots(a, b, c) {
  let d = b * b;
  d -= 4 * a * c;
  if (d < 0) return [];
  d = Math.sqrt(d);

  let denom = 2 * a;

  let root1 = -b + d;
  root1 /= denom;
  if (d == 0) return [root1];

  let root2 = -b - d;
  root2 /= denom;
  return [root1, root2];
}

Your goal is to figure out how this function works. You read top-to-bottom, understanding how each variable is calculated. You get to root1 and you realize you forgot what d was. You go back and check how d was defined. Now you have to re-interpret every statement that modified d. In more complex code, you may have to juggle the definition of several mutable variables, possibly with functions that modify their state and you have to read those functions definitions. This isn't to say it's impossible to write readable code with mutable data, but it requires much more care to write and a larger mental model for the reader.

Additionally, weakly-typed languages have no correspondence with immutability. Many functional languages are very strongly-typed (I'd consider the type system of Haskell more powerful than Java, for example) and are designed around immutability.

Overall, this article emanates a vibe of "Real programmers naturally understand complicated mutable state," although I doubt that that was intended.

[Mike Talbot ⭐]

A very good point from my perspective on legibility. A key thing here is using stack based variables that have super low cost, so no point following my argument there. You can have many stack based variables without fearing a garbage collection glitch or a complex memory management operation.

So for clarity on my comment in light of this point, I'm suggesting that:

    something.state = {...something.state, x: something.state.x+1}

If you do it frequently is a bad idea for performance reasons due to the amount of memory being stored up for collection. It's also a bit less legible than:

   something.state.x += 1

[John Peters]

The example shows poor programming technique.

// This is ambiguous, lazy, and the worst form of mutation.
// Its a terrible way to program in any language!
// Its what was done in "c" 40 years ago
// 93 characters

let d = b * b;
d -= 4 * a * c;
if (d < 0) return [];
d = Math.sqrt(d);

// A better way to program.
// Totally non-ambiguous, non lazy, self commenting. 
// No concern for mutability here.
// 193 characters

let taxmultiplier = taxbase*taxbase;
let exciseTax = 4;
let figuretax = taxmultiplier -(exciseTax*stateTax*countytax);
if(figuretax<0) return [];
let taxRoot = Math.sqrt(taxMultipier);

// even better, we have a tax rule a object which, for safety must be immutable; 
// unless the new taxable rates arrive of which we handle separately somewhere
// 138 characters

let a = {taxbase:.04, taxmultipler:'*2', stateTax:.1, countyTax:.05} 
return a.taxmultiplier -(a.exciseTax*a.stateTax*a.countytax);


// This allows us to pass in an object and return a number based on object content.
// 66 characters

function calcTax(a){
 return a.taxmultiplier -(a.exciseTax*a.stateTax*a.countytax);
}

// implementing a decorator
// 72 chars

function calcFloodTax(a){
 let floodtax = .005;
 let tax = calcTax(a);
 return tax * floodtax;
}

// a decorator with injected floodtax
// Total characters 32

function calcFloodTax(a, floodtax){
  return calcTax(a) * floodtax;
}

If a programmer can type 200 words per minute or 4 lines of code. From a time perspective it's just better to be a better programmer.

My main point is if the programming is done correctly we should be able to mutate any time we want. It's just way easier to set a field to a new value than to do the immutable tricks.

[Craig McIlwrath]

I was struggling to find a small example that could get my point across. Usually confusion due to mutable states arise in larger systems with many pieces, in my experience.

And yes, I agree your example is better code and more readable. But your code uses immutability to improve readability, so how does that support the idea that mutability doesn't decrease readability?

[John Peters]

Good point, the code example was only trying to point out that we don't need to be forced into an immutability model all the time, rather with proper techniques we can mutate at will and not worry about problems down the road.

But thanks for pointing this out. I'm beginning to see that javascript programmers may not follow the techniques listed above, so the "immutability" rules are good. Immutability is a creedo, a warning about what happens when mutating objects by reference where not intended. Always a bad outcome.