why concurrency in the first place?

[Karel Van Oudheusden]

Hello,


I know this may sound like a naieve question but I would like to have a
thorough answer any way :)
"Why does an (Erlang) programmer have to program his application with
concurrency explicitly in mind?"
I also know (think) that this was the main intention of the Erlang
language.

Isn't it easier (cfr. Haskell) to free the programmer (=designer) from
this burden?  If a programmer has to specify it (as is the case in
Erlang), he will typically overspecify his system (even if the processes
are light weight).

Process spawning and message passing are sources of impureness in
Erlang.  This was a pragmatic choice of the Erlang founders.  Is this
because it is (still) difficult for pure functional compilers to do a
good job on extracting optimal concurrency from an initially pure
functional specification?  Does the Haskell compiler do a good job on
this?

I also want to make the following statement (please give feedback):  "It
is always easier to specify a system without explicit concurrency in
mind."  For example:  programming in Haskell (which is almost similar to
specifying) is done in a concurrency-independent way leaving the
eventual implementation to have any degree of true concurrency,
depending on what the compiler decides is best.

And then a final question:  if the application (or system) that has to
be specified contains a high degree of non-manifest constructs (such as
dynamic event behaviour which Erlang was typically designed for), does
the concurrency extraction of the compiler become an even more difficult
job?  Stated otherwise,  is the presence of non-manifest code a good
reason to have the Erlang programmer explicitly define the concurrency
of the system?
Can Haskell for instance tackle non-manifest code efficiently?  What is
the status of this problem in the research community?

thanx,
Karel.

P.S.
I have looked at the "Erlang/OTP R7 - speed test of new inet driver"
code the last couple of days.  It can be found at:
http://www.erlang.se/r7_inet_speed/index.shtm.  I am relatively new to
Erlang.  I must say that this code is not very readable.  I would
typically choose to use more modules in my code.  And I am very
astonished about the different (light-weight) processes that are spawned
every now and then.  Perhaps somebody could explain to me when it is
interesting (from a specification and implementation point of view) to
use a seperate process to accomplish something.  I have worked with
multi-threaded languages previously, but I would have typically chosen
other kinds of abstractions than the ones made here.  And concluding
from my above remarks, I now think a specification should contain no
concurrency at all.