Erlang Programming/Overview

Everything is a process

Software technologies often use a particular organizing principle. In Linux, everything is a file. In Ruby, everything is an object. In lisp, everything (program or data) is a list. In Erlang, the most important unit of organization is the process. Each process has an ID and at least one function that starts it (an entry point). In theory, there could be multiple entry point functions for a process. Each process is not limited to one function when running. On the contrary, one can have a whole barrel-of-functions that recursively call one-another and behave together as one process. GS based graphics programs in Erlang often use the barrel-of-functions per process technique to handle GUI events. CPU time is scheduled in a round robin fashion with equal time slices to each process.

Messages

Processes send messages and receive messages from one another. Messages are read with pattern matching. The messages are matched in a fifo (first in, first out) way.

Be parallel safe

To be serial-safe we need to control side effects. As a solution, first we invented structured programming, then object oriented programming. Each time the goal was to isolate state and variables to reduce side-effects. In the same tradition, side effects are more restricted in Erlang. If a function has no state then it will behave the same way every time. If a function has no side effects, then it cannot cause other functions to break.

A pure function is a function that returns the same value given the same arguments regardless of the context of the call of the function. This is what we normally expect from a mathematical function. A function that is not pure is said to have side effects.

Side effects typically occur if a function
a) sends a message
b) receives a message
c) calls exit
d) calls any BIF* which changes a processes environment or mode of operation (e.g. get/1, put/2, erase/1, process_flag/2 etc).

—quoted from Erlang Programming Rules (see references)

 * Note: "BIF" stands for "built in function"

Forget state

In general, state is forgotten in Erlang functions. Iteration is simulated by recursion. Variables can only be assigned once during each function call. State is carried by function arguments or state is put into a database if absolutely necessary. Avoiding state protects the integrity of processing in parallel. Each function call can be thought of as the creation of a pocket universe that has a set of equations that are true for the extent of invocation. Alternatively, one could conceive of erlang as a system to program with a kind of temporal logic. Some say that Erlang does not even have variable assignment, it only has pattern matching.

[ Head | Tail ] = [ 1, 2, 3 ], Head = 1.
 ok

Head must always match in a consistent way or the containing process will fail.

Head = 2.
 Error in process <0.29.0> with exit value: {{badmatch,2},[{erl_eval,expr,3}]}

Pattern matching can be thought of as a series of assertions that must be true.

Mixing paradigms

Simple object oriented programming can be simulated with erlang by using processes for objects and messages for methods.

The new software crisis

In 2003 Moore's law took a sharp turn. Overheating caused microprocessors to limit their speed to 4 GHz. The solution was to create multicore processors. This allowed Moore's law to continue but only in a parallel way. Multicell computing created a new software crisis, the MIMD (Multiple Instruction Multiple Data) software crisis. SIMD (Single Instruction Multiple Data) is relatively easy, MIMD is difficult. (Ref:The free lunch is over). MIMD programs are needed to make use of the new multi-core computers, otherwise, Moore's law breaks.

Uses of Erlang

Erlang is well suited to address the new MIMD software crisis. Erlang can be used for agent programming because of parallel processes and message passing. Erlang can be used for classical AI programming because it is a symbolic language. Because of extreme process isolation it should work well for genetic/evolutionary programming.

References

[1] - The free lunch is over, Dr Dobbs Journal, March 2005. (html)

[2] - Rules of Erlang programming from erlang.se (html)

[3] - Joe Armstrong (2003). "Making reliable distributed systems in the presence of software errors". Ph.D. Dissertation. (pdf)