What are processes good for?

Jay Nelson <>
Sat Mar 15 06:41:21 CET 2003

Chris Pressey wrote:
 > Of course it depends on your definition of waste, but
 > I don't think programmers should ever truly waste resources,
 > even cheap ones, when thereare equally viable alternatives
 > - which is what I would like to explore.

I sounded a bit overzealous here -- I actually am too
worried about performance and waste most of the time.
I recently saw at work how they ground their computers
into dust and thought "mine are sitting idle right now, why
aren't they working to make things easier for me later?"

To me the goal of coding is to: 1) accomplish something
useful, and 2) make clear the problem being solved so that
it can be verified to work correctly.  I generally ignore #1
and spend all my time working on problems that I find
suitably interesting, but really concentrate on #2.  I believe
that computers have plenty enough power that you should
always waste other things besides clarity and correctness.
Whatever you have the most of should be traded off against
the goal.  If storing a value in two places in memory makes
the code easier to understand and easier to write and maintain,
the memory should be "wasted".

 > But what about controls without state, or barely any state,
 > I wonder? Like pushbuttons and frames and labels. Do
 > they still get processes?

I've been thinking about this, and OO in general -- why it
initially feels wrong to me in erlang.  I may be way off, so
correct me, but here is the thinking:

The main characteristics of OO are statefulness and identity.
The goal of OO is to encapsulate state, protect it from outside
influence, publish a proscribed interface for interacting with it
and maintain independence from other instances of state whilst
trying to optimize and reuse the functionality that makes the data
consistent and dynamic.  It is an extension of structured
programming in that it is concerned with improving verifiability
and readability by limiting the scope of destructive side-effects.
At its heart, it is fundamentally concerned with state and sharing
state -- thus the need for identity.  As an optimization, a small
reference to a state can be shared among other entities, knowing
that at all times they refer to the same state.

The main characteristic of Functional Languages was to create
a way to avoid state and side-effects so that code could be
provably verified to perform to specification.  State is maintained
consistent by never modifying it, but rather creating a new version
of the state to represent the new state.  Pure functional languages
cannot have a shared reference to dynamic state, only a shared
reference to a particular version of state that is unchangeable.

In erlang, processes are the only safe way to share dynamic state.
That is why I listed "strong encapsulation" as a purpose for processes.
The process id may be shared among many places in the code, and
it will always refer to the currently accessible state that is available
via the message interface.  The server serialized access is what
makes it possible, but also what makes it not a pure functional language.

My answer to your question is: if the data is truly static, store it any
way that is convenient for the clarity and correctness of the code.  If
the data is shared *and* may change but all references to it *must*
refer to the same current state, then it *must* be a process.  Being
dynamic in and of itself may not qualify for a process if there is
enough time to update it synchronously, and it is not shared by
reference.  If either of these conditions is not true, it most be a process.

As you pointed out, the other case for using a process is to have
a consistent interface, which was precisely my point about code reuse /
adapting interfaces as another purpose of processes.  Other methods
work, but if you have a shared reference the other methods can't be
trusted (and are unwieldy code-wise to implement correctly when there
are several occurrences of the reference in complex data structures).


More information about the erlang-questions mailing list