An immutable collection is data that is not changed after creation. Instead of updating shared values in place, functional code treats input as something to read and produces a result separately. This reduces moving parts: a function can be understood from its input and output rather than from hidden changes elsewhere. section 1.0 section 1.2
The problem becomes clear with a counter held outside a function. An increment operation that reads and changes that external counter can produce different results as the counter changes between calls. Passing the value in and returning the next value avoids that dependency: `counter => counter + 1` describes a calculation without changing external state. section 1.2
Transform an array without assigning into it
An imperative loop squares numbers by writing each result back into the original array. A functional rewrite uses `map` to describe the same transformation: `[0, 1, 2, 3].map(num => Math.pow(num, 2))` The expression yields `[0, 1, 4, 9]` while keeping the transformation focused on what each number becomes. This style fits declarative programming because the expression describes the desired result rather than a sequence of updates. section 1.2
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9].map(
function(num) {
return Math.pow(num, 2); #1
});
//-> [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
Compare the array transformation expressed with `map` to an in-place loop that assigns each squared value back to an array index. section 1.2
Immutability works alongside pure functions and referential transparency. When calculations do not rely on changing shared state, they are easier to combine into small operations, reason about independently, and use in a larger flow. Functional programming can also be used beside object-oriented architecture rather than replacing it completely. section 1.2 section 1.3
