This means variables can't be overwritten, arrays can't be modified, and nothing can be modified "in-place" - a new variable has to be created. Or if you need to modify it with a loop, then you would need recursion or foldl/similar.
What are the advantages and disadvantages of complete immutability?
Sometimes you'll want to pass objects to other functions. And if a pass-by-reference system is used by your language, that object may end up having changes made to it (looking at you python and Java). Immutability ensures that if you do something like adding items to a list you pass to a function, the original list in the calling scope won't be changed.
const) is what is ideal in my opinion.
$\endgroup$
const.
$\endgroup$
const and immutable are different: const is a promise by the function that it won't modify the object, whereas immutable is (also) a promise to the function that the object won't be modified. const is a constraint/guarantee for/about the function, immutable is (also) for the rest of the code.
$\endgroup$
Programs that use mutability are easier to write, up to a certain level of complexity. You have an object that contains a value that's almost what you need, so you mutate the object and you move on.
But programmers spend a lot more time reading code than writing code. And reading code is harder than writing code. Reading code with mutable state is a lot harder than reading code without mutable state. If the language guarantees that no state is mutable, it's a huge cognitive win.
One thing that makes mutability especially painful is concurrency. When multiple threads can access the same memory, you risk a race condition each time the program reads or writes an object with mutable state. This makes even very simple reasoning about programs hard. Simple-looking code like
# x : integer
assert (x + x) mod 2 == 0
may be wrong if x is actually mutable by another thread.
This concern can be alleviated by making the language fully immutable. But outside of some special-purpose languages, programs have to deal with the mutability of the world around them — they have to handle input-ouput. So good languages make mutability explicit. For example, in Haskell, all mutability has to be handled through monad operations. In Rust, the type system keeps track of which objects are mutable and of which objects are potentially shared: the world is immutable by default. In Erlang, all local computation is immutable, except for interprocess communication and direct access to a single, compound mutable object (the process state).
Two big advantages are lazy evaluation and memoisation. If computations don't have side-effects, such as by mutating data structures, then you don't need to compute them at all when their results don't matter, and you don't need to recompute them multiple times when their results do matter.
In order to modify a single element in an array with for example 1000 items, all 999 other items would need to be copied over into a brand new array. This would add considerable overhead and memory usage.
Advantages:
Given array of floats of arbitrary size, how would you compute the sum of them?
int sum(const std::vector<int> & array, int p, int s) {
return p == array.size() ? s : sum(array, p + 1, s + array[p]);
}
sum({1,2,4,8}, 0, 0) // it works, 15!
Mmm, does not this look a little bit too sophisticated? If not for you, go ahead with this idea. You can try to code this way without any special compiler, just accepting the agreed conventions.
Challenges
