forget

[Thomas Lindgren]

[James Hague:]
>I disagree, though the concurrency is invaluable.
>
> The original point of functional programming, at least as I've always seen
> it, was that computation was done in a referentially transparent way (see
> Backus's FP articles, for example).  In the last decade or more, this has
> changed into functional programming being entirely about:
>
> 1. Higher order functions.
> 2. Type systems.

Good point. The interesting thing about Erlang in this respect is that

		concurrency encapsulates side effects.

Ets-tables, ports and all that can all be viewed as _other_ processes
changing state,
while your own process is entirely pure (if you forget about timeouts).

(The process dictionary, etc. can be viewed as passing an implicit state,
much like
the DCG transformation discussed before.)

This is, it seems to me, much nicer than our siblings ML or Lisp, where you
have visible
side-effects to data. (Though ML at least marks the places where this can
occur
clearly.) Haskell's approach (encapsulating side-effects in monads) appears
orthogonal
to Erlang's, though I haven't studied it closely enough to say.

It is much nicer, because you can rely on all data being referentially
transparent inside a process. In short: the "opaqueness" of your code is
limited to process communication, or if we also consider monitors and links,
process interactions.

Best,
Thomas