Lambda the Ultimate

State manipulation is not inherently bad -- rather, limiting your state manipulation to a certain scope of objects for any given task is good. Functional programming makes this nice because you know the only object modified is the one you're returning to the caller :)

Of course, some applications (say, emulating a CPU) are all about state manipulation and would not benefit at all (well, much) from a functional language.

Not only that, but by avoiding the use of state when you can, it is quite easy to avoid a lot of headaches associated with concurrency. Without state, a calculation no longer needs to lock resources to avoid nondeterminism-based errors, nor does it need to perform hairy syncronization to keep stateful objects updated. So, without state, you can just tell a calculation to go off and compute itself somewhere and come back with the answer when it's done, without all the headaches (that I, at least associate) with stateful concurrency.

Now, that said, you still need some state behind the scenes to keep everything working, such as futures for passing evaluation results. There's a trick to doing statefulness with concurrency *right* that tends to scare people away.

Is this a trick or some insightful way of dealing with concurrent state?
Because I tend to see futures like lazy evaluations, but with a not so fancy dress on.

The nice thing with state is that it can be freely copied and distributed if it was immutable.

Still, if you want to change immutable state, make sure you refer to it with a new unique name while keeping the old state safe. Otherwise you're in big trouble.

Sharing immutable state is easy. Concurrently sharing (unique) references even more so.

Current databases/applications achieve shared state a-priori by introducing some kind of lock mechanism. But why use locks? Because they allow the illegal re-use of the same reference for different states in a system (=objects).

To achieve maximum concurrency, locked state and re-used names should be completely banned in a distributed setup.

This rule will eventually give us the scaleability everyone wants - its the referential transparency rule!

What if, for example, a specific field of a record must be updated and two users have opened the update form? the database will end up in having two records for the same thing, whereas one was expected.

It will be a great day indeed when the default approaches to basic architectural concerns in programming languages, such as mutation and concurrency, aren't, by default, the most complex to reason about, and therefore to use correctly, available! Peter Van Roy and Tim Sweeney have already covered what the alternatives might look like at length, so I won't rehash them here (and there was much rejoicing).