forget

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

forget

James Hague-3
>  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:

http://citeseer.nj.nec.com/183013.html

(Section 4.2 is about the decision to be be dynamically typed, even though
"Within the functional programming community, an overwhelming majority
supports static typing.")

I need to write an FL interpreter in Erlang , I think :)


Reply | Threaded
Open this post in threaded view
|

forget

Thomas Lindgren-3

[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