[erlang-questions] Re: Shared/Hybrid Heap
Paulo Sérgio Almeida
Thu Nov 4 12:52:07 CET 2010
there is a point on which I do not agree; when you say:
On 11/4/10 10:46 AM, Robert Virding wrote:
> - I think that having immutable data even within only one process is a big win. Having mutable data gives you all the problems of global data. Immutable data makes it much easier to keep track of what is happening with your data, which is always a Big Win.
I would say that having mutable data gives us SOME problems, but much
LESS than when we have global mutable data.
You are mixing the problems due to:
- global data
- mutable data
In most languages around we have the nightmare of mutable global data,
and the nasty problem of aliasing in object references.
On the other hand in Erlang we have processes that give us locality, but
only immutable data in each process.
I (and others) think there is a place for a middle-ground where
processes give us locality, allowing a divid-and-conquer of the global
problem into simple parts, where the data in a given process is
manageable, but where if the algorithm calls for mutable data then we
should be able to use it. All the nasty problems of shared memory
concurrency (from the programmer's point of view) have already
disappeared when we have only per-process mutable data as opposed to
global mutable data.
If the data is immutable and only pure functions are used, we have extra
benefits, but not always can we afford it, nor is it necessary even for
proving correctness. Lot's of classic formal methods stuff with
pre-conditions, post-conditions, invariants, Hoare logic, etc, were made
for the mutable data world. They become difficult to apply when we have
global data and aliasing, but may well be applied when we have just a
little local data.
The idea would be to be able to use the many proven algorithms that were
created for the imperative sequential world inside each process, and let
the process concept a la Erlang deal with the concurrency aspects.
I am not saying it is now practical to add it to Erlang, but that some
language in this design spot (actors + local mutable data) makes much sense.
More information about the erlang-questions