Appendix B. Lists and referential transparency
What is the point of Erlang’s list data type, you may ask (in particular if you’re used to languages like Java, Python, and so on, where you work a lot with arrays, buffers, and whatnot). For every element, you also need a pointer to the next one, using valuable memory, and you can’t even add elements on the right side of the list! Pah!
This is all true; but in Erlang, you’re never allowed to modify the value of something if it could cause someone else’s data to be changed behind their back. This is the main idea behind the fancy words referential transparency.
Referential transparency is a simple concept. It boils down to this: If you get hold of a value (a term), and you give it a name (let’s say X) to keep track of it for the time being, then you’re guaranteed that X remains unchanged no matter what, even if you pass a reference to X to some other part of the program. In other words, values kept in variables (or parts of those values) are never changed behind your back. As you can see, this goes hand in hand with Erlang’s single-assignment variables.
The same reasoning is behind why strings are constant in Java: you don’t want to be embarrassed by printing something rude instead of your intended “More tea, Vicar?” just because you happened to pass a reference to that string to another, rather naughty function, before you printed the string.