What are processes good for?

[Jay Nelson]

Chris Pressey wrote:

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

See discussion below.  Frames and labels are generally
static adornments.  They could be changed by external
function calls, or could be active themselves, but today
they are generally just static state.  Push buttons are input
devices and need to be asynchronous stream signallers
to other processes; they need to be always alive and able
to send messages instantly. Their appearance on the screen is
less relevant as in the case of frames and labels.

 > If so, why, if it is wasteful enough to warrant not doing it?

Programmers should always waste resources in order of
their availability.  Amongst processes, memory, CPU
cycles, communication bandwidth, etc. each situation may
vary, but waste the cheapest and most abundant resource
if it makes the code clearer, faster or more correct.  In erlang
processes are abundant, and if you need more CPU "wasting"
them across nodes can increase performance if communication
overhead is low.

 > And if not, how do you deal with
 > the unorthogonality that will almost certainly present?

I don't understand this question.

==================
Thoughts on Processes
===================

Joe, et al, say that there should be one process for each
real world concurrent activity (or something along those lines).
Which is equivalent to the OO answer that there should be
one Object for each real world object being modeled.

While this is a good guideline, it assumes that the software
is modeling real-world processes and activities.  There are
other reasons for using processes (once you are no longer
a beginning programmer in erlang).  Here are a few I thought
of.  I would be interested in any additions that others think of.

Processes are useful for:

1) Modeling real world concurrent activities.
       - Self-explanatory for "liveness" purposes, but also
         in the realm of simulating multi-agent systems
         where each process is an independent agent.

       - OO programming would fall here.

2) Strong encapsulation
       - This is an engineering design decision to hide
          state, and provide a black-box communication
          interface to prevent unpredictability inside the model.

       - Finite state machine programming.

       - Or OO programming could fall here if you are not
         doing simulations or are working with abstract objects.

3) Code reuse / abstraction / adapting interfaces.
       - If strong encapsulation is used, two processes may
         only be able to talk to one another if they are aware
         of the interface design.  An adaptor process can be
         added to allow reuse of the two without modification
         (within the limitations of semantic equivalence).

       - If a complicated feature is not yet implemented, a
         simple substitute can be dummied up in a process
         and replaced later (although functions work as well,
         build, execution and management may be simplified
         by a separate process).

       - Streams can be transformed by successive process
         filtering to interface two existing bodies of code, or to
         simplify the algorithms by eliminating exception
         handling.

4) Simulating environmental influences.
       - In test situations a stream of sample data is
         useful in exercising a system, or where access to the
         real environment is prohibitive (e.g., the device is not
         yet built, the sensors need to be in outer space,
         catastrophic physical world failures, etc.)

       - This could be viewed as #1 but I think it warrants
          separate consideration.

5) Creating unpredictable, complex behaviour / adaptive behaviour
       - Dynamic feedback of multiple very simple processes
         can be used to create complex behaviour.  Think of
         a series of differential equations.

       - The ease of process creation and death allows for an
         approach to adaptive systems based on the collection
         of active processes changing in response to external
         influences.

6) Resource management / distribution
       - Relocation of connected resources may require the
         code to run on a different processor.  Processes are
         more easily managed and dynamically distributed.

       - When a resource has initialization and finalization
         needs, a process that traps EXITs can simplify the
         implementation.

       - Code replacement may be easier if the functionality is
         subdivided to account for stateful and stateless pieces;
         processes allow for simpler replacement policies.

       - Non-stop operation requires replication, failover and
         redundancy as well as partial or whole retry semantics.

       - When a resource is in short supply on a single node,
         (e.g., power, CPU speed, memory, attached storage)
         distributing the processing to several nodes may be a
         necessary architectural consideration.

       - Providing several peripherals with a common interface
         or network accessibility requires separate processes on
         each.


Any other ideas?

jay