> I am becoming more and more convinced that Erlang should be
>judged as a concurrent language than as an FP langauge.
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.
While these are both useful, they're more icing than the core of functional
programming: programming without destructive updates. As such, I find
writing functional programs more approachable in Erlang than in Haskell or
ML. Haskell lends itself to a dense style of function composition, which I
find obtuse. And both Haskell and ML put correct typing above writing the
most succint and obvious code. There's a good paper by Aiken, et al, about
the successor to Backus's FP: FL. One of the design goals was to avoid a
static type system because it was one extra thing to stand in the way of
someone learning the language. A very interesting read:
>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
while your own process is entirely pure (if you forget about timeouts).
(The process dictionary, etc. can be viewed as passing an implicit state,
the DCG transformation discussed before.)
This is, it seems to me, much nicer than our siblings ML or Lisp, where you
side-effects to data. (Though ML at least marks the places where this can
clearly.) Haskell's approach (encapsulating side-effects in monads) appears
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,