Functional Programming with Erlang

Last week I was reading Joe’s new book Programming Erlang and just couldn’t seem to get my mind around Functional Programming. You see when Joe says

Concurrency is easy.
We don’t have shared memory. I have my memory, you have yours, we have two brains, one each, they are not joined together. To change your memory I send you a message, I talk or wave my arms. You listen, you see, your memory changes, but without asking you a question or observing your response I do not know that you have received my messages.

bHe’s completely correct. So, why is Erlang a functional language then? I ask this Because; if you have memory then you have state, and your state is modifiable. Each process should have an associated heap, or at least mutable declared statics. When I send you a message you should be able to update your private store of knowledge.

I know that what I’m talking about can be achieved in a functional program, that to implement this you’d use a variable in the functional call, which is passed via tail-recursion, and that this isn’t too inconvenient because we use tail-recursion anyway just to receive the next message. But if you’re an agent with a large accumulated dictionary of knowledge, making a new copy of that dictionary to send to yourself is rather wasteful of memory. Since it’s your knowledge you should be able to modify it in-place. Just like what we do in the real world.

So while Joe has the right idea about modeling things from the real-world using concurrency, I feel that he’s got the implementation wrong. But it just might be that my growing up on imperative languages has broken my mind.